linux-kernel - Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH

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]

Date:   Fri, 1 Oct 2021 10:19:58 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Olof Johansson <olof@...om.net>,
        Will McVicker <willmcvicker@...gle.com>,
        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>,
        Lee Jones <lee.jones@...aro.org>,
        "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>
Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

Hi Saravana,

On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan <saravanak@...gle.com> wrote:
> I skimmed through the emails and you all make a lot of good points. It
> looks like you all at least like the idea of being able to have a
> minimal generic kernel where everything that can be a module is a
> module. Please correct me if I'm wrong on that.
>
> I was thinking about this patch series and I was wondering if it'd be
> good to come at it from the other end. Instead of taking the mostly
> builtin generic kernel and trying to rip out drivers as modules (and
> not having enough hardware to test them all) and hitting all these
> issues, we could come at it from the other end.
>
> A config like ARM64_MINIMAL_GENERIC_KERNEL that's off by default. But
> if it's selected, all the "selects" done by the various ARCH_XXX are
> not done any more. Something like:
>
> ARCH_XXX
>     select XXX_CLK1 if !ARM64_MINIMAL_GENERIC_KERNEL
>     select XXX_PINCTRL1 if !ARM64_MINIMAL_GENERIC_KERNEL
>
> ARCH_YYY
>     select YYY_CLK1 if !ARM64_MINIMAL_GENERIC_KERNEL
>     select YYY_PINCTRL1 if !ARM64_MINIMAL_GENERIC_KERNEL
>
> And ARM64_MINIMAL_GENERIC_KERNEL itself would select the absolutely
> mandatory stuff that can never be made into a module like the GIC,
> architectured timer (as Geert mentioned) and UART early console
> driver. I'm not sure if ARM32 has an equivalent to the standardized

While the UART early console can work (assuming the related hardware
setup has been done by the boot loader), the actual serial driver
usually cannot, as it relies on clocks, PM Domains, pin control, which
won't be available until the corresponding modular drivers are loaded.
Actually earlycon is a debug feature, so I'm wondering if you actually
want that in your GKI kernel?

> GIC and arch timer. Basically the minimal kernel would need a timer
> for the scheduler tick and IRQ controller to get the timer IRQ and the
> fixed clock driver if the archtimer uses one to get its frequency and
> the early UART console is pointless as a module (so build it in to
> allow debugging/development).
>
> And then all new drivers, we should make sure are implemented as
> tristate drivers. And we can go back and slowly work on converting
> existing drivers to modules (community effort -- not one person or
> entity) -- at least the ones where the author has hardware or ones
> where the change is very likely to be correct and someone else is
> willing to test it. We'll never be able to support some/all ARM32 (do
> they even have a GIC/arch timer standard?), but at least for ARM64,
> this seems like a viable goal.

Cortex-A7/A15 and later have GIC and architectured timer, so it should
work for contemporary systems.
Cortex-A9 systems may have GIC, and TWD and/or Global Timer (but I've
seen SoCs where the interrupt for the latter was not wired :-(.

What are the plans for other architectures?
I've seen similar patches being applied for e.g. MIPS.

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