Robert, Arnd,
On 03/07/2025 at 14:25, Robert Marko wrote:
On Wed, Jul 2, 2025 at 9:57 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
On Wed, Jul 2, 2025, at 20:35, Robert Marko wrote:
Currently, Microchip SparX-5 SoC is supported and it has its own symbol.
However, this means that new Microchip platforms that share drivers need
to constantly keep updating depends on various drivers.
So, to try and reduce this lets add ARCH_MICROCHIP symbol that drivers
could instead depend on.
Thanks for updating the series to my suggestion!
@@ -174,6 +160,27 @@ config ARCH_MESON
This enables support for the arm64 based Amlogic SoCs
such as the s905, S905X/D, S912, A113X/D or S905X/D2
+menuconfig ARCH_MICROCHIP
+ bool "Microchip SoC support"
+
+if ARCH_MICROCHIP
+
+config ARCH_SPARX5
+ bool "Microchip Sparx5 SoC family"
This part is the one bit I'm not sure about: The user-visible
arm64 CONFIG_ARCH_* symbols are usually a little higher-level,
so I don't think we want both ARCH_MICROCHIP /and/ ARCH_SPARX5
here, or more generally speaking any of the nested ARCH_*
symbols.
Well, having a look at arch/arm64/Kconfig.platforms, I like how NXP is
organized.
SPARX5, LAN969x or other MPU platforms, even if they share some common
IPs, are fairly different in terms of internal architecture or feature set.
So, to me, different ARCH_SPARX5, ARCH_LAN969X (as Robert proposed) or
future ones make a lot sense.
It will help in selecting not only different device drivers but
different PM architectures, cores or TrustZone implementation...
This version of your patch is going to be slightly annoying
to existing sparx5 users because updating an old .config
breaks when ARCH_MICROCHIP is not enabled.
Oh, yeah, indeed. Even if I find Robert's proposal ideal.
Alexandre, Lars, can you evaluate this level of annoyance?
The two options that I would prefer here are
a) make ARCH_SPARX5 a hidden symbol in order to keep the
series bisectable, remove it entirely once all references
are moved over to ARCH_MICROCHIP
b) Make ARCH_MICROCHIP a hidden symbol that is selected by
ARCH_SPARX5 but keep the menu unchanged.
Hi Arnd,
Ok, I see the issue, and I would prefer to go with option b and do
what I did for
AT91 with the hidden ARCH_MICROCHIP symbol to avoid breaking current configs.
Yep, but at the cost of multiple entries for Microchip arm64 SoCs at the
"Platform selection" menu level. Nuvoton or Cavium have this already, so
it's probably fine.
Let's see what the sparx5 and at91 maintainers think about
these options.
Sounds good, let's give them some time before I respin this series.
Thanks to both of you. Best regards,
Nicolas
