Re: [PATCH v8 01/10] arm64: Add config for Microchip SoC platforms

[Daniel Machon <daniel.machon@microchip.com>]

On Fri, Jul 04, 2025 at 07:36:06PM +0200, Robert Marko wrote:
> 
> On Thu, Jul 3, 2025 at 3:56 PM Nicolas Ferre
> <nicolas.ferre@microchip.com> 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@kernel.org> 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

Hi Robert,

Sorry for the late reply.

I appreciate the effort to make the addition of future symbols easier by using
a common ARCH_MICROCHIP symbol — that makes sense to me.

Regarding the actual symbols, I’m certainly no expert, but I agree with
Nicolas, that having more granular control with separate ARCH_SPARX5 and
ARCH_LAN969X could make sense, as opposed to only having ARCH_MICROCHIP, as
Arnd mentioned.

As for the goal of using a common symbol for drivers to depend on,  while not
breaking existing configs (are there any unwritten rules or practices about
breaking existing configs?), I think option B will work fine. I dont mind the
symbols being top-level.

/Daniel