linux-kernel - Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABYd82bzKh=QQHyk-kPXekzCKx+Uy-z2TY5qAQQNfuew=h=O-w@mail.gmail.com>
Date:   Tue, 21 Sep 2021 10:58:28 -0700
From:   Will McVicker <willmcvicker@...gle.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Sylwester Nawrocki <s.nawrocki@...sung.com>,
        Tomasz Figa <tomasz.figa@...il.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Lee Jones <lee.jones@...aro.org>,
        Android Kernel Team <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>
Subject: Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default
 config logic

On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski
<krzysztof.kozlowski@...onical.com> wrote:
>
> On 21/09/2021 09:50, Geert Uytterhoeven wrote:
> > On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@...nel.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. 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.

I will update the series with my patch that refactors the Samsung SoC
drivers menuconfig to make these visible as well.

Thanks,
Will