On Thu, 30 Sep 2021, Tomasz Figa wrote:

2021年9月30日(木) 18:23 Lee Jones [off-list ref]:

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

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

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.

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.

[Chiming in as a clock driver sub-maintainer and someone who spent a
non-insignificant part of his life on SoC driver bring-up - not as a
Google employee.]

I'd argue that the proper way for them to achieve it would be to
extend the upstream frameworks and/or existing drivers with
appropriate APIs to allow their downstream modules to plug into what's
already available upstream.

Is that the same as exporting symbols to framework APIs?

Since this is already a method GKI uses to allow external modules to
interact with the core kernel/frameworks.  However, it's not possible
to upstream these without an upstream user for each one.

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