From: Lee Jones <lee.jones@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
Will McVicker <willmcvicker@google.com>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Tomasz Figa <tomasz.figa@gmail.com>,
Chanwoo Choi <cw00.choi@samsung.com>,
Linus Walleij <linus.walleij@linaro.org>,
Alessandro Zummo <a.zummo@towertech.it>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
John Stultz <john.stultz@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Saravana Kannan <saravanak@google.com>,
"Cc: Android Kernel" <kernel-team@android.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
linux-clk <linux-clk@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
linux-rtc@vger.kernel.org, Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs
Date: Thu, 30 Sep 2021 10:30:24 +0100 [thread overview]
Message-ID: <YVWDsFE7qyH6AwxR@google.com> (raw)
In-Reply-To: <CAK8P3a0zezKvexqvL29Oc44uQq-8QG7LwZy31VYJuYAYbh-Utw@mail.gmail.com>
On Thu, 30 Sep 2021, Arnd Bergmann wrote:
> On Thu, Sep 30, 2021 at 8:15 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@canonical.com> wrote:
> > On 29/09/2021 21:48, Will McVicker wrote:
> > > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:
> > >> What is more, it seems you entirely ignored Geert's comments. I pointed
> > >> attention to it last time and you just said you will send v2 instead of
> > >> joining discussion.
> > >>
> > >> It's a NAK for this reason - ignoring what Geert brought: you just broke
> > >> distro configs for Exynos.
> > >
> > > First off I did want to chime into the discussion from the previous
> > > patchset, but I felt that Lee and Saravana addressed all your concerns
> > > regarding the intent and feasibility. You also made it clear what the
> > > next steps were that I needed to take.
> >
> > One of the steps was problem with distros using everything as modules.
> > They should not receive these drivers as modules.
> > 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).
>
> Agreed. I absolutely love the work of the GKI developers to turn more
> drivers into loadable modules, but the "correctness-first" principle is
> not up for negotiation. If you are uncomfortable with the code or the
> amount of testing because you think it breaks something, you should
> reject the patches. Moving core platform functionality is fundamentally
> hard and it can go wrong in all possible ways where it used to work
> by accident because the init order was fixed.
>
> > >> Please also explain why Exynos is so special that we deviate from the
> > >> policy for all SoC that critical SoC-related drivers have to be enabled
> > >> (built-in or as module).
> > >
> > > I am not actually changing ANY default build configurations here and
> > > I'm not removing any existing configuration.
> >
> > 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. Kernel configuration
> > is huge and complex, so by mistake they could now even disable
> > potentially essential driver. There is no need to disable for example
> > essential clock driver on a supported Exynos platform.
>
> I'm not overly worried about the defaults. If the drivers work as loadable
> modules, I'm happy with them being loadable modules in distros.
> If they don't work this way, then the patches are broken and should
> not get merged.
>
> I don't even mind having essential drivers that can be turned off,
> since we already have a ton of those (e.g. serial ports on most platforms).
> It's up to distros to know which drivers to enable, though having
> either reasonable defaults or fail-safe Kconfig dependencies (e.g.
> making it impossible to turn off but allowing modules) is clearly
> best.
>
> > > I tried to make it pretty
> > > clear in my original patch series commit messages that none of my
> > > changes modify the default behavior. The .config is the same with and
> > > without my patches. All of these drivers remain enabled as built-in.
> > > So if there is a distro that requires all of these drivers to be
> > > built-in, then they can continue as is without noticing any
> > > difference. IOW, all of these changes are/should be backwards
> > > compatible.
> >
> > I was not referring to default neither to backwards compatibility.
> > Please explain why Exynos is special that it does not require essential
> > drivers to be selected as built-in. For example why aren't same changes
> > done for Renesas?
> >
> > Is that now a new global approach that all SoC drivers should be allowed
> > to be disabled for ARCH_XXX?
>
> I wouldn't enforce it either way across platforms. I would prefer drivers
> to be loadable modules where possible (and tested), rather than
> selected by the platform Kconfig. If you want to ensure the exynos
> drivers are impossible to turn into a nonworking state, that's up to you.
>
> > > You said that upstream supports a generic
> > > kernel, but I argue that the upstream "generic" arm64 kernel can't be
> > > considered generic if it builds in SoC specific drivers that can be
> > > modules.
> >
> > Good point, but since having them as modules was not tested, I consider
> > it as theoretical topic.
>
> I actually disagree strongly with labelling the kernel as "non-generic"
> just because it requires platform specific support to be built-in rather than
> a loadable module. This has never been possible on any platform
> I'm aware of, and likely never will, except for minor variations of
> an existing platform.
>
> Look at x86 as an example: there are less than a dozen SoC platforms
> supported and they are incredibly similar hardware-wise, but the kernel
> is anything but "generic" in the sense that was mentioned above.
> Most of the platform specific drivers in arch/x86/platform and the
> corresponding bits in drivers/{irqchip,clocksource,iommu} are always
> built-in, and a lot more is hardwired in architecture code as PCI
> quirks or conditional on cpuid or dmi firmware checks.
>
> > >> Even if there was, I think it is good to have dependencies like
> > >> ARCH_EXYNOS, as they let us partition the (19000, as Arnd said recently)
> > >> Kconfig symbols into better manageable groups. Without these, we cannot
> > >> do better than "depends on ARM || ARM64 || COMPILE_TEST".
> > >
> > > My patch series still keeps the dependencies on ARCH_EXYNOS. I am
> > > totally fine with "depends on ARCH_EXYNOS" and totally fine with
> > > "default ARCH_EXYNOS". The problem we have is that ARCH_EXYNOS
> > > forcefully selects SoC specific drivers to be built-in because it just
> > > adds more and more SoC-specific drivers to a generic kernel.
> >
> > The selected drivers are essential for supported platforms. We don't
> > even know what are these unsupported, downstream platforms you want
> > customize kernel for. They cannot be audited, cannot be compared.
> >
> > 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.
> >
> > If you want to change it, let me paste from previous discussion:
> >
> > Affecting upstream platforms just because vendor/downstream does not
> > want to mainline some code is unacceptable. Please upstream your drivers
> > and DTS.
>
> Agreed. I understand that it would be convenient for SoC vendors to
> never have to upstream their platform code again, and that Android
> would benefit from this in the short run.
>
> From my upstream perspective, this is absolutely a non-goal. If it becomes
> easier as a side-effect of making the kernel more modular, that's fine.
> The actual goal should be to get more people to contribute upstream so
> devices run code that has been reviewed and integrated into new kernels.
>
> > > I know you are asking for me to only push changes that have proven to
> > > work.
> >
> > Yep, tested.
>
> I'm generally fine with "obviously correct" ones as well, but it's up to
> you to categorize them ;-)
Arnd,
FWIW, I agree with all of your points.
Krzysztof,
It sounds like a lack of testing is your main concern.
How can I help here? What H/W do I need to be able to fully test this?
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2021-09-30 9:30 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-28 23:56 [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs Will McVicker
2021-09-28 23:56 ` [PATCH v2 01/12] arm64: don't have ARCH_EXYNOS select EXYNOS_CHIPID Will McVicker
2021-09-29 13:58 ` (subset) " Krzysztof Kozlowski
2021-09-29 14:00 ` Krzysztof Kozlowski
2021-09-28 23:56 ` [PATCH v2 02/12] timekeeping: add API for getting timekeeping_suspended Will McVicker
2021-09-29 3:42 ` John Stultz
2021-09-29 20:01 ` Will McVicker
2021-09-29 20:46 ` John Stultz
2021-09-30 18:31 ` Will McVicker
2021-09-28 23:56 ` [PATCH v2 03/12] clk: samsung: add support for CPU clocks Will McVicker
2021-09-28 23:56 ` [PATCH v2 04/12] clk: samsung: exynos5433: update apollo and atlas clock probing Will McVicker
2021-09-28 23:56 ` [PATCH v2 05/12] clk: export __clk_lookup Will McVicker
2021-10-08 4:31 ` Stephen Boyd
2021-09-28 23:56 ` [PATCH v2 06/12] clk: samsung: modularize exynos arm64 clk drivers Will McVicker
2021-09-28 23:56 ` [PATCH v2 07/12] clk: samsung: set exynos arm64 clk driver as tristate Will McVicker
2021-09-29 13:09 ` Krzysztof Kozlowski
2021-09-28 23:56 ` [PATCH v2 08/12] pinctrl: samsung: modularize the ARM and ARM64 pinctrls Will McVicker
2021-09-29 2:01 ` Chanho Park
2021-09-28 23:56 ` [PATCH v2 09/12] pinctrl: samsung: set PINCTRL_EXYNOS and PINCTRL_SAMSUNG as tristate Will McVicker
2021-09-28 23:56 ` [PATCH v2 10/12] soc: samsung: pmu: modularize the Exynos ARMv8 PMU driver Will McVicker
2021-09-29 13:11 ` Krzysztof Kozlowski
2021-09-28 23:56 ` [PATCH v2 11/12] soc: samsung: pm_domains: modularize EXYNOS_PM_DOMAINS Will McVicker
2021-09-29 13:36 ` Krzysztof Kozlowski
2021-09-28 23:56 ` [PATCH v2 12/12] ARM: rtc: remove HAVE_S3C_RTC in favor of direct dependencies Will McVicker
2021-09-29 11:52 ` Alexandre Belloni
2021-09-29 13:02 ` [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs Krzysztof Kozlowski
2021-09-29 19:48 ` Will McVicker
2021-09-30 6:14 ` Krzysztof Kozlowski
2021-09-30 9:01 ` Arnd Bergmann
2021-09-30 9:30 ` Lee Jones [this message]
2021-09-30 10:33 ` Krzysztof Kozlowski
2021-09-30 12:34 ` Lee Jones
2021-09-30 12:38 ` Krzysztof Kozlowski
2021-09-30 10:05 ` Geert Uytterhoeven
2021-09-30 9:23 ` Lee Jones
2021-09-30 10:17 ` Geert Uytterhoeven
2021-09-30 10:56 ` Lee Jones
2021-09-30 11:25 ` Geert Uytterhoeven
2021-09-30 12:08 ` Lee Jones
2021-09-30 16:09 ` Geert Uytterhoeven
2021-09-30 10:52 ` Krzysztof Kozlowski
2021-09-30 12:32 ` Lee Jones
2021-09-30 11:01 ` Tomasz Figa
2021-09-30 11:27 ` Geert Uytterhoeven
2021-09-30 11:51 ` Lee Jones
2021-09-30 12:10 ` Tomasz Figa
2021-09-30 12:15 ` Krzysztof Kozlowski
2021-09-30 12:45 ` Lee Jones
2021-10-01 4:01 ` Christoph Hellwig
2021-10-01 4:52 ` Saravana Kannan
2021-10-01 4:55 ` Christoph Hellwig
2021-09-30 12:21 ` Krzysztof Kozlowski
2021-09-30 12:39 ` Lee Jones
2021-09-30 13:08 ` Krzysztof Kozlowski
2021-09-30 13:29 ` Lee Jones
2021-09-30 16:12 ` Geert Uytterhoeven
2021-09-30 16:21 ` Lee Jones
2021-09-30 16:26 ` Geert Uytterhoeven
2021-09-30 18:02 ` Will McVicker
2021-10-01 4:04 ` Christoph Hellwig
2021-10-01 4:52 ` Olof Johansson
2021-10-01 5:23 ` Saravana Kannan
2021-10-01 5:35 ` Olof Johansson
2021-10-01 5:59 ` Will McVicker
2021-10-01 8:01 ` Krzysztof Kozlowski
2021-10-01 6:02 ` Saravana Kannan
2021-10-01 6:27 ` Olof Johansson
2021-10-01 6:30 ` Olof Johansson
2021-10-01 12:00 ` Arnd Bergmann
2021-10-01 12:31 ` Lee Jones
2021-10-01 15:43 ` Olof Johansson
2021-10-01 11:38 ` Linus Walleij
2021-10-01 11:59 ` Geert Uytterhoeven
2021-10-01 15:59 ` Olof Johansson
2021-10-01 16:51 ` Will McVicker
2021-10-01 17:15 ` Olof Johansson
2021-10-01 17:48 ` Will McVicker
2021-10-01 8:19 ` Geert Uytterhoeven
2021-10-01 9:00 ` Arnd Bergmann
2021-10-01 15:27 ` Olof Johansson
2021-10-01 19:26 ` Saravana Kannan
2021-10-02 1:47 ` Tomasz Figa
2021-10-02 21:03 ` Olof Johansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YVWDsFE7qyH6AwxR@google.com \
--to=lee.jones@linaro.org \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=cw00.choi@samsung.com \
--cc=geert@linux-m68k.org \
--cc=john.stultz@linaro.org \
--cc=kernel-team@android.com \
--cc=krzysztof.kozlowski@canonical.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mturquette@baylibre.com \
--cc=olof@lixom.net \
--cc=s.nawrocki@samsung.com \
--cc=saravanak@google.com \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
--cc=tomasz.figa@gmail.com \
--cc=will@kernel.org \
--cc=willmcvicker@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).