Message-ID: <20221201003102.1b131a2d@slackpad.lan>
Date:   Thu, 1 Dec 2022 00:31:02 +0000
From:   Andre Przywara <andre.przywara@....com>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     Conor Dooley <conor@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
        ajones@...tanamicro.com, heiko@...ech.de, samuel@...lland.org,
        wens@...e.org, jernej.skrabec@...il.com,
        linux-sunxi@...ts.linux.dev, linux-riscv@...ts.infradead.org,
        devicetree@...r.kernel.org, krzysztof.kozlowski+dt@...aro.org,
        robh+dt@...nel.org, jszhang@...nel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        aou@...s.berkeley.edu, apatel@...tanamicro.com,
        Atish Patra <atishp@...osinc.com>, christianshewitt@...il.com,
        Conor Dooley <conor.dooley@...rochip.com>, guoren@...nel.org,
        heinrich.schuchardt@...onical.com, linus.walleij@...aro.org,
        Paul Walmsley <paul.walmsley@...ive.com>,
        stano.jakubek@...il.com
Subject: Re: [PATCH v2 12/12] riscv: defconfig: Enable the Allwinner D1
 platform and drivers

On Wed, 30 Nov 2022 12:24:08 -0800 (PST)
Palmer Dabbelt <palmer@...belt.com> wrote:

Hi,

> On Mon, 28 Nov 2022 22:54:18 PST (-0800), Conor Dooley wrote:
> >
> >
> > On 29 November 2022 06:49:25 GMT, Andrew Jones <ajones@...tanamicro.com> wrote:  
> >>On Mon, Nov 28, 2022 at 09:17:38PM +0000, Conor Dooley wrote:  
> >>> On 28/11/2022 21:11, Heiko Stübner wrote:  
> >>> > Am Samstag, 26. November 2022, 17:40:11 CET schrieb Conor Dooley:  
> >>> >> On Fri, Nov 25, 2022 at 05:46:56PM -0600, Samuel Holland wrote:  
> >>> >>> Now that several D1-based boards are supported, enable the platform in
> >>> >>> our defconfig. Build in the drivers which are necessary to boot, such as
> >>> >>> the pinctrl, MMC, RTC (which provides critical clocks), SPI (for flash),
> >>> >>> and watchdog (which may be left enabled by the bootloader).  
> >>> >>
> >>> >> All of that looks good.
> >>> >>  
> >>> >>> Other common
> >>> >>> onboard peripherals are enabled as modules.  
> >>> >>
> >>> >> This I am not sure about though. I'll leave that to Palmer since I'm
> >>> >> pretty sure it was him that said it, but I thought the plan was only
> >>> >> turning on stuff required to boot to a console & things that are
> >>> >> generally useful rather than enabling modules for everyone's "random"
> >>> >> drivers. Palmer?  
> >>> > 
> >>> > Isn't the defconfig meant as a starting point to get working systems
> >>> > with minimal config effort? At least that was always the way to go on arm
> >>> > so far :-) .
> >>> > 
> >>> > So having boot-required drivers built-in with the rest enabled as modules
> >>> > for supported boards will allow people to boot theirs without headaches.
> >>> > 
> >>> > Disabling unneeded drivers if you're starved for storage space in a special
> >>> > project is always easier than hunting down all the drivers to enable for a
> >>> > specific board.   
> >>> 
> >>> I wouldn't mind being able to turn on all the PolarFire SoC stuff and
> >>> yeah, that would be the way that arm64 does it. But I do recall hearing
> >>> that I should not turn stuff on this way, when I initially tried to
> >>> turn stuff on via selects, got a nack and asked if I could do this instead.
> >>> 
> >>> But it may be that I misremember, which is why I appealed to the Higher
> >>> Powers for clarification :)  
> >>
> >>FWIW, I don't worry too much about modules in defconfig because I always
> >>immediately apply a 'LSMOD=$PWD/L localmodconfig' to it, where the L
> >>file is an lsmod output which only includes modules I need.  
> >
> > idk, defconfig to me is not about you or I, it's about A Developer that gets an SBC or a devkit and their experience.
> > Or alternatively, someone's CI ;)
> > I'd like to put everything in, but I recall that being shot down, that's all.  
> 
> The whole "who is defconfig for" discussion always ends up kind of 
> vague, but IIUC it's generally aimed at kernel hackers as opposed to end 
> users -- so it's not meant to be a disto config, that's why we have 
> things like the debug options turned on.  I tend to think of it as a "if 
> a patch submitter is going to test only one config, then what do I want 
> in it?" and let that determine what goes in defconfig.

Yes, this is also the guideline for arm64. On top of that it's supposed
to be a sane common config to be used to reproduce bugs. A common
question from maintainers is "Does it happen with defconfig?". If not,
what does it take on top of defconfig to get there?
The idea is that people can run the same config and thus the same image
on *their* boards, regardless of the particular platform.

> IMO having defconfig contain the drivers necessary to boot every common 
> dev board as =y, and having =m for anything else on those boards also 
> seem reasonable.  That will make the transition from vendor/distro 
> kernels to upstream a bit smoother, which is always good.  I guess 
> there's some slight build time and image size issues, but aside from 
> some very small systems that shouldn't be too bad for kernel developers 
> -- and if we really end up with another popular system with 6MiB of RAM 
> we can just stick another tiny defconfig in there for it.
> 
> I actually don't use modules when doing kernel development because I 
> find it easier to track things when they're packed into a single binary, 

Originally arm64 included most drivers as [=y], but this grew too big
quickly, so it was scaled back to be able to boot from the board's mass
storage (SD card, SATA, NVMe), with non-essential drivers included as
modules. And yes, most people just build and use the Image, which keeps
the build effort reasonable.
Also required features to make systemd happy, and to enable other core
distro features, were included, so that such kernels can boot distro
userland without losing significant functionality.

> but I don't think it's necessary to steer everyone that way.
> 
> Adding some of the Arm folks here, in case they have thoughts.  The best 
> bet is probably to try and do something similar, though my worry is that 
> the answer is something like "target standard platforms" and we don't 
> have any.

No such thing on arm64 either :-(

Cheers,
Andre

Powered by blists - more mailing lists