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@xxxxxxxxxxxxx> 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@xxxxxxxx> 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