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

Hi Arnd,

I saw your reply to my defconfig pull request, but apparently never received your original reply. I only found this mail here. It looks like I have to look for a better E-Mail provider as gmail is choking on the volume of the linux-arm-kernel mailing list.

To answer your questions I found at https://lore.kernel.org/all/[email protected]/ :

> Either way, the patch description above should at least explain
> why you think you need your own defconfig, as we don't normally
> take those.

It was more cluelessness / being new to kernel development that gave me the impression that boards should have defconfigs. Since then I ran across scripts/dt_to_config. I haven't tested it yet on my DT, but if it does the right thing I don't think this board needs a defconfig.

>> +CONFIG_CMDLINE="console=ttyAMA0 earlyprintk root=/dev/ram rw"

> A definconfig should normall not rely on earlyprintk, just add
> that when you actually need to debug the super-early boot
> stages. With "earlycon" it should pick up the right console
> from the stdout path and work almost as early.

>> +CONFIG_BINFMT_FLAT=y

> Are you actually using flat binaries? I wasn't aware that this
> is still possible on MMU-enabled kernels.

>> +CONFIG_BLK_DEV_RAM=y
>> +CONFIG_BLK_DEV_RAM_COUNT=4

> The old ramdisk boot is going away in the future, please use
> initramfs instead. This should also save a good amount of RAM.

I'll fix those in my tree and keep the defconfig around just in case, but otherwise drop it from the submission. We can revisit it later when the board is more complete.

>> +CONFIG_DEVTMPFS=y # FIXME: This is specific to my initrd. Remove 
>> before upstream
>stale comment?

I believe I removed this in later versions though :-)

Cheers,
Stefan

> Am 24.04.2026 um 11:54 schrieb Arnd Bergmann <[email protected]>:
> 
> On Fri, Apr 24, 2026, at 09:13, Linus Walleij wrote:
>> On Tue, Apr 21, 2026 at 10:24 PM Stefan Dösinger
>> <[email protected]> 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 <[email protected]>
>> 
>> *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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEQxb0tqoFWyeVMl1sPRO8yFRPGiIFAmoOu4EACgkQPRO8yFRP
GiL8IQ//Zm20DYooaVaVCuklde82UX5X2MHKLX3bEwoqFm8OwrwK1a0bu61uKXRd
TTj/RVjingjzc/MWqbhSiDLM+1tvrMaa8bhi16TRYn5upIa71KlieKL5Kd/9cmoW
fqmI+HoIIq6mQTIYJ2GMCp0/ciADEXnE41buFWzPiu7BMeVInJMaYpX6NKyXd7ZG
oAf3t5tCMMxrRfBq7bv4JV8TAjLdibq+SNyxH6xYoZwrW7J6pLYGeHJcbUNNHJFD
Vl5PgpflnmNhfcQk7nTKufpY44szSAwB9GmiuOemwzmUEGv3V0e4t8Rni1FlHQsR
gAUiB04OMbDSDV9kntSrZwbEUR4UkJLZhKanfJOTv/Sy6pNZLpcS0TB5YY7TEfcy
lr1oKB9HXUka9mhPKFmGrC0TN7jkPKmkTLK70RXVtNX/pU4dFSsm0yP76XL2KrBA
rfvH0At+i5cU3nPYvoOm56VkiOfHsnQB9adNQ5l8GeAUpQB6HI4jr23IhD8BYvsB
yKxccCZ4tkD05c9InZqE+lsxvB9esDjo4gKZzFWhuXY/+4rOcRowbxsFGHt/TCWn
9U7SU0cAsuce6Ex+oPs62EkqM0yyZ0FMVlmVGI9PJ5O1sJ5W6xYOlxwnLGH6TJNE
bOIJ4WxSJmZra+QaQXak7qAOxAV92+Du/IioWZnoXjGc0BzTjhw=
=rcPP
-----END PGP SIGNATURE-----