On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:

On 30/09/2021 11:23, Lee Jones 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.
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*.

By "essential", I meant drivers which are needed for supported platform
to boot properly.

Yes, I know what you meant by essential.

My comment still stands.  As long as they are provided, it should work.

Also without significant performance penalty due to
probe deferrals.

Agreed.  We will try to find a way to test this.

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

Geert responded here. If drivers are essential for supported platforms
to boot, having them built-in has technical sense.

We're going to have to agree to disagree here.

None of us are currently aware of any technical reasons why these
particular drivers have to be built-in.  Hopefully we can prove this
out with testing.

quoted

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

The same with all the DTS and hundreds of drivers you keep out of tree.

I do not keep any drivers out of tree. :)

quoted

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.

Accepting changes based on the proviso that vendors upstream all of
their work-in-progress solutions is an unfair position.  

You twisted (or ignored) my words here. I said before - sacrificing any
mainline platform (e.g. reliable boot for distro) for an out-of-tree
vendor which does no want to upstream drivers is the unfair position.
One of the incentives of upstreaming is to be able to shape kernel and
be considered in kernel upstream decisions. That's the privileged for
upstreamed platforms - they have an impact.

Vendor decides to stay out - fine, vendor's choice. You loose impact.
Any sad words like "oh upstream does not want to change for me" should
receive a message: "please join the upstream :), so we will change
together".

No one is proposing to sacrifice anything.

This change is believed to be benign.

quoted

We already
discussed why upstreaming support for bleeding edge H/W and
functionality is unrealistic in terms of competitive advantage.

Nope, my last point was not responded to. You said that there is no
point for vendor to upstream bleeding edge HW. Then you said that there
is also little point to upstream older HW.

The driver in question is already upstream.

It is my hope that the vendor will realign with Mainline and upstream
the differences (providing the current competitive edge).  Although I
have no real influence in this regard, as I have no contact with
them.

Basically following this approach you agree that vendor does not have to
do anything because it is inconvenient for him.

However upstream has to adapt to downstream vendor, right?

No, this is *unfair to all the platforms we upstreamed*.

The point here is that this change should not be a determent to
anyone.

quoted

Exynos isn't special in this regard.  This applies to any vendor who
releases Android images and wishes to be solve all of the issues the
GKI project addresses (please read the article above for more about
this).

We have then slightly different goals, because you are driven by Android
release images and this is why you are less interested in NXP and
Renesas. Only some vendors should receive such changes? No, in upstream
we are not focusing on any specific distro and there are other uses of
Exynos (and NXP and Renesas) platforms. Therefore the choice/policy and
overall design tries to match all vendors, not only some subset
convenient to Android.

If Android (or some vendor) wants to have exception for a specific
driver/platform, it must do it in upstream way, by contributing, not by
changing to match downstream needs while ignoring other users.

No users are being ignored.  No damaging changes are being proposed.

This has little to do with Android and everything to do with the
possibly of a more generic kernel.  Moving drivers out of platform
code and into /drivers along with enabling components as modules has
been an on-going effort for many years now.

I'm struggling to see how this is different.

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