On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:

Hi Lee,

On Thu, Sep 30, 2021 at 11:23 AM Lee Jones [off-list ref] wrote:

quoted

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:

quoted

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).

quoted

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.

quoted

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.

quoted

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.

quoted

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?

quoted

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.

quoted

In order for vendors to work more closely with upstream, they need the
ability to over-ride a *few* drivers to supplement them with some
functionality which they believe provides them with a competitive edge
(I think you called this "value-add" before) prior to the release of a
device.  This is a requirement that cannot be worked around.

By insisting on drivers (most of which will not be executed in the
vast majority of cases) to be built-in, you are insisting on a
downstream kernel fork, which all of us would like to avoid [0].

[0] Full disclosure: part of my role at Linaro is to keep the Android
kernel running as close to Mainline as possible and encourage/push the
upstream-first mantra, hence my involvement with this and other sets.
I assure you all intentions are good and honourable.  If you haven't
already seen it, please see Todd's most recent update on the goals and
status of GKI:

  Article: https://tinyurl.com/saaen3sp
  Video:   https://youtu.be/O_lCFGinFPM

quoted

We don't even know what are these unsupported, downstream platforms
you want customize kernel for. They cannot be audited, cannot be
compared.  Affecting upstream platforms just because
vendor/downstream does not want to mainline some code is
unacceptable. Please upstream your drivers and DTS.

quoted

You also mentioned downstream devices but without actually ever defining
them. Please be more specific. What SoC, what hardware?

Accepting changes based on the proviso that vendors upstream all of
their work-in-progress solutions is an unfair position.  We already
discussed why upstreaming support for bleeding edge H/W and
functionality is unrealistic in terms of competitive advantage.

Besides, we might not be talking about new silicon at all (I don't
believe anyone alluded to that).  The flexibility in configuration
simply allows for generic upstream drivers to be swapped out for ones
which may have more or slightly different functionality (that can't be
publicly shared until release).

The replacement drivers are already a downstream kernel fork, which you
would like to avoid?

Avoid, yes, absolutely.

However, in the real world of competitive tech, other than in extreme
cases such as; fully open source, community driven, cute embedded
hobby platforms, there will always be changes required on-top of
upstream projects.  Even as upstream kernel developers we need to
understand and respect that.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel