[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZpJOMg2rNbJW_Oi-P5O+k6=rMB1XEUd1BwJQK14fMH2w@mail.gmail.com>
Date: Fri, 28 May 2021 10:56:31 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Esben Haabendal <esben@...nix.com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Russell King <linux@...linux.org.uk>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ARM: imx: only enable pinctrl as needed
On Fri, May 28, 2021 at 9:55 AM Arnd Bergmann <arnd@...db.de> wrote:
> I think it would be even better to leave all these drivers to be
> user-configurable. The symbols are currently defined as e.g.
>
> config PINCTRL_IMX51
> bool "IMX51 pinctrl driver"
> depends on SOC_IMX51
> select PINCTRL_IMX
> help
> Say Y here to enable the imx51 pinctrl driver
>
> which could be changed to
>
> config PINCTRL_IMX51
> bool "IMX51 pinctrl driver" if COMPILE_TEST && !SOC_IMX51
> depends on OF
> default SOC_IMX51
> select PINCTRL_IMX
> help
> Say Y here to enable the imx51 pinctrl driver
>
> Today, having it configurable is pointless because you can't turn it off
> when SOC_IMX51 is set, and you can't turn it on when SOC_IMX51
> is disabled.
I agree this looks better.
With pin control drivers I think this often reflects the desire
to not make it possible to build a kernel that will not boot.
Usually this is because initramfs is assumed not to be used to house
the most necessary modules, so any modules need to be loaded
later from e.g. eMMC and that of course needs pin control
before it can be mounted.
I think it is a bit of "embedded culture" to do things like
this, because the distro way with modules and initramfs isn't
used by all embedded build environments like it is on your
regular Debian, Fedora, ... etc. Instead they assume a
monolithic kernel tailored for the hardware to a certain extent.
Maybe we need to clarify somehow that the driving idea
behind multiplatform also assumes modularization and
using initramfs for the most necessary modules and things
like that.
Yours,
Linus Walleij
Powered by blists - more mailing lists