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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250811122053.4bfyoefln7wpz2a4@DEN-DL-M70577>
Date: Mon, 11 Aug 2025 12:20:53 +0000
From: Daniel Machon <daniel.machon@...rochip.com>
To: Robert Marko <robert.marko@...tura.hr>
CC: Nicolas Ferre <nicolas.ferre@...rochip.com>, Arnd Bergmann
	<arnd@...nel.org>, Alexandre Belloni <alexandre.belloni@...tlin.com>,
	"Russell King" <linux@...linux.org.uk>, Claudiu Beznea
	<claudiu.beznea@...on.dev>, Catalin Marinas <catalin.marinas@....com>, Will
 Deacon <will@...nel.org>, Olivia Mackall <olivia@...enic.com>, Herbert Xu
	<herbert@...dor.apana.org.au>, "David S . Miller" <davem@...emloft.net>,
	Vinod Koul <vkoul@...nel.org>, Andi Shyti <andi.shyti@...nel.org>, Lee Jones
	<lee@...nel.org>, Mark Brown <broonie@...nel.org>, Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
	<linux-crypto@...r.kernel.org>, <dmaengine@...r.kernel.org>,
	<linux-i2c@...r.kernel.org>, <linux-spi@...r.kernel.org>,
	<linux-serial@...r.kernel.org>, Oleksij Rempel <o.rempel@...gutronix.de>,
	<luka.perkov@...tura.hr>, Conor Dooley <Conor.Dooley@...rochip.com>, "Lars
 Povlsen - M31675" <Lars.Povlsen@...rochip.com>
Subject: Re: [PATCH v8 01/10] arm64: Add config for Microchip SoC platforms

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@...rochip.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@...nel.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