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] [thread-next>] [day] [month] [year] [list]

Message-ID: <421d61db-27eb-4ad2-bd98-eb187fd14b1e@microchip.com>
Date: Thu, 3 Jul 2025 15:55:47 +0200
From: Nicolas Ferre <nicolas.ferre@...rochip.com>
To: Robert Marko <robert.marko@...tura.hr>, Arnd Bergmann <arnd@...nel.org>,
	Alexandre Belloni <alexandre.belloni@...tlin.com>
CC: 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>,
	Daniel Machon <daniel.machon@...rochip.com>, <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

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.

>> 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