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

[Lee Jones]

On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:

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

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

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

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

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

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