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 [off-list ref] 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@linux-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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel