Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	Will McVicker <willmcvicker@google.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Tomasz Figa <tomasz.figa@gmail.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Alessandro Zummo <a.zummo@towertech.it>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	John Stultz <john.stultz@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Saravana Kannan <saravanak@google.com>,
	"Cc: Android Kernel" <kernel-team@android.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	linux-rtc@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs
Date: Thu, 30 Sep 2021 13:25:06 +0200	[thread overview]
Message-ID: <CAMuHMdUkP6Jg5sXAXEw7twGqPs8rKftiyh+wYomFVdRHyhUrgQ@mail.gmail.com> (raw)
In-Reply-To: <YVWX1fFB1L1K3Mnn@google.com>

Hi Lee,

On Thu, Sep 30, 2021 at 12:56 PM Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:
> > On Thu, Sep 30, 2021 at 11:23 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > I've taken the liberty of cherry-picking some of the points you have
> > > reiteratted a few times.  Hopefully I can help to address them
> > > adequently.
> > >
> > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > Reminder: these are essential drivers and all Exynos platforms must have
> > > > them as built-in (at least till someone really tests this on multiple
> > > > setups).
> > >
> > > > Therefore I don't agree with calling it a "problem" that we select
> > > > *necessary* drivers for supported platforms. It's by design - supported
> > > > platforms should receive them without ability to remove.
> > >
> > > > The selected drivers are essential for supported platforms.
> > >
> > > SoC specific drivers are only essential/necessary/required in
> > > images designed to execute solely on a platform that requires them.
> >
> > Why?
>
> Because without them the image wouldn't functional on any level.
>
> But you're right, there is still no requirement for it to be built-in.
>
> > > For a kernel image which is designed to be generic i.e. one that has
> > > the ability to boot on vast array of platforms, the drivers simply
> > > have to be *available*.
> >
> > If the drivers are really essential/necessary/required, this precludes
> > running the generic kernel image on the platform that requires them,
> > making the kernel not sufficiently generic.
>
> If they are not at all present, then yes.  However that is not what is
> being suggested.  The essential functionality will be provided.  Just
> not built-in.

I really meant "essential/necessary/required to be built-in".

> > > Forcing all H/W drivers that are only *potentially* utilised on *some*
> > > platforms as core binary built-ins doesn't make any technical sense.
> > > The two most important issues this causes are image size and a lack of
> > > configurability/flexibility relating to real-world application i.e.
> > > the one issue we already agreed upon; H/W or features that are too
> > > new (pre-release).
> >
> > True, if "potentially".  If not potentially, they must be included.
>
> I'm not sure what you're trying to say here.  Would you mind elaborating?

It was a comment to your "*potentially* utilised on *some* platforms".
It is clear they are not used on the other ("not *some*") platforms, but your
sentence was unclear whether they are always or only sometimes used on
"*some*" platforms.
"always" => "not potentially"
"sometimes" => "potentially".

I hope this makes it more clear.

> > > Bloating a generic kernel with potentially hundreds of unnecessary
> > > drivers that will never be executed in the vast majority of instances
> > > doesn't achieve anything.  If we have a kernel image that has the
> > > ability to boot on 10's of architectures which have 10's of platforms
> > > each, that's a whole host of unused/wasted executable space.
> >
> > The key here is if the driver is required or not to use the platform,
> > and why it is required.  If the requirement comes from some deficiency
> > in the kernel code or config system, it should be fixed, if possible.
> > And the fix should be tested.
> > If it cannot be fixed, the driver should be included, else it would
> > preclude running the generic kernel on the affected platform.
>
> Sorry, I'm not following.

It all depends on why the driver is "required to be built-in".
Depending on the reason behind that requirement, the driver can be
changed from built-in to modular without ill effects on functionality.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds