Re: [GIT PULL] asm-generic changes for 5.19

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/29/22 19:24, Arnd Bergmann wrote:
On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <arnd@xxxxxxxxxx> 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.

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.

(CC-ing Jianmin Lv as he is apparently the person responsible for the majority of irqchip changes, which are arguably the center of the whole controversy; and Jiaxun Yang, author of the original Loongson MIPS IRQ scheme, carried over to the LoongArch era.)

Just my two cents, sorry for the wall of text following:

It's unfortunate the irqchip situation evolved to eventually block merging of the whole port altogether, especially the kernel ABI; but I'd like to point out that *the ship has already sailed*, regarding the move to fully dynamic IRQ topology probing.

IIUC, the necessary ACPI spec changes were already accepted even before the first revision of the port, back in late 2021; while I don't know if there's time for the responsible Loongson team to listen and amend the spec draft before the freeze, the end result is no change, and I was told that the ACPI 6.5 release is imminent (around early June). As everyone can see from the code, it's simply not possible to express fully dynamic associations between the interrupt controllers, the necessary reference fields for describing arbitrary graph edges are simply not there.

The responsible Loongson team could be hard-pressed to revise their tables and make it more IORT-like so as to satisfy the subsystem maintainer's requirement, but it'll be at least 1 year before the fixed ACPI 6.6 is out, and there will already be loads of boards featuring the fixed-topology ACPI 6.5 tables, which we have to support for a while anyway.

Yes, the Loongson teams could be (or most probably, are already) punished for their uncooperative attitude towards upstream reviews, by letting them miss the 5.19 window; the open-source community in general is *not* going to bend rules only for some random people's KPI and the kernel community is famously no exception. Reviewers always give suggestions out of their goodwill and previous experience, and I believe in this case it must be the case too; it's Loongson's fault to repeatedly ignore the comments after all, no matter due to ignorance, or language barrier (looking at the conversations, it's painfully clear to a native Chinese speaker that many chances to resolve confusion/misunderstanding have been wasted), and missing 5.19 is precisely that hard lesson for them.

But what for the users and downstream projects? Do the users owning LoongArch hardware (me included) and projects/companies porting their offerings have to pay for Loongson's mistakes and wait another [2mo, 1yr], "ideally" also missing the glibc 2.36 release too?

So, being an affected end user and a distro developer, I suggest that we be pragmatic, and try to review the irqchip code in its current form, in hopes of making it into this merge window. The more elegant alternative is already impossible in the context of ACPI 6.5, and the current code is going to get in eventually anyway, unless we're ready to declare the ACPI 6.5 LoongArch systems deprecated and unsupported from day one, due to some Loongson dev being unreasonably stubborn and rejecting upstream reviews. In return, the Loongson devs should really lower their ego and consider the maintainer's advice, and ensure things are sorted out in ACPI 6.6; the experience behind the comment simply cannot be ignored for any reason.

At the very least, we should give out a clear signal for downstream projects, that the userspace ABI of the port can already be considered stable, so they could somehow move forward even if the port is not going to appear in 5.19. (Semi-selfishly speaking, it's arguably preferable to work especially hard for inclusion in 5.19, because otherwise we would likely miss the glibc 2.36 release, which means another 6mo of carrying patches downstream, and widespream patching of glibc symbol versions once the glibc port is changed to target 2.37 instead. It's really hard to teach end users to migrate such low-level thing.)

Lastly, I'd like to clarify, that this is by no means a passive-aggressive statement to make the community look like "the bad guy", or to make Loongson "look bad"; I just intend to provide a hopefully fresh perspective from a/an {end user, hobbyist kernel developer, distro developer, native Chinese speaker with a hopefully decent grasp of English}'s view.


And thanks for your patience,

WANG Xuerui




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux