[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221129064925.kjjqrzmi3fm67akt@kamzik>
Date: Tue, 29 Nov 2022 07:49:25 +0100
From: Andrew Jones <ajones@...tanamicro.com>
To: Conor Dooley <conor@...nel.org>
Cc: Heiko Stübner <heiko@...ech.de>,
Samuel Holland <samuel@...lland.org>, palmer@...belt.com,
Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
linux-sunxi@...ts.linux.dev, linux-riscv@...ts.infradead.org,
devicetree@...r.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Jisheng Zhang <jszhang@...nel.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Andre Przywara <andre.przywara@....com>,
Albert Ou <aou@...s.berkeley.edu>,
Anup Patel <apatel@...tanamicro.com>,
Atish Patra <atishp@...osinc.com>,
Christian Hewitt <christianshewitt@...il.com>,
Conor Dooley <conor.dooley@...rochip.com>,
Guo Ren <guoren@...nel.org>,
Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
Linus Walleij <linus.walleij@...aro.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Stanislav Jakubek <stano.jakubek@...il.com>
Subject: Re: [PATCH v2 12/12] riscv: defconfig: Enable the Allwinner D1
platform and drivers
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.
Thanks,
drew
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Powered by blists - more mailing lists