Date: Sun, 29 May 2022 14:21:33 +0100 From: Marc Zyngier <maz@...nel.org> To: Arnd Bergmann <arnd@...nel.org> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, linux-arch <linux-arch@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Yoshinori Sato <ysato@...rs.sourceforge.jp>, Palmer Dabbelt <palmer@...belt.com>, Masahiro Yamada <masahiroy@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Huacai Chen <chenhuacai@...ngson.cn>, WANG Xuerui <kernel@...0n.name>, libc-alpha@...rceware.org, musl@...ts.openwall.com, ardb@...nel.org, linux-acpi@...r.kernel.org, linux-pci@...r.kernel.org Subject: Re: [GIT PULL] asm-generic changes for 5.19 On Sun, 29 May 2022 12:24:29 +0100, Arnd Bergmann <arnd@...nel.org> wrote: > > On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <arnd@...nel.org> wrote: > > - A series to add a generic ticket spinlock that can be shared by most > > architectures with a working cmpxchg or ll/sc type atomic, including > > the conversion of riscv, csky and openrisc. This series is also a > > prerequisite for the loongarch64 architecture port that will come as > > a separate pull request. > > An update on Loongarch: I was originally planning to send Linus a > pull request with > the branch with the contents from > > https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next > > but I saw that this includes both the architecture code and some > device drivers (irqchip, pci, acpi) that are essential for the > kernel to actually boot. At least the irqchip driver has not passed > review because it uses a nonstandard way to integrate into ACPI, and > the PCI stuff may or may not be ready but has no Reviewed-by or > Acked-by tags from the maintainers. I clearly don't want to bypass > the subsystem maintainers on those drivers by sending a pull request > for the current branch. It seems that there is now a new contributor on the irqchip front, and the current approach *should* be better than the "copy MIPS and run" approach that was previously taken. I'm still to find time to review the new series (I just came back from a week off), but hopefully next week. > My feeling is that there is also no point in merging a port without > the drivers as it cannot work on any hardware. On the other hand, > the libc submissions (glibc and musl) are currently blocked while > they are waiting for the kernel port to get merged. I'd tend to agree. But if on the other hand the userspace ABI is clearly defined, I think it could make sense to go for it (if I remember well, we merged arm64 without any support irqchip support, and the arm64 GIC support appeared later in the game). Thanks, M. -- Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.