On Thu, Jul 3, 2025 at 3:56 PM Nicolas Ferre <nicolas.ferre@xxxxxxxxxxxxx> wrote: > > 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. Yes, this is why I went with a menu instead, to me it is much cleaner. So, how would you guys want me to proceed? a) Keep the menu-based config symbol or b) Like for AT91, add a hidden symbol and keep the individual SoC-s in the top level platform menu? Regards, Robert > > >> 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 -- Robert Marko Staff Embedded Linux Engineer Sartura d.d. Lendavska ulica 16a 10000 Zagreb, Croatia Email: robert.marko@xxxxxxxxxx Web: www.sartura.hr
