Re: [PATCH v5 8/8] ARM: defconfig: Add a zx29 defconfig file

["Arnd Bergmann" <arnd@arndb.de>]

On Fri, Apr 24, 2026, at 09:13, Linus Walleij wrote:
> On Tue, Apr 21, 2026 at 10:24 PM Stefan Dösinger
> <stefandoesinger@gmail.com> wrote:
>
>> This enables existing drivers that already are (UART) or will be (USB,
>> GPIO) necessary to operate this board even if they aren't declared in
>> the DTS yet.
>>
>> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> *I* personally (as SoC maintainer) think that having a few more defconfigs
> is fine, even helpful.
>
> But I would defer this to the more senior SoC maintainers because I think
> their stance is something like:
>
> - We have multi_v7_defconfig for compile testing
>
> - We know that binary gets way to big for your system: it's for build
>   testing and perhaps booting in QEMU or systems with many MB of
>   RAM, not for actually running it on products.
>
> - You are encouraged to keep your own defconfig out-of-tree.

Right, we clearly need to do something better than what we are with
the general defconfigs, as I'm sure many of the existing ones are
never actually used for booting a machine, and are horribly out of
date with the Kconfig options.

I wouldn't object to adding another defconfig for a new (or revived)
soc family, but I don't want to have more per-board ones.
Overall, we have about 70 defconfigs and 55 soc families that have their
own mach-* directory (plus a few without code), and the number of
defconfigs alone makes it hard to keep them up to date. 

> However I even challenged this myself by adding a defconfig for memory
> constrained Broadcoms a while back (NACKed/ignored ;) so if it was all
> up to me I would merge this.

I don't even remember that discussion ;-)

One idea might be to have a tiny base defconfig, plus platform
specific fragments that add drivers. The problem is agreeing
what bits are essential enough to still get enabled in the
tiny config.

       Arnd