Message-ID: <df5c406c-eec6-c340-2847-49670b7fe8bf@xen0n.name>
Date:   Sun, 29 May 2022 21:10:16 +0800
From:   WANG Xuerui <kernel@...0n.name>
To:     Arnd Bergmann <arnd@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     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>, Marc Zyngier <maz@...nel.org>,
        libc-alpha@...rceware.org, musl@...ts.openwall.com,
        ardb@...nel.org, linux-acpi@...r.kernel.org,
        linux-pci@...r.kernel.org, Jianmin Lv <lvjianmin@...ngson.cn>,
        Jiaxun Yang <jiaxun.yang@...goat.com>
Subject: Re: [GIT PULL] asm-generic changes for 5.19

On 5/29/22 19:24, Arnd Bergmann 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.
>
> 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

Powered by blists - more mailing lists