From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> To: Will McVicker <willmcvicker@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Sylwester Nawrocki <s.nawrocki@samsung.com>, Tomasz Figa <tomasz.figa@gmail.com>, Chanwoo Choi <cw00.choi@samsung.com>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Lee Jones <lee.jones@linaro.org>, Android Kernel Team <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> Subject: Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic Date: Tue, 21 Sep 2021 20:04:23 +0200 [thread overview] Message-ID: <001cd621-53d1-fe22-0eaa-d13137827297@canonical.com> (raw) In-Reply-To: <CABYd82bzKh=QQHyk-kPXekzCKx+Uy-z2TY5qAQQNfuew=h=O-w@mail.gmail.com> On 21/09/2021 19:58, Will McVicker wrote: > On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski > <krzysztof.kozlowski@canonical.com> wrote: >> >> On 21/09/2021 09:50, Geert Uytterhoeven wrote: >>> On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>> On 20/09/2021 21:03, Will McVicker wrote: >>>>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config >>>>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a >>>>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable >>>>> or modularize this driver. >>>> >>>> The clock drivers are essential, you cannot disable them for a generic >>>> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms. >>> >>> Obviously it's not gonna work if the clock driver is not enabled >>> at all. But does it work if you make the clock driver modular, and >>> put it with all other essential driver modules in initramfs? Debugging >>> would be hard, as the serial console driver also relies on clocks >>> and PM Domains etc. >> >> The kernel could boot without clock drivers (default settings from >> bootloader), probe clocks from initramfs and proceed with rootfs from >> eMMC/SD/net. >> >> In theory. >> >> However I have no reports that it ever worked. If there is such working >> upstream configuration, I don't mind here. Just please explain this in >> the commit msg. >> >>> >>> If not, this patch should be NAKed, until it works with a modular >>> clock driver. >>> >>> If yes, perhaps another line should be added (_before_ the other line)? >>> >>> + default m if ARCH_EXYNOS && MODULES >>> default y if ARCH_EXYNOS >>> >>> However, many developers may want MODULES=y, but not want to bother >>> with an initramfs. So perhaps we need a new symbol >>> MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the >>> driver default to m if that is enabled? >> >> Yeah, that's indeed a problem to solve. For most users (and distros) >> building kernel for Exynos this should be built-in by default. >> >> Anyway, the option is non-selectable so it cannot be converted to "m" or >> disabled. And this is claimed in the commit msg: >> "provide flexibilty for vendors to disable or modularize this driver." >> >> The commit does not achieve it. >> >> Best regards, >> Krzysztof > > Thanks for the reviews! As Lee has explained in his replies, the > intent of this series is to provide config flexibility to create a > defconfig that allows us to move out SoC specific drivers in order to > create a generic kernel that can be used across multiple devices with > different SoCs. That's quite generic statement... or let me put it that way - we already have this ability to create a generic kernel supporting different SoCs. Exynos and other ARMv7 and ARMv8 platforms are multiplatform. Task is done. Please be more specific about use case and describe what exactly in current upstream multiplatform kernel is missing, what is not multiplatform enough. > I'm sorry I added confusion by mentioning > modularization. All of these drivers that I am modifying in this > series can be modularized which is an ongoing effort, but is not > addressed here and I don't believe that modularizing them should be a > requirement before supporting enabling/disabling them. Since the disabling the driver for a kernel supporting Exynos does not make any sense, then making it at least modular unfortunately it is a requirement. > I will update the series with my patch that refactors the Samsung SoC > drivers menuconfig to make these visible as well. I would first recommend to really describe your use case because my questions about this are still unanswered. Best regards, Krzysztof
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> To: Will McVicker <willmcvicker@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Sylwester Nawrocki <s.nawrocki@samsung.com>, Tomasz Figa <tomasz.figa@gmail.com>, Chanwoo Choi <cw00.choi@samsung.com>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Lee Jones <lee.jones@linaro.org>, Android Kernel Team <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> Subject: Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic Date: Tue, 21 Sep 2021 20:04:23 +0200 [thread overview] Message-ID: <001cd621-53d1-fe22-0eaa-d13137827297@canonical.com> (raw) In-Reply-To: <CABYd82bzKh=QQHyk-kPXekzCKx+Uy-z2TY5qAQQNfuew=h=O-w@mail.gmail.com> On 21/09/2021 19:58, Will McVicker wrote: > On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski > <krzysztof.kozlowski@canonical.com> wrote: >> >> On 21/09/2021 09:50, Geert Uytterhoeven wrote: >>> On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>> On 20/09/2021 21:03, Will McVicker wrote: >>>>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config >>>>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a >>>>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable >>>>> or modularize this driver. >>>> >>>> The clock drivers are essential, you cannot disable them for a generic >>>> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms. >>> >>> Obviously it's not gonna work if the clock driver is not enabled >>> at all. But does it work if you make the clock driver modular, and >>> put it with all other essential driver modules in initramfs? Debugging >>> would be hard, as the serial console driver also relies on clocks >>> and PM Domains etc. >> >> The kernel could boot without clock drivers (default settings from >> bootloader), probe clocks from initramfs and proceed with rootfs from >> eMMC/SD/net. >> >> In theory. >> >> However I have no reports that it ever worked. If there is such working >> upstream configuration, I don't mind here. Just please explain this in >> the commit msg. >> >>> >>> If not, this patch should be NAKed, until it works with a modular >>> clock driver. >>> >>> If yes, perhaps another line should be added (_before_ the other line)? >>> >>> + default m if ARCH_EXYNOS && MODULES >>> default y if ARCH_EXYNOS >>> >>> However, many developers may want MODULES=y, but not want to bother >>> with an initramfs. So perhaps we need a new symbol >>> MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the >>> driver default to m if that is enabled? >> >> Yeah, that's indeed a problem to solve. For most users (and distros) >> building kernel for Exynos this should be built-in by default. >> >> Anyway, the option is non-selectable so it cannot be converted to "m" or >> disabled. And this is claimed in the commit msg: >> "provide flexibilty for vendors to disable or modularize this driver." >> >> The commit does not achieve it. >> >> Best regards, >> Krzysztof > > Thanks for the reviews! As Lee has explained in his replies, the > intent of this series is to provide config flexibility to create a > defconfig that allows us to move out SoC specific drivers in order to > create a generic kernel that can be used across multiple devices with > different SoCs. That's quite generic statement... or let me put it that way - we already have this ability to create a generic kernel supporting different SoCs. Exynos and other ARMv7 and ARMv8 platforms are multiplatform. Task is done. Please be more specific about use case and describe what exactly in current upstream multiplatform kernel is missing, what is not multiplatform enough. > I'm sorry I added confusion by mentioning > modularization. All of these drivers that I am modifying in this > series can be modularized which is an ongoing effort, but is not > addressed here and I don't believe that modularizing them should be a > requirement before supporting enabling/disabling them. Since the disabling the driver for a kernel supporting Exynos does not make any sense, then making it at least modular unfortunately it is a requirement. > I will update the series with my patch that refactors the Samsung SoC > drivers menuconfig to make these visible as well. I would first recommend to really describe your use case because my questions about this are still unanswered. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-09-21 18:04 UTC|newest] Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-20 19:03 [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs Will McVicker 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-20 19:03 ` Will McVicker 2021-09-21 7:29 ` Krzysztof Kozlowski 2021-09-21 7:29 ` Krzysztof Kozlowski 2021-09-21 7:50 ` Geert Uytterhoeven 2021-09-21 7:50 ` Geert Uytterhoeven 2021-09-21 8:35 ` Krzysztof Kozlowski 2021-09-21 8:35 ` Krzysztof Kozlowski 2021-09-21 17:58 ` Will McVicker 2021-09-21 17:58 ` Will McVicker 2021-09-21 18:04 ` Krzysztof Kozlowski [this message] 2021-09-21 18:04 ` Krzysztof Kozlowski 2021-09-23 12:57 ` Lee Jones 2021-09-23 12:57 ` Lee Jones 2021-09-23 13:27 ` Krzysztof Kozlowski 2021-09-23 13:27 ` Krzysztof Kozlowski 2021-09-23 14:18 ` Lee Jones 2021-09-23 14:18 ` Lee Jones 2021-09-23 16:27 ` Krzysztof Kozlowski 2021-09-23 16:27 ` Krzysztof Kozlowski 2021-09-23 16:30 ` 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 19:03 ` Will McVicker 2021-09-20 20:57 ` Will McVicker 2021-09-20 20:57 ` Will McVicker 2021-09-21 7:23 ` Krzysztof Kozlowski 2021-09-21 7:23 ` Krzysztof Kozlowski 2021-09-21 8:19 ` Lee Jones 2021-09-21 8:19 ` Lee Jones 2021-09-21 17:45 ` Will McVicker 2021-09-21 17:45 ` Will McVicker 2021-09-21 18:20 ` Krzysztof Kozlowski 2021-09-21 18:20 ` Krzysztof Kozlowski 2021-09-23 12:39 ` Lee Jones 2021-09-23 12:39 ` Lee Jones 2021-09-23 12:57 ` Krzysztof Kozlowski 2021-09-23 12:57 ` Krzysztof Kozlowski 2021-09-23 13:41 ` Lee Jones 2021-09-23 13:41 ` Lee Jones 2021-09-23 16:19 ` Geert Uytterhoeven 2021-09-23 16:19 ` Geert Uytterhoeven 2021-09-23 18:05 ` 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-20 19:03 ` Will McVicker 2021-09-21 7:27 ` Krzysztof Kozlowski 2021-09-21 7:27 ` Krzysztof Kozlowski 2021-09-21 8:18 ` Lee Jones 2021-09-21 8:18 ` Lee Jones 2021-09-23 21:52 ` Linus Walleij 2021-09-23 21:52 ` Linus Walleij 2021-09-20 19:03 ` [PATCH v1 4/4] rtc: change HAVE_S3C_RTC " Will McVicker 2021-09-20 19:03 ` Will McVicker 2021-09-20 20:05 ` Alexandre Belloni 2021-09-20 20:05 ` Alexandre Belloni 2021-09-21 7:36 ` Krzysztof Kozlowski 2021-09-21 7:36 ` Krzysztof Kozlowski 2021-09-21 7:08 ` [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs Lee Jones 2021-09-21 7:08 ` Lee Jones 2021-09-21 7:19 ` Krzysztof Kozlowski 2021-09-21 7:19 ` Krzysztof Kozlowski 2021-09-21 7:22 ` Krzysztof Kozlowski 2021-09-21 7:22 ` Krzysztof Kozlowski 2021-09-21 8:11 ` Lee Jones 2021-09-21 8:11 ` Lee Jones 2021-09-21 8:25 ` Krzysztof Kozlowski 2021-09-21 8:25 ` Krzysztof Kozlowski 2021-09-21 8:41 ` Lee Jones 2021-09-21 8:41 ` Lee Jones 2021-09-25 2:17 ` Saravana Kannan 2021-09-25 2:17 ` Saravana Kannan 2021-09-27 8:08 ` Krzysztof Kozlowski 2021-09-27 8:08 ` Krzysztof Kozlowski 2021-09-27 8:16 ` Geert Uytterhoeven 2021-09-27 8:16 ` Geert Uytterhoeven 2021-09-27 18:07 ` Saravana Kannan 2021-09-27 18:07 ` Saravana Kannan 2021-09-27 19:54 ` Geert Uytterhoeven 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 \ --in-reply-to=001cd621-53d1-fe22-0eaa-d13137827297@canonical.com \ --to=krzysztof.kozlowski@canonical.com \ --cc=catalin.marinas@arm.com \ --cc=cw00.choi@samsung.com \ --cc=geert@linux-m68k.org \ --cc=kernel-team@android.com \ --cc=lee.jones@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=mturquette@baylibre.com \ --cc=s.nawrocki@samsung.com \ --cc=sboyd@kernel.org \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.