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

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

> 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