Message-ID: <CABYd82b9wmzZHAQwBqn-6uJupEV=r6Zx7fiaz+o4Xxt8RQppUA@mail.gmail.com>
Date:   Thu, 30 Sep 2021 11:02:18 -0700
From:   Will McVicker <willmcvicker@...gle.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Lee Jones <lee.jones@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Russell King <linux@...linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Sylwester Nawrocki <s.nawrocki@...sung.com>,
        Tomasz Figa <tomasz.figa@...il.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Saravana Kannan <saravanak@...gle.com>,
        "Cc: Android Kernel" <kernel-team@...roid.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-rtc@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
        Olof Johansson <olof@...om.net>
Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

On Thu, Sep 30, 2021 at 9:26 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Lee,
>
> On Thu, Sep 30, 2021 at 6:21 PM Lee Jones <lee.jones@...aro.org> wrote:
> > On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:
> > > On Thu, Sep 30, 2021 at 3:29 PM Lee Jones <lee.jones@...aro.org> wrote:
> > > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > > On 30/09/2021 14:39, Lee Jones wrote:
> > > > > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > > >> On 30/09/2021 11:23, Lee Jones wrote:
> > > > > >>> [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
> > > > > >>>
> > > > > >>
> > > > > >> Side topic, why this patchset is in your scope or Will's/Google's scope?
> > > > > >> Just drop it from Android main kernel, it will not be your problem. I
> > > > > >> mean, really, you don't need this patchset in your tree at all. The only
> > > > > >> platform which needs it, the only platform which will loose something
> > > > > >> will be one specific vendor. Therefore this will be an incentive for
> > > > > >> them to join both discussions and upstream development. :)
> > > > > >
> > > > > > How would they fix this besides upstreaming support for unreleased
> > > > > > work-in-progress H/W?
> > > > > >
> > > > > > Haven't I explained this several times already? :)
> > > > >
> > > > > Either that way or the same as Will's doing but that's not my question.
> > > > > I understand you flush the queue of your GKI patches to be closer to
> > > > > upstream. Reduce the backlog/burden. you can achieve your goal by simply
> > > > > dropping such patch and making it not your problem. :)
> > > >
> > > > git reset --hard mainline/master   # job done - tea break  :)
> > > >
> > > > Seriously though, we wish to encourage the use of GKI so all vendors
> > > > can enjoy the benefits of more easily updateable/secure code-bases.
> > > >
> > > > I can't see how pushing back on seamlessly benign changes would
> > > > benefit them or anyone else.
> > >
> > > I like your wording ;-)
> > >
> > > Indeed, seamlessly benign changes, which are (1) not tested, and (2)
> > > some believed by the platform maintainer to break the platform.
> > > What can possibly go wrong? ;-)
> >
> > William has already shown a willingness to test the series.
>
> I'm looking forward to the results!
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Hi Krzysztof and Geert,

Thanks for all the responses! There are a few things I want to respond
to. Since this thread is 32 responses deep, I'm copying and pasting
the parts I'm responding to. I hope that isn't an issue.

>You are changing not default, but selectability which is part of the
>enforced configuration to make platforms working. The distros do not
>always choose defaults but rather all as modules.

I'm guessing you are referring to distros using the "allmodconfig". I
agree that this would affect their platforms in the sense that they
would get a module vs built-in, but obviously that is the choice they
are making by using "allmodconfig". I also agree that my changes
should not break any distros. I definitely don't want you or anyone
else to accept these without them being tested and verified.

>I don't understand the point (2) here. Anyone can use upstream kernel
>for supported and unsupported platforms. How upstream benefits from a
>change affecting supported platforms made for unsupported, downstream
>platforms.

We believe that if we make it easier for SoC vendors to directly use
the upstream kernel during bring-up and during the development stages
of their project, then that will decrease the friction of working with
upstream (less downstream changes) and increase the upstream
contributions. As mentioned in the LPC talk by Todd, the Android
kernel team is constantly pushing to reduce the number of out-of-tree
changes we carry so that we can ultimately use the upstream kernel
directly.

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

Saravana provided 2 platforms in his response. The first one is
hikey960 devboard and the second one is the Pixel 5 which uses the
Qualcomm sm7250 chipset. In particular the Pixel 5 is running a fully
modular kernel. It has 320+ modules including interrupt controllers,
timers, pinctrl and clocks.

To address your question regarding if Exynos is special? No, Exynos
isn't special. There is a long road ahead of us to get to where we'd
ultimately like to be and ARCH_EXYNOS happens to be along the way.
Currently, we are working through the arm64 ARCH_XXX configs that are
supported by Android to make sure that all drivers included by any
ARCH_XXX are modularized if they can be which benefits all parties.
>From my understanding upstream does support modularizing drivers and
we can help with that. I believe this also kind of addresses Geert's
comments regarding what a generic kernel is. We look at it as a kernel
that only includes the absolutely necessary SoC drivers as built-in.
Obviously we can't go back and change older hardware like Cortex A9 to
support this, but we can do our best to support future SoCs.

Lastly, you mentioned a couple of times that we should just disable
ARCH_EXYNOS and move on. At the moment we are not able to do that
because some SoC specific drivers actually do need to be built-in to
the kernel (tainting it's generic-ness unfortunately) and are
protected by these ARCH_XXX configs. One example that you or Geert
pointed out is the early console serial driver which Greg did try to
decouple from ARCH_EXYNOS but was turned down. There are likely other
reasons as well that I don't know of off hand.

I hope Lee and I answered all your questions. Ultimately, I think we
all understand what is being debated here and it sounds like we all
agree that we are okay with modules as long as (1) they are proven to
work as both built-in and as modules and (2) can't be disabled if they
are required by the platform, but can be built-in or modular. Let me
know if I misunderstood that.

Regarding the testing, I will look around for a devboard that I can
test my clock driver changes on since those are the most contested
ones. I obviously am not going to be able to find all the HW variants
you mentioned, but I will try to find an ARM64 Exynos7 or Exynos5433
devboard since my patchset only modifies the clocks for these SoCs
which seem to be the most contested. Once I provide some testing
results, I'm hoping someone upstream can help verify that on the other
affected hardware. Of course this will take some time though.

In the meantime, I will try to push some of these easier patches that
don't need extensive testing, but are required before modularizing the
drivers.

Thanks,
Will

Powered by blists - more mailing lists