[PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Bartosz Golaszewski]

Microchip is the only platform that doesn't have a top-level switch for
disabling all SoC families. Align it with other platforms and update the
arm64 defconfig to keep the default config the same.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 arch/arm64/Kconfig.platforms | 10 ++++------
 arch/arm64/configs/defconfig |  1 +
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 54eb1d7fd419b..72c812e76b0b1 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -188,16 +188,15 @@ config ARCH_MESON
 	  This enables support for the arm64 based Amlogic SoCs
 	  such as the s905, S905X/D, S912, A113X/D or S905X/D2
 
-menu "Microchip SoC support"
+menuconfig ARCH_MICROCHIP
+	bool "Microchip SoC support"
 
-config ARCH_MICROCHIP
-	bool
+if ARCH_MICROCHIP
 
 config ARCH_LAN969X
 	bool "Microchip LAN969X SoC family"
 	select PINCTRL
 	select DW_APB_TIMER_OF
-	select ARCH_MICROCHIP
 	help
 	  This enables support for the Microchip LAN969X ARMv8-based
 	  SoC family of TSN-capable gigabit switches.
@@ -212,7 +211,6 @@ config ARCH_SPARX5
 	bool "Microchip Sparx5 SoC family"
 	select PINCTRL
 	select DW_APB_TIMER_OF
-	select ARCH_MICROCHIP
 	help
 	  This enables support for the Microchip Sparx5 ARMv8-based
 	  SoC family of TSN-capable gigabit switches.
@@ -223,7 +221,7 @@ config ARCH_SPARX5
 	  security through TCAM-based frame processing using versatile
 	  content aware processor (VCAP).
 
-endmenu
+endif
 
 config ARCH_MMP
 	bool "Marvell MMP SoC Family"
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d1e894b988f99..580b7ab2ea05f 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -57,6 +57,7 @@ CONFIG_ARCH_HISI=y
 CONFIG_ARCH_KEEMBAY=y
 CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_MESON=y
+CONFIG_ARCH_MICROCHIP=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_ARCH_NXP=y
 CONFIG_ARCH_LAYERSCAPE=y
-- 
2.47.3

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Krzysztof Kozlowski]

On 26/02/2026 15:36, Bartosz Golaszewski wrote:
> Microchip is the only platform that doesn't have a top-level switch for
> disabling all SoC families. Align it with other platforms and update the
> arm64 defconfig to keep the default config the same.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
>  arch/arm64/Kconfig.platforms | 10 ++++------
>  arch/arm64/configs/defconfig |  1 +
>  2 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 54eb1d7fd419b..72c812e76b0b1 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -188,16 +188,15 @@ config ARCH_MESON
>  	  This enables support for the arm64 based Amlogic SoCs
>  	  such as the s905, S905X/D, S912, A113X/D or S905X/D2
>  
> -menu "Microchip SoC support"
> +menuconfig ARCH_MICROCHIP
> +	bool "Microchip SoC support"
>  
> -config ARCH_MICROCHIP
> -	bool
> +if ARCH_MICROCHIP

This will surprise all out-of-tree non-defconfig users, because their
boards will stop working (drivers depend on ARCH_LAN969X|ARCH_SPARX5
which will be now disabled), but I like the consistency.

I guess this will go via Microchip arm64 soc tree.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Bartosz Golaszewski]

On Thu, Feb 26, 2026 at 3:49 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 26/02/2026 15:36, Bartosz Golaszewski wrote:
> > Microchip is the only platform that doesn't have a top-level switch for
> > disabling all SoC families. Align it with other platforms and update the
> > arm64 defconfig to keep the default config the same.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > ---
> >  arch/arm64/Kconfig.platforms | 10 ++++------
> >  arch/arm64/configs/defconfig |  1 +
> >  2 files changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> > index 54eb1d7fd419b..72c812e76b0b1 100644
> > --- a/arch/arm64/Kconfig.platforms
> > +++ b/arch/arm64/Kconfig.platforms
> > @@ -188,16 +188,15 @@ config ARCH_MESON
> >         This enables support for the arm64 based Amlogic SoCs
> >         such as the s905, S905X/D, S912, A113X/D or S905X/D2
> >
> > -menu "Microchip SoC support"
> > +menuconfig ARCH_MICROCHIP
> > +     bool "Microchip SoC support"
> >
> > -config ARCH_MICROCHIP
> > -     bool
> > +if ARCH_MICROCHIP
>
> This will surprise all out-of-tree non-defconfig users, because their
> boards will stop working (drivers depend on ARCH_LAN969X|ARCH_SPARX5
> which will be now disabled), but I like the consistency.
>

I'm not following, ARCH_SPARX5 remains enabled in defconfig and
ARCH_LAN969X was already disabled by default.

> I guess this will go via Microchip arm64 soc tree.
>

I think this should be picked up directly into the ARM SoC tree to
avoid conflicts later into the cycle.

Bartosz

> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> Best regards,
> Krzysztof

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Arnd Bergmann]

On Fri, Feb 27, 2026, at 09:42, Bartosz Golaszewski wrote:
> On Thu, Feb 26, 2026 at 3:49 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> This will surprise all out-of-tree non-defconfig users, because their
>> boards will stop working (drivers depend on ARCH_LAN969X|ARCH_SPARX5
>> which will be now disabled), but I like the consistency.
>>
>
> I'm not following, ARCH_SPARX5 remains enabled in defconfig and
> ARCH_LAN969X was already disabled by default.

Your patch to the in-kernel defconfig is fine, but most users don't
use that but instead have their own defconfig files which they now
need to update.

      Arnd

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Bartosz Golaszewski]

On Fri, Feb 27, 2026 at 9:49 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Feb 27, 2026, at 09:42, Bartosz Golaszewski wrote:
> > On Thu, Feb 26, 2026 at 3:49 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >> This will surprise all out-of-tree non-defconfig users, because their
> >> boards will stop working (drivers depend on ARCH_LAN969X|ARCH_SPARX5
> >> which will be now disabled), but I like the consistency.
> >>
> >
> > I'm not following, ARCH_SPARX5 remains enabled in defconfig and
> > ARCH_LAN969X was already disabled by default.
>
> Your patch to the in-kernel defconfig is fine, but most users don't
> use that but instead have their own defconfig files which they now
> need to update.
>

Ah ok, I see. Do you want me to do:

config ARCH_SPARX5
    def_bool y if ARCH_MICROCHIP

?

That should fix it, right?

Bart

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Krzysztof Kozlowski]

On 27/02/2026 09:51, Bartosz Golaszewski wrote:
> On Fri, Feb 27, 2026 at 9:49 AM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Fri, Feb 27, 2026, at 09:42, Bartosz Golaszewski wrote:
>>> On Thu, Feb 26, 2026 at 3:49 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>
>>>> This will surprise all out-of-tree non-defconfig users, because their
>>>> boards will stop working (drivers depend on ARCH_LAN969X|ARCH_SPARX5
>>>> which will be now disabled), but I like the consistency.
>>>>
>>>
>>> I'm not following, ARCH_SPARX5 remains enabled in defconfig and
>>> ARCH_LAN969X was already disabled by default.
>>
>> Your patch to the in-kernel defconfig is fine, but most users don't
>> use that but instead have their own defconfig files which they now
>> need to update.
>>
> 
> Ah ok, I see. Do you want me to do:
> 
> config ARCH_SPARX5
>     def_bool y if ARCH_MICROCHIP
> 
> ?
> 
> That should fix it, right?

No, because they still won't have ARCH_MICROCHIP. The out-of-tree
person's config is for example only:

CONFIG_ARCH_SPARX5=y

now, this will be silently discarded with all the drivers depending on
it, because the ARCH_MICROCHIP is missing.

I don't think this is fixable, that's why I wrote that I accept the
negative impact because I like the cleanup more.

Best regards,
Krzysztof

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Arnd Bergmann]

On Fri, Feb 27, 2026, at 10:21, Krzysztof Kozlowski wrote:
> On 27/02/2026 09:51, Bartosz Golaszewski wrote:
>> On Fri, Feb 27, 2026 at 9:49 AM Arnd Bergmann <arnd@arndb.de> wrote:

> I don't think this is fixable, that's why I wrote that I accept the
> negative impact because I like the cleanup more.

Agreed. I remember when we split up the ethernet drivers into per-vendor
subdirectories and had to add 'default y' to each one in 88f07484ccdf
("drivers/net/ethernet/*: Enabled vendor Kconfig options"). Changing the
default to 'n' would be a regression now as much as it was then, so it's
not something we can expect to do more easily in the future.

If the Microchip maintainers think the change will cause too much
extra work, we can leave the current version forever, otherwise lets
apply it for 7.1.

   Arnd

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

On Fri, Feb 27, 2026 at 10:28:53AM +0100, Arnd Bergmann wrote:
> On Fri, Feb 27, 2026, at 10:21, Krzysztof Kozlowski wrote:
> > On 27/02/2026 09:51, Bartosz Golaszewski wrote:
> >> On Fri, Feb 27, 2026 at 9:49 AM Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > I don't think this is fixable, that's why I wrote that I accept the
> > negative impact because I like the cleanup more.
> 
> Agreed. I remember when we split up the ethernet drivers into per-vendor
> subdirectories and had to add 'default y' to each one in 88f07484ccdf
> ("drivers/net/ethernet/*: Enabled vendor Kconfig options"). Changing the
> default to 'n' would be a regression now as much as it was then, so it's
> not something we can expect to do more easily in the future.
> 
> If the Microchip maintainers think the change will cause too much
> extra work, we can leave the current version forever, otherwise lets
> apply it for 7.1.

Here's the previous discussion when this was added not too long ago:
https://lore.kernel.org/all/20250811122053.4bfyoefln7wpz2a4@DEN-DL-M70577/

Daniel is probably the one that "needs" to answer this, I think the
lan969x is added recently enough for this to not be particularly
disruptive.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Krzysztof Kozlowski]

On 27/02/2026 11:15, Conor Dooley wrote:
> On Fri, Feb 27, 2026 at 10:28:53AM +0100, Arnd Bergmann wrote:
>> On Fri, Feb 27, 2026, at 10:21, Krzysztof Kozlowski wrote:
>>> On 27/02/2026 09:51, Bartosz Golaszewski wrote:
>>>> On Fri, Feb 27, 2026 at 9:49 AM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>>> I don't think this is fixable, that's why I wrote that I accept the
>>> negative impact because I like the cleanup more.
>>
>> Agreed. I remember when we split up the ethernet drivers into per-vendor
>> subdirectories and had to add 'default y' to each one in 88f07484ccdf
>> ("drivers/net/ethernet/*: Enabled vendor Kconfig options"). Changing the
>> default to 'n' would be a regression now as much as it was then, so it's
>> not something we can expect to do more easily in the future.
>>
>> If the Microchip maintainers think the change will cause too much
>> extra work, we can leave the current version forever, otherwise lets
>> apply it for 7.1.
> 
> Here's the previous discussion when this was added not too long ago:
> https://lore.kernel.org/all/20250811122053.4bfyoefln7wpz2a4@DEN-DL-M70577/
> 
> Daniel is probably the one that "needs" to answer this, I think the
> lan969x is added recently enough for this to not be particularly
> disruptive.

I don't get arguments there. The policy is one ARCH per vendor, so why
exactly upstream would like to "having more granular control with
separate"? That's downstream or vendor wishlist, not upstream.


Best regards,
Krzysztof

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Daniel Machon]

> On 27/02/2026 11:15, Conor Dooley wrote:
> > On Fri, Feb 27, 2026 at 10:28:53AM +0100, Arnd Bergmann wrote:
> >> On Fri, Feb 27, 2026, at 10:21, Krzysztof Kozlowski wrote:
> >>> On 27/02/2026 09:51, Bartosz Golaszewski wrote:
> >>>> On Fri, Feb 27, 2026 at 9:49 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >>> I don't think this is fixable, that's why I wrote that I accept the
> >>> negative impact because I like the cleanup more.
> >>
> >> Agreed. I remember when we split up the ethernet drivers into per-vendor
> >> subdirectories and had to add 'default y' to each one in 88f07484ccdf
> >> ("drivers/net/ethernet/*: Enabled vendor Kconfig options"). Changing the
> >> default to 'n' would be a regression now as much as it was then, so it's
> >> not something we can expect to do more easily in the future.
> >>
> >> If the Microchip maintainers think the change will cause too much
> >> extra work, we can leave the current version forever, otherwise lets
> >> apply it for 7.1.
> >
> > Here's the previous discussion when this was added not too long ago:
> > https://lore.kernel.org/all/20250811122053.4bfyoefln7wpz2a4@DEN-DL-M70577/
> >
> > Daniel is probably the one that "needs" to answer this, I think the
> > lan969x is added recently enough for this to not be particularly
> > disruptive.
> 
> I don't get arguments there. The policy is one ARCH per vendor, so why
> exactly upstream would like to "having more granular control with
> separate"? That's downstream or vendor wishlist, not upstream.
> 
> 
> Best regards,
> Krzysztof

The out-of-tree defconfig impact is minimal for us. As Conor mentioned, lan969x
was added fairly recently, so the number of affected users should be small.

/Daniel

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Bartosz Golaszewski]

On Fri, Feb 27, 2026 at 12:18 PM Daniel Machon
<daniel.machon@microchip.com> wrote:
>
> > On 27/02/2026 11:15, Conor Dooley wrote:
> > > On Fri, Feb 27, 2026 at 10:28:53AM +0100, Arnd Bergmann wrote:
> > >> On Fri, Feb 27, 2026, at 10:21, Krzysztof Kozlowski wrote:
> > >>> On 27/02/2026 09:51, Bartosz Golaszewski wrote:
> > >>>> On Fri, Feb 27, 2026 at 9:49 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > >>
> > >>> I don't think this is fixable, that's why I wrote that I accept the
> > >>> negative impact because I like the cleanup more.
> > >>
> > >> Agreed. I remember when we split up the ethernet drivers into per-vendor
> > >> subdirectories and had to add 'default y' to each one in 88f07484ccdf
> > >> ("drivers/net/ethernet/*: Enabled vendor Kconfig options"). Changing the
> > >> default to 'n' would be a regression now as much as it was then, so it's
> > >> not something we can expect to do more easily in the future.
> > >>
> > >> If the Microchip maintainers think the change will cause too much
> > >> extra work, we can leave the current version forever, otherwise lets
> > >> apply it for 7.1.
> > >
> > > Here's the previous discussion when this was added not too long ago:
> > > https://lore.kernel.org/all/20250811122053.4bfyoefln7wpz2a4@DEN-DL-M70577/
> > >
> > > Daniel is probably the one that "needs" to answer this, I think the
> > > lan969x is added recently enough for this to not be particularly
> > > disruptive.
> >
> > I don't get arguments there. The policy is one ARCH per vendor, so why
> > exactly upstream would like to "having more granular control with
> > separate"? That's downstream or vendor wishlist, not upstream.
> >
> >
> > Best regards,
> > Krzysztof
>
> The out-of-tree defconfig impact is minimal for us. As Conor mentioned, lan969x
> was added fairly recently, so the number of affected users should be small.
>
> /Daniel

So can this be picked up directly into ARM-SoC please?

Bart

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Krzysztof Kozlowski]

On 11/03/2026 09:32, Bartosz Golaszewski wrote:
>>>>
>>>> Here's the previous discussion when this was added not too long ago:
>>>> https://lore.kernel.org/all/20250811122053.4bfyoefln7wpz2a4@DEN-DL-M70577/
>>>>
>>>> Daniel is probably the one that "needs" to answer this, I think the
>>>> lan969x is added recently enough for this to not be particularly
>>>> disruptive.
>>>
>>> I don't get arguments there. The policy is one ARCH per vendor, so why
>>> exactly upstream would like to "having more granular control with
>>> separate"? That's downstream or vendor wishlist, not upstream.
>>>
>>>
>>> Best regards,
>>> Krzysztof
>>
>> The out-of-tree defconfig impact is minimal for us. As Conor mentioned, lan969x
>> was added fairly recently, so the number of affected users should be small.
>>
>> /Daniel
> 
> So can this be picked up directly into ARM-SoC please?

This should go rather via Microchip ARM64 tree.

Best regards,
Krzysztof

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Bartosz Golaszewski]

On Wed, Mar 11, 2026 at 9:58 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 11/03/2026 09:32, Bartosz Golaszewski wrote:
> >>>>
> >>>> Here's the previous discussion when this was added not too long ago:
> >>>> https://lore.kernel.org/all/20250811122053.4bfyoefln7wpz2a4@DEN-DL-M70577/
> >>>>
> >>>> Daniel is probably the one that "needs" to answer this, I think the
> >>>> lan969x is added recently enough for this to not be particularly
> >>>> disruptive.
> >>>
> >>> I don't get arguments there. The policy is one ARCH per vendor, so why
> >>> exactly upstream would like to "having more granular control with
> >>> separate"? That's downstream or vendor wishlist, not upstream.
> >>>
> >>>
> >>> Best regards,
> >>> Krzysztof
> >>
> >> The out-of-tree defconfig impact is minimal for us. As Conor mentioned, lan969x
> >> was added fairly recently, so the number of affected users should be small.
> >>
> >> /Daniel
> >
> > So can this be picked up directly into ARM-SoC please?
>
> This should go rather via Microchip ARM64 tree.
>

Hey Microchip maintainers, can you please pick it up for v7.1?

Bartosz

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[claudiu beznea]

On 3/18/26 10:21, Bartosz Golaszewski wrote:
> On Wed, Mar 11, 2026 at 9:58 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 11/03/2026 09:32, Bartosz Golaszewski wrote:
>>>>>>
>>>>>> Here's the previous discussion when this was added not too long ago:
>>>>>> https://lore.kernel.org/all/20250811122053.4bfyoefln7wpz2a4@DEN-DL-M70577/
>>>>>>
>>>>>> Daniel is probably the one that "needs" to answer this, I think the
>>>>>> lan969x is added recently enough for this to not be particularly
>>>>>> disruptive.
>>>>>
>>>>> I don't get arguments there. The policy is one ARCH per vendor, so why
>>>>> exactly upstream would like to "having more granular control with
>>>>> separate"? That's downstream or vendor wishlist, not upstream.
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Krzysztof
>>>>
>>>> The out-of-tree defconfig impact is minimal for us. As Conor mentioned, lan969x
>>>> was added fairly recently, so the number of affected users should be small.
>>>>
>>>> /Daniel
>>>
>>> So can this be picked up directly into ARM-SoC please?
>>
>> This should go rather via Microchip ARM64 tree.
>>
> 
> Hey Microchip maintainers, can you please pick it up for v7.1?

Applied to microchip-soc, thanks!

Will push it later today (infrastructure issue ATM).

Thank you,
Claudiu

Re: [PATCH] arm64: Kconfig: provide a top-level switch for Microchip platforms

[Krzysztof Kozlowski]

On 27/02/2026 09:42, Bartosz Golaszewski wrote:
> On Thu, Feb 26, 2026 at 3:49 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 26/02/2026 15:36, Bartosz Golaszewski wrote:
>>> Microchip is the only platform that doesn't have a top-level switch for
>>> disabling all SoC families. Align it with other platforms and update the
>>> arm64 defconfig to keep the default config the same.
>>>
>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>> ---
>>>  arch/arm64/Kconfig.platforms | 10 ++++------
>>>  arch/arm64/configs/defconfig |  1 +
>>>  2 files changed, 5 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>> index 54eb1d7fd419b..72c812e76b0b1 100644
>>> --- a/arch/arm64/Kconfig.platforms
>>> +++ b/arch/arm64/Kconfig.platforms
>>> @@ -188,16 +188,15 @@ config ARCH_MESON
>>>         This enables support for the arm64 based Amlogic SoCs
>>>         such as the s905, S905X/D, S912, A113X/D or S905X/D2
>>>
>>> -menu "Microchip SoC support"
>>> +menuconfig ARCH_MICROCHIP
>>> +     bool "Microchip SoC support"
>>>
>>> -config ARCH_MICROCHIP
>>> -     bool
>>> +if ARCH_MICROCHIP
>>
>> This will surprise all out-of-tree non-defconfig users, because their
>> boards will stop working (drivers depend on ARCH_LAN969X|ARCH_SPARX5
>> which will be now disabled), but I like the consistency.
>>
> 
> I'm not following, ARCH_SPARX5 remains enabled in defconfig and
> ARCH_LAN969X was already disabled by default.

That's why I said non-defconfig.


Best regards,
Krzysztof