From: Krzysztof Kozlowski <email@example.com> To: Lee Jones <firstname.lastname@example.org> Cc: Will McVicker <email@example.com>, Catalin Marinas <firstname.lastname@example.org>, Will Deacon <email@example.com>, Sylwester Nawrocki <firstname.lastname@example.org>, Tomasz Figa <email@example.com>, Chanwoo Choi <firstname.lastname@example.org>, Michael Turquette <email@example.com>, Stephen Boyd <firstname.lastname@example.org>, Linus Walleij <email@example.com>, Alessandro Zummo <firstname.lastname@example.org>, Alexandre Belloni <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs Date: Tue, 21 Sep 2021 10:25:41 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <YUmTwZPqrCfRMekd@google.com> On 21/09/2021 10:11, Lee Jones wrote: > On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote: > >> On 20/09/2021 21:03, Will McVicker wrote: >>> This patch series tries to address the issue of ARCH_EXYNOS force selecting >>> a handful of drivers without allowing the vendor to override any of the >>> default configs. This takes away from the flexibilty of compiling a generic >>> kernel with exynos kernel modules. For example, it doesn't allow vendors to >>> modularize these drivers out of the core kernel in order to share a generic >>> kernel image across multiple devices that require device-specific kernel >>> modules. >> >> You do not address the issue in these patches. The problem you describe >> is that drivers are not modules and you are not changing them into modules. > > The wording is unfortunate. The reason for this change doesn't have > much to do with kernel modules. > > Let's go back in time 18 months or so when Greg KH submitted this  > patch, which you Acked. Greg was trying to solve the problem of not > having to enable ARCH_EXYNOS on kernels which are designed to be > platform agnostic (sometimes called Generic Kernels). For some reason > SERIAL_SAMSUNG is the only symbol with these dependencies, so the > solution seemed simple and straight forward at the time. > > However, For sound reasons Geert NACKed the patch. > > Quoting from  he says: > > "A generic kernel will include Samsung SoC support, hence > PLAT_SAMSUNG or ARCH_EXYNOS will be enabled." Yes, it's correct reasoning. There is also one more use-case - non-upstreamed (out of tree) platform which wants to use Exynos-specific drivers. Something like was happening with Apple M1 except that it got upstreamed and we do not care much about out-of-tree. > > However, since the entry for ARCH_EXYNOS *insists* on building-in a > bunch of other symbols (via 'select') which will be unused in most > cases, this is not a currently acceptable approach for many Generic > Kernels due to size constraints. In the mainline kernel there is no such use case. If you want to have Exynos-whatever-driver (e.g. SERIAL_SAMSUNG or S3C RTC), you should select ARCH_EXYNOS because otherwise it does not make any sense. Zero sense. Such kernel won't work. It makes sense only if there is some other work, hidden here, where someone might want to have SERIAL_SAMSUNG or S3C RTC without ARCH_EXYNOS. Although GKI is not that work because GKI kernel will select ARCH_EXYNOS. It must select ARCH_EXYNOS if it wants to support Exynos platforms. Therefore I expect first to bring this "some other work, hidden here" to broader audience, so we can review its use case. > > What this patch does is migrates those symbols from being 'select'ed > (always built-in with no recourse) to 'default y'. Where the former > cannot be over-ridden, but the latter can be via a vendor's > defconfig/fragment. It cannot be overridden by vendor fragment because options are not visible. You cannot change them. The patch does nothing in this regard (making them selectable/possible to disable), which is why I complained. > > I doubt many (any?) of these symbols can be converted to kernel > modules anyway, as they are required very early on in the boot > sequence. True, some could, some not. Also some platforms are set up via bootloader, so actually could "survive" till module is loaded from some initrd. Best regards, Krzysztof
next prev parent reply other threads:[~2021-09-21 8:25 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-20 19:03 Will McVicker 2021-09-20 19:03 ` [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic Will McVicker 2021-09-21 7:29 ` Krzysztof Kozlowski 2021-09-21 7:50 ` Geert Uytterhoeven 2021-09-21 8:35 ` Krzysztof Kozlowski 2021-09-21 17:58 ` Will McVicker 2021-09-21 18:04 ` Krzysztof Kozlowski 2021-09-23 12:57 ` Lee Jones 2021-09-23 13:27 ` Krzysztof Kozlowski 2021-09-23 14:18 ` Lee Jones 2021-09-23 16:27 ` Krzysztof Kozlowski 2021-09-23 16:30 ` Krzysztof Kozlowski 2021-09-20 19:03 ` [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG " Will McVicker 2021-09-20 20:57 ` Will McVicker 2021-09-21 7:23 ` Krzysztof Kozlowski 2021-09-21 8:19 ` Lee Jones 2021-09-21 17:45 ` Will McVicker 2021-09-21 18:20 ` Krzysztof Kozlowski 2021-09-23 12:39 ` Lee Jones 2021-09-23 12:57 ` Krzysztof Kozlowski 2021-09-23 13:41 ` Lee Jones 2021-09-23 16:19 ` Geert Uytterhoeven 2021-09-23 18:05 ` Geert Uytterhoeven 2021-09-20 19:03 ` [PATCH v1 3/4] pinctrl: samsung: change PINCTRL_EXYNOS " Will McVicker 2021-09-21 7:27 ` Krzysztof Kozlowski 2021-09-21 8:18 ` Lee Jones 2021-09-23 21:52 ` Linus Walleij 2021-09-21 7:08 ` [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs Lee Jones 2021-09-21 7:19 ` Krzysztof Kozlowski 2021-09-21 7:22 ` Krzysztof Kozlowski 2021-09-21 8:11 ` Lee Jones 2021-09-21 8:25 ` Krzysztof Kozlowski [this message] 2021-09-21 8:41 ` Lee Jones 2021-09-25 2:17 ` Saravana Kannan 2021-09-27 8:08 ` Krzysztof Kozlowski 2021-09-27 8:16 ` Geert Uytterhoeven 2021-09-27 18:07 ` Saravana Kannan 2021-09-27 19:54 ` Geert Uytterhoeven
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs' \ /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
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).