On Thu, 23 Sep 2021, Krzysztof Kozlowski wrote:

On 23/09/2021 14:39, Lee Jones wrote:

quoted

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

quoted

On 21/09/2021 19:45, Will McVicker wrote:

quoted

On Tue, Sep 21, 2021 at 1:19 AM Lee Jones [off-list ref] wrote:

quoted

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

quoted

On 20/09/2021 21:03, Will McVicker wrote:

quoted

Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
be enabled by default via "default y if ARCH_EXYNOS" versus being
selected by the ARCH_EXYNOS config directly. This allows vendors to
disable these configs if they wish and provides additional flexibility
to modularize them in the presence of a generic kernel.

This is not true. Vendors cannot disable these options as they are not
visible.

Good point, well made.

quoted

Although I understand that Arnd prefers this way and I do not
object it, but your explanation is incorrect.

Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden
configs" part. I'll upload the series to include the fix that refactos
the Samsung SoC drivers menuconfig which will address that and allow
one to enable/disable those configs. I'm going to hold off though
until we hash out the rest of the discussion in the cover letter
email.

No, please first read our discussions, including Lee's and Geert's
comments. The drivers should not be converted to modules or made visible
if such configuration does not work. If it works, please describe your
testing setup.

Modules *should* work.  William is going to try it out.

Might need to lean-on for some testing on different H/W though.

I can help, few other folks from Samsung can help as well.

Thanks.  I'd really appreciate it.

quoted

quoted

All these drivers are *necessary* for a multiplatform kernel supporting
Exynos platforms, therefore disabling them does not make any sense (if
you support Exynos platform). If your kernel does not support Exynos
platform, just do not select ARCH_EXYNOS and problem disappears because
none of these drivers will be visible and selected.

Unless you describe here some out-of-tree kernel which wants
ARCH_EXYNOS, because vendor did not upstream it's code, but you do not
want existing Exynos upstream drivers. We do not support such
configuration. Please push your lovely vendor to work with upstream.
That's the only solution.

It's the third time this abuse re-usage of ARCH_EXYNOS appears and the
same as before - the vendor does not like to upstream stuff. There are
few guys trying to upstream recent Samsung SoC support by themself (ping
me for contacts if you would like to participate) but the one party
which should be doing it - the lovely vendor - does not actually
participate and instead sends ridiculous patches like this one here...
or like this [1] [2].

Nope, please work with upstreaming SoC support, instead of abusing
ARCH_EXYNOS for out of tree code from the vendor.

One of the on-going issues that GKI aims to solve pertains to the
disparity between what upstream engineers would like to be upstreamed
(i.e. everything) and what vendors can upstream (i.e. most things).

The old Open Source vs Business (i.e. products/real-life) struggle!

Vendors are not able to upstream all functionality right away, as it
would give away their perceived edge on the competition (i.e. other
vendors).  This is something we just have to accept as it will *never*
change.

Sure, I understand. Balance, compromise, not perfectness.

However now it is heavily in-balanced since vendor did upstream only one
change - UFS drivers for new SoC - since 2017. One change. Nothing else,
nothing for older SoC, nothing for newer.

All other work is done by the community, not by the vendor.

Not sure how to qualify Sam's Exynos850 work, but even if counting it,
there will be just two changes from vendor.

This is not acceptable, this is not a balanced approach.

Completely understand.  Been there, got frustrated by that!

However, GKI is your friend here, since it operates an upstream-first
philosophy.  Samsung would not be able to utilise GKI if its platform
wasn't supported by upstream.  Regardless of who did the work, (not my
concern at this point) the platform is supported in Mainline.

Volunteers (including Linaro) do a bunch of upstreaming on behalf of
vendors, including some of the very largest/most successful.
Sometimes that just the way it goes - try not to take it too
personally.

quoted

GKI attempts to solve this issue by providing a generic core
containing all of the elements required to get every supported
platform bootstrapped to a point where modules can be loaded and
additional functionality can be brought in.  GKI provides all of the
modules available from the upstream kernel BUT allows them to be
overwritten/swapped-out by modules containing code (new/shiny
unreleased value-add) that the vendors do not wish to share (yet).

Clever, eh!

As I've explained before, the trigger for all of this was
SERIAL_SAMSUNG which is required for early console on supported
Samsung platforms i.e. this symbol *has* to be built-in.  

Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary
for built-in only for debugging or development, not for real products.

Right.  And in the early stages, GKI is used for early (non-released)
H/W (this is also the part of the reason these differences can't be
upstreamed early/now/yet) and sometimes changes break things requiring
low-level debugging techniques to solve (inc. early console).

Unlike other drivers which have to be built-in, e.g. clocks or pinctrl,
or heavily tested whether setup from initrd works. Plus not breaking
distros who like to have everything as module (solution from Geert?)...

We don't know which drivers *need* to be built-in yet.

Clocks is probably not a good example even, since the power-on default
is most likely all-on, which is fine.  Pinctrl remains to be seen.

quoted

In order for
this to built-in ARCH_EXYNOS has to be enabled due to the listed
dependencies in Kconfig.  And since ARCH_EXYNOS 'selects' all of these
different extra symbols, it means they too will be built-in, meaning
that a) the core binary will be unnecessarily bloated and b) vendors
who wish to overwrite/replace this functionality with their
non-shareable value-add, are not able to do so.

I am sorry, but this is not reflecting status we want to have in
usptream. Everything selected by ARCH_EXYNOS *has to be selected* for
supported platforms. Since vendor does not contribute anything new
(except mentioned one work for UFS), we are not going to sacrifice
supported mainline platforms for a non-cooperative out-of-tree unknown
platforms.

The is the part of the discussion that is the most contentious.

Ideally we wouldn't have to enable any ARCH_* explicitly.  Greg has
mentioned this publicly on a number of discussions.  However, removing
the dependencies (from Kconfig in this case) is in contention with
other user's use-cases.  No one wants to be asked seemingly irrelevant
configuration questions during the config stages of a kernel build.

So we are forced to enable ARCH_* to have our requirements built-in
(ARCH_EXYNOS for SAMSUNG_SERIAL [early console] in this case).
Unfortunately, this comes with additional cruft that we *might* not
want (resulting in bloat) or that we wish to overwrite with more
featureful driver modules.  We can't do that if these features are
built-in.

Please don't make this discussion about particular vendors.  Bringing
in emotional feelings pertaining to specific companies or individuals
does not make for a quality level-headed technical discussion.

The principles I'm discussing here are vendor agnostic.

quoted

Going forward, it sounds like the best approach that will make
everyone happy, providing it's technically feasible, is to enable
these added (sometimes required, other times superfluous) symbols as
loadable modules.

Not entirely. What actually would make everyone happy and it is still
technically feasible is for a multi-billion company with thousands of
engineers to contribute something. Let's start with a little bit. From
billions of dollars and thousands of engineers we won't expect too much,
right?

I understand your frustration, but it's orthogonal to this discussion.

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