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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 2 Oct 2021 10:47:13 +0900 From: Tomasz Figa <tomasz.figa@...il.com> To: Saravana Kannan <saravanak@...gle.com> Cc: Olof Johansson <olof@...om.net>, Arnd Bergmann <arnd@...db.de>, Geert Uytterhoeven <geert@...ux-m68k.org>, 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>, 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 Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs 2021年10月2日(土) 4:26 Saravana Kannan <saravanak@...gle.com>: > > On Fri, Oct 1, 2021 at 8:27 AM Olof Johansson <olof@...om.net> wrote: > > > > On Fri, Oct 1, 2021 at 2:01 AM Arnd Bergmann <arnd@...db.de> wrote: > > > > > > On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote: > > > > On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan <saravanak@...gle.com> wrote: > > > > > 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 :-(. > > > > > > There are a number of well-known examples even with 64-bit chips or > > > Cortex-A7/A15 based SoCs that can't use the architected timer, > > > irqchip or iommu. > > > > > > Apple M1, Broadcom BCM283x, Samsung Exynos5 and > > > some Hisilicon server parts come to mind, I'm sure there > > > are more. > > > > There's also more and more movement towards having coprocessors with > > standardized interfaces dealing with this functionality. We're > > currently at the point where they have coprocessors with > > non-standardized interfaces, and it's useful to keep encouraging > > convergence in this area to everybody's benefit. I don't find it > > particularly useful to make life easier for the custom solutions at > > the expense of others like this patchset does, when that's (just > > beyond? on?) the horizon. > > > > > > What are the plans for other architectures? > > > > I've seen similar patches being applied for e.g. MIPS. > > > > > > There is some work in the more actively maintained MIPS > > > platforms to make those behave more like Arm/powerpc/riscv/m68k > > > platforms, using a single image and moving drivers into modules. > > > Most MIPS platforms seem unlikely to get updated to this, > > > and will continue to require a SoC specific kernel binary forever, > > > similar to the renesas superh platforms. Most of the less > > > common architectures (arc, csky, hexagon, nios2, xtensa, > > > microblaze, nds32, openrisc, sparc/leon) are way behind that > > > though, and generally don't work at all without out-of-tree > > > code. > > > > One of the arguments for needing some of these core drivers in-kernel > > is that some platforms boot at very conservative DVFS operating > > points, to a degree that you really want to turn up the CPU clocks > > fairly early during boot. > > > > If you don't have the drivers built-in, you can't do that and/or you > > create possible fragile or awkward inter-module dependencies with > > deferred probing, etc. We do care about boot time enough to prefer to > > just build them in for this reason. > > Go look at a Pixel 5, we got this working just fine with all these > drivers as modules and we definitely care about boot time. You just > need to load your CPU freq driver and the other ones it needs early > on. And with fw_devlink=on (default in upstream), there's hardly any > deferred probing. > > > If vmlinux binary size is a concern, maybe it's time to consider > > splitting the drivers into a bare-minimum piece that's not a module > > for early setup, and the rest that can be loaded post-boot. > > Isn't this literally what I was suggesting with my > ARM64_MINIMAL_GENERIC_KERNEL suggestion? Build in all the bare minimum > drivers that are needed before module loading can happen? You'd just > select them all under that config. And any existing platform that > wants to use it would break up their drivers into modules and switch > to it. I think the point here is that pinctrl and clk are considered a part of "bare minimum" for Exynos.
Powered by blists - more mailing lists