From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5209 invoked from network); 1 Jun 2022 16:46:57 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Jun 2022 16:46:57 -0000 Received: (qmail 30648 invoked by uid 550); 1 Jun 2022 16:46:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 29790 invoked from network); 1 Jun 2022 16:44:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1654101870; bh=D86uvLtUnid4ac7RPV6LXcQ6KwoBx2mBLbHHxLqwrus=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=rCSys+WSoaWiFQDm31CP75+HYXB6/F1uJSD8F2HZfW31dKUPSaK3hTAq2ub1Skgxq 4F+g0b2xTlO92waMrhrZ/d/Zv2R5bQVlDwHuk33MfL+SrYXR0/2yCTLOVQJhNTjTcE UB+cQ/tIApWLxneHte7BXvPhqhkz3K4LQXZagY88= Message-ID: <47b559c0-b1e8-e800-0491-2431e2083dad@xen0n.name> Date: Thu, 2 Jun 2022 00:44:30 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Thunderbird/103.0a1 Content-Language: en-US To: Ard Biesheuvel , Arnd Bergmann Cc: WANG Xuerui , Huacai Chen , linux-arch , GNU C Library , Yoshinori Sato , Peter Zijlstra , Marc Zyngier , Masahiro Yamada , musl@lists.openwall.com, Linux Kernel Mailing List , Jiaxun Yang , ACPI Devel Maling List , Jianmin Lv , linux-pci , Linus Torvalds , Huacai Chen References: <358025d1-28e6-708b-d23d-3f22ae12a800@xen0n.name> <832c3ae8-6c68-db2c-2c7f-0a5cd3071543@xen0n.name> From: WANG Xuerui In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 Hi Ard, On 6/2/22 00:01, Ard Biesheuvel wrote: > On Wed, 1 Jun 2022 at 09:41, Arnd Bergmann wrote: >> On Wed, Jun 1, 2022 at 7:52 AM WANG Xuerui wrote: >>> On 6/1/22 00:01, Huacai Chen wrote: >>>> https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next >>>> has been updated. Now this branch droped irqchip drivers and pci >>>> drivers. But the existing irqchip drivers need some small adjustment >>>> to avoid build errors [1], and I hope Marc can give an Acked-by. >>>> Thanks. >>>> >>>> This branch can be built with defconfig and allmodconfig (except >>>> drivers/platform/surface/aggregator/controller.c, because it requires >>>> 8bit/16bit cmpxchg, which I was told to remove their support). >>>> >>>> [1] https://lore.kernel.org/lkml/e7cf33a170d0b4e98e53744f60dbf922@kernel.org/T/#t >>> I see the loongarch-next HEAD has been updated and it's now purely arch >>> changes aside from the two trivial irqchip cleanups. Some other changes >>> to the v11 patchset [1] are included, but arguably minor enough to not >>> invalidate previous Reviewed-by tags. >> Very nice! I don't see exactly how the previous build bugs were addressed, >> but I can confirm that this version builds. Regarding the two irqchip patches, >> 621e7015b529 ("irqchip/loongson-liointc: Fix build error for LoongArch") is >> a good way to work around the mips oddity, and I have no problem taking >> that through the asm-generic tree. The other one, f54b4a166023 ("irqchip: >> Adjust Kconfig for Loongson"), looks mostly unnecessary, and I think only >> the LOONGSON_HTPIC change should be included here, while I would >> leave out the COMPILE_TEST changes and instead have the driver >> changes take care of making it possible to keep building it on x86, possibly >> doing >> >> depends on MACH_LOONGSON64 || (COMPILE_TEST && ACPI) >> >> in the future, after the loongarch64 ACPI support is merged. >> >>> After some small tweaks: >>> >>> - adding "#include " to arch/loongarch/include/asm/ptrace.h, >>> - adding an arch/loongarch/include/uapi/asm/bpf_perf_event.h with the >>> same content as arch/arm64's, and >>> - adding "depends on ARM64 || X86" to >>> drivers/platform/surface/aggregator/Kconfig, >>> >>> the current loongarch-next HEAD (commit >>> 36552a24f70d21b7d63d9ef490561dbdc13798d7) now passes allmodconfig build >>> (with CONFIG_WERROR disabled; my Gentoo-flavored gcc-12 seems to emit >>> warnings on a few drivers). >> The only one of these issues that I see is the surface aggregator one. >> I think we can address all three as follow-up fixes after -rc1 if the port >> gets merged and these are still required. >> >>> The majority of userspace ABI has been stable for a few months already, >>> after the addition of orig_a0 and removal of newfstatat; the necessary >>> changes to switch to statx are already reviewed [2] / merged [3], and >>> have been integrated into the LoongArch port of Gentoo for a while. Eric >>> looked at the v11 and gave comments, and changes were made according to >>> the suggestions, but it'd probably better to get a proper Reviewed-by. >> Right. >> >>> Among the rest of patches, I think maybe the EFI/boot protocol part >>> still need approval/ack from the EFI maintainer. However because the >>> current port isn't going to be able to run on any real hardware, maybe >>> that part could be done later; I'm not sure if the unacknowledged EFI >>> bits should be removed as well. >> Ard, do you have any last comments on this? >> > It would be nice if the questions I raised against the previous > revision (v11) were addressed (or at least answered) first. In > general, I think this is feeling a bit rushed and IMHO we should > probably defer this to the next cycle. Actually I think Huacai did reply to your review on v11: https://lore.kernel.org/all/CAAhV-H7KAg8RxN7M=WiOOh0fDhEKTyqrwp6V-SC0cyR0iMrdeg@mail.gmail.com/. It's a bit unfortunate that he probably didn't justify some of the approaches enough, and it's especially unfortunate that some of the points (like maybe the kernel version string in the EFI stub header) are result of their internal discussion, which I presume to be especially hard to change due to their particularly worrying corporate dynamics... But again, my point is that the userspace ABI in particular is *not* rushed -- it has been brewing since v1 of the port which is already several months ago, and multiple distro-building efforts are already underway. We (LoongArch distro packagers) want to freeze the userspace ABI so that many downstream efforts wouldn't be blocked by the merging of kernel port. As the boot protocol is technically not part of the userspace ABI that toolchains care about, and we already know it'll be a rather standards-compliant UEFI implementation even if this part gets dropped for brewing one more cycle, would taking this part out work for you?