* [GIT PULL] asm-generic changes for 5.19 @ 2022-05-26 15:00 Arnd Bergmann 2022-05-26 18:20 ` pr-tracker-bot 2022-05-29 11:24 ` Arnd Bergmann 0 siblings, 2 replies; 26+ messages in thread From: Arnd Bergmann @ 2022-05-26 15:00 UTC (permalink / raw) To: Linus Torvalds Cc: linux-arch, Linux Kernel Mailing List, Yoshinori Sato, Palmer Dabbelt, Masahiro Yamada, Peter Zijlstra The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17: Linux 5.18-rc1 (2022-04-03 14:08:21 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-5.19 for you to fetch changes up to b2441b3bdce6c02cb96278d98c620d7ba1d41b7b: h8300: remove stale bindings and symlink (2022-05-20 22:40:56 +0200) ---------------------------------------------------------------- asm-generic changes for 5.19 The asm-generic tree contains three separate changes for linux-5.19: - The h8300 architecture is retired after it has been effectively unmaintained for a number of years. This is the last architecture we supported that has no MMU implementation, but there are still a few architectures (arm, m68k, riscv, sh and xtensa) that support CPUs with and without an MMU. - 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. - A cleanup of some exported uapi header files to ensure they can be included from user space without relying on other kernel headers. ---------------------------------------------------------------- Arnd Bergmann (4): Merge branch 'remove-h8300' of git://git.infradead.org/users/hch/misc into asm-generic Merge tag 'generic-ticket-spinlocks-v6' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux into asm-generic Merge branch 'asm-generic-headers-cleanup' into asm-generic h8300: remove stale bindings and symlink Christoph Hellwig (1): remove the h8300 architecture Guo Ren (1): csky: Move to generic ticket-spinlock Masahiro Yamada (6): agpgart.h: do not include <stdlib.h> from exported header kbuild: prevent exported headers from including <stdlib.h>, <stdbool.h> riscv: add linux/bpf_perf_event.h to UAPI compile-test coverage mips: add asm/stat.h to UAPI compile-test coverage powerpc: add asm/stat.h to UAPI compile-test coverage sparc: add asm/stat.h to UAPI compile-test coverage Palmer Dabbelt (3): asm-generic: qrwlock: Document the spinlock fairness requirements RISC-V: Move to generic spinlocks RISC-V: Move to queued RW locks Peter Zijlstra (3): asm-generic: ticket-lock: New generic ticket-based spinlock asm-generic: qspinlock: Indicate the use of mixed-size atomics openrisc: Move to ticket-spinlock .../bindings/clock/renesas,h8300-div-clock.txt | 24 -- .../bindings/clock/renesas,h8s2678-pll-clock.txt | 23 -- Documentation/devicetree/bindings/h8300/cpu.txt | 13 - .../interrupt-controller/renesas,h8300h-intc.txt | 22 -- .../interrupt-controller/renesas,h8s-intc.txt | 22 -- .../memory-controllers/renesas,h8300-bsc.yaml | 35 -- .../bindings/timer/renesas,16bit-timer.txt | 25 -- .../bindings/timer/renesas,8bit-timer.txt | 25 -- .../features/core/cBPF-JIT/arch-support.txt | 1 - .../features/core/eBPF-JIT/arch-support.txt | 1 - .../core/generic-idle-thread/arch-support.txt | 1 - .../features/core/jump-labels/arch-support.txt | 1 - .../core/thread-info-in-task/arch-support.txt | 1 - .../features/core/tracehook/arch-support.txt | 1 - .../features/debug/KASAN/arch-support.txt | 1 - .../debug/debug-vm-pgtable/arch-support.txt | 1 - .../debug/gcov-profile-all/arch-support.txt | 1 - Documentation/features/debug/kcov/arch-support.txt | 1 - Documentation/features/debug/kgdb/arch-support.txt | 1 - .../features/debug/kmemleak/arch-support.txt | 1 - .../debug/kprobes-on-ftrace/arch-support.txt | 1 - .../features/debug/kprobes/arch-support.txt | 1 - .../features/debug/kretprobes/arch-support.txt | 1 - .../features/debug/optprobes/arch-support.txt | 1 - .../features/debug/stackprotector/arch-support.txt | 1 - .../features/debug/uprobes/arch-support.txt | 1 - .../debug/user-ret-profiler/arch-support.txt | 1 - .../features/io/dma-contiguous/arch-support.txt | 1 - .../locking/cmpxchg-local/arch-support.txt | 1 - .../features/locking/lockdep/arch-support.txt | 1 - .../locking/queued-rwlocks/arch-support.txt | 1 - .../locking/queued-spinlocks/arch-support.txt | 1 - .../features/perf/kprobes-event/arch-support.txt | 1 - .../features/perf/perf-regs/arch-support.txt | 1 - .../features/perf/perf-stackdump/arch-support.txt | 1 - .../sched/membarrier-sync-core/arch-support.txt | 1 - .../features/sched/numa-balancing/arch-support.txt | 1 - .../seccomp/seccomp-filter/arch-support.txt | 1 - .../time/arch-tick-broadcast/arch-support.txt | 1 - .../features/time/clockevents/arch-support.txt | 1 - .../time/context-tracking/arch-support.txt | 1 - .../features/time/irq-time-acct/arch-support.txt | 1 - .../features/time/virt-cpuacct/arch-support.txt | 1 - .../features/vm/ELF-ASLR/arch-support.txt | 1 - .../features/vm/PG_uncached/arch-support.txt | 1 - Documentation/features/vm/THP/arch-support.txt | 1 - Documentation/features/vm/TLB/arch-support.txt | 1 - .../features/vm/huge-vmap/arch-support.txt | 1 - .../features/vm/ioremap_prot/arch-support.txt | 1 - .../features/vm/pte_special/arch-support.txt | 1 - MAINTAINERS | 11 - arch/csky/include/asm/Kbuild | 3 + arch/csky/include/asm/spinlock.h | 89 ----- arch/csky/include/asm/spinlock_types.h | 27 -- arch/h8300/Kbuild | 5 - arch/h8300/Kconfig | 49 --- arch/h8300/Kconfig.cpu | 99 ----- arch/h8300/Kconfig.debug | 2 - arch/h8300/Makefile | 44 --- arch/h8300/boot/Makefile | 27 -- arch/h8300/boot/compressed/Makefile | 45 --- arch/h8300/boot/compressed/head.S | 49 --- arch/h8300/boot/compressed/misc.c | 76 ---- arch/h8300/boot/compressed/vmlinux.lds | 35 -- arch/h8300/boot/compressed/vmlinux.scr | 9 - arch/h8300/boot/dts/Makefile | 6 - arch/h8300/boot/dts/edosk2674.dts | 108 ----- arch/h8300/boot/dts/h8300h_sim.dts | 97 ----- arch/h8300/boot/dts/h8s_sim.dts | 100 ----- arch/h8300/configs/edosk2674_defconfig | 48 --- arch/h8300/configs/h8300h-sim_defconfig | 48 --- arch/h8300/configs/h8s-sim_defconfig | 48 --- arch/h8300/include/asm/Kbuild | 8 - arch/h8300/include/asm/bitops.h | 179 --------- arch/h8300/include/asm/bug.h | 13 - arch/h8300/include/asm/byteorder.h | 7 - arch/h8300/include/asm/cache.h | 12 - arch/h8300/include/asm/elf.h | 102 ----- arch/h8300/include/asm/flat.h | 36 -- arch/h8300/include/asm/hash.h | 54 --- arch/h8300/include/asm/io.h | 67 ---- arch/h8300/include/asm/irq.h | 25 -- arch/h8300/include/asm/irqflags.h | 97 ----- arch/h8300/include/asm/kgdb.h | 45 --- arch/h8300/include/asm/mmu_context.h | 6 - arch/h8300/include/asm/page.h | 17 - arch/h8300/include/asm/page_offset.h | 2 - arch/h8300/include/asm/pgtable.h | 43 -- arch/h8300/include/asm/processor.h | 126 ------ arch/h8300/include/asm/ptrace.h | 39 -- arch/h8300/include/asm/signal.h | 23 -- arch/h8300/include/asm/smp.h | 1 - arch/h8300/include/asm/string.h | 18 - arch/h8300/include/asm/switch_to.h | 52 --- arch/h8300/include/asm/syscall.h | 43 -- arch/h8300/include/asm/thread_info.h | 102 ----- arch/h8300/include/asm/tlb.h | 7 - arch/h8300/include/asm/traps.h | 41 -- arch/h8300/include/asm/user.h | 71 ---- arch/h8300/include/asm/vmalloc.h | 4 - arch/h8300/include/uapi/asm/Kbuild | 2 - arch/h8300/include/uapi/asm/byteorder.h | 7 - arch/h8300/include/uapi/asm/posix_types.h | 13 - arch/h8300/include/uapi/asm/ptrace.h | 43 -- arch/h8300/include/uapi/asm/sigcontext.h | 19 - arch/h8300/include/uapi/asm/signal.h | 92 ----- arch/h8300/include/uapi/asm/unistd.h | 8 - arch/h8300/kernel/.gitignore | 2 - arch/h8300/kernel/Makefile | 22 -- arch/h8300/kernel/asm-offsets.c | 70 ---- arch/h8300/kernel/entry.S | 433 --------------------- arch/h8300/kernel/h8300_ksyms.c | 35 -- arch/h8300/kernel/head_ram.S | 60 --- arch/h8300/kernel/head_rom.S | 111 ------ arch/h8300/kernel/irq.c | 99 ----- arch/h8300/kernel/kgdb.c | 135 ------- arch/h8300/kernel/module.c | 71 ---- arch/h8300/kernel/process.c | 173 -------- arch/h8300/kernel/ptrace.c | 199 ---------- arch/h8300/kernel/ptrace_h.c | 256 ------------ arch/h8300/kernel/ptrace_s.c | 44 --- arch/h8300/kernel/setup.c | 213 ---------- arch/h8300/kernel/signal.c | 287 -------------- arch/h8300/kernel/sim-console.c | 31 -- arch/h8300/kernel/syscalls.c | 15 - arch/h8300/kernel/traps.c | 156 -------- arch/h8300/kernel/vmlinux.lds.S | 69 ---- arch/h8300/lib/Makefile | 9 - arch/h8300/lib/abs.S | 21 - arch/h8300/lib/ashldi3.c | 25 -- arch/h8300/lib/ashrdi3.c | 25 -- arch/h8300/lib/delay.c | 41 -- arch/h8300/lib/libgcc.h | 78 ---- arch/h8300/lib/lshrdi3.c | 24 -- arch/h8300/lib/memcpy.S | 86 ---- arch/h8300/lib/memset.S | 70 ---- arch/h8300/lib/moddivsi3.S | 73 ---- arch/h8300/lib/modsi3.S | 73 ---- arch/h8300/lib/muldi3.c | 45 --- arch/h8300/lib/mulsi3.S | 39 -- arch/h8300/lib/ucmpdi2.c | 18 - arch/h8300/lib/udivsi3.S | 77 ---- arch/h8300/mm/Makefile | 6 - arch/h8300/mm/fault.c | 57 --- arch/h8300/mm/init.c | 95 ----- arch/h8300/mm/memory.c | 52 --- arch/mips/include/uapi/asm/stat.h | 20 +- arch/openrisc/Kconfig | 1 - arch/openrisc/include/asm/Kbuild | 5 +- arch/openrisc/include/asm/spinlock.h | 27 -- arch/openrisc/include/asm/spinlock_types.h | 7 - arch/powerpc/include/uapi/asm/stat.h | 10 +- arch/riscv/Kconfig | 1 + arch/riscv/include/asm/Kbuild | 4 + arch/riscv/include/asm/spinlock.h | 135 ------- arch/riscv/include/asm/spinlock_types.h | 25 -- arch/sparc/include/uapi/asm/stat.h | 12 +- drivers/clk/Makefile | 1 - drivers/clk/h8300/Makefile | 3 - drivers/clk/h8300/clk-div.c | 57 --- drivers/clk/h8300/clk-h8s2678.c | 145 ------- drivers/clocksource/Kconfig | 20 - drivers/clocksource/Makefile | 3 - drivers/clocksource/h8300_timer16.c | 192 --------- drivers/clocksource/h8300_timer8.c | 211 ---------- drivers/clocksource/h8300_tpu.c | 158 -------- drivers/irqchip/Kconfig | 11 - drivers/irqchip/Makefile | 2 - drivers/irqchip/irq-renesas-h8300h.c | 94 ----- drivers/irqchip/irq-renesas-h8s.c | 102 ----- drivers/net/ethernet/smsc/Kconfig | 4 +- drivers/net/ethernet/smsc/smc91x.h | 11 - drivers/tty/serial/Kconfig | 5 +- include/asm-generic/qrwlock.h | 4 + include/asm-generic/qspinlock.h | 29 ++ include/asm-generic/spinlock.h | 94 ++++- include/asm-generic/spinlock_types.h | 17 + include/uapi/linux/agpgart.h | 9 +- init/Kconfig | 3 +- scripts/dtc/include-prefixes/h8300 | 1 - tools/arch/h8300/include/asm/bitsperlong.h | 15 - tools/arch/h8300/include/uapi/asm/mman.h | 7 - usr/dummy-include/stdbool.h | 7 + usr/dummy-include/stdlib.h | 7 + usr/include/Makefile | 12 +- 185 files changed, 192 insertions(+), 7354 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/renesas,h8300-div-clock.txt delete mode 100644 Documentation/devicetree/bindings/clock/renesas,h8s2678-pll-clock.txt delete mode 100644 Documentation/devicetree/bindings/h8300/cpu.txt delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,h8300h-intc.txt delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,h8s-intc.txt delete mode 100644 Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml delete mode 100644 Documentation/devicetree/bindings/timer/renesas,16bit-timer.txt delete mode 100644 Documentation/devicetree/bindings/timer/renesas,8bit-timer.txt delete mode 100644 arch/csky/include/asm/spinlock.h delete mode 100644 arch/csky/include/asm/spinlock_types.h delete mode 100644 arch/h8300/Kbuild delete mode 100644 arch/h8300/Kconfig delete mode 100644 arch/h8300/Kconfig.cpu delete mode 100644 arch/h8300/Kconfig.debug delete mode 100644 arch/h8300/Makefile delete mode 100644 arch/h8300/boot/Makefile delete mode 100644 arch/h8300/boot/compressed/Makefile delete mode 100644 arch/h8300/boot/compressed/head.S delete mode 100644 arch/h8300/boot/compressed/misc.c delete mode 100644 arch/h8300/boot/compressed/vmlinux.lds delete mode 100644 arch/h8300/boot/compressed/vmlinux.scr delete mode 100644 arch/h8300/boot/dts/Makefile delete mode 100644 arch/h8300/boot/dts/edosk2674.dts delete mode 100644 arch/h8300/boot/dts/h8300h_sim.dts delete mode 100644 arch/h8300/boot/dts/h8s_sim.dts delete mode 100644 arch/h8300/configs/edosk2674_defconfig delete mode 100644 arch/h8300/configs/h8300h-sim_defconfig delete mode 100644 arch/h8300/configs/h8s-sim_defconfig delete mode 100644 arch/h8300/include/asm/Kbuild delete mode 100644 arch/h8300/include/asm/bitops.h delete mode 100644 arch/h8300/include/asm/bug.h delete mode 100644 arch/h8300/include/asm/byteorder.h delete mode 100644 arch/h8300/include/asm/cache.h delete mode 100644 arch/h8300/include/asm/elf.h delete mode 100644 arch/h8300/include/asm/flat.h delete mode 100644 arch/h8300/include/asm/hash.h delete mode 100644 arch/h8300/include/asm/io.h delete mode 100644 arch/h8300/include/asm/irq.h delete mode 100644 arch/h8300/include/asm/irqflags.h delete mode 100644 arch/h8300/include/asm/kgdb.h delete mode 100644 arch/h8300/include/asm/mmu_context.h delete mode 100644 arch/h8300/include/asm/page.h delete mode 100644 arch/h8300/include/asm/page_offset.h delete mode 100644 arch/h8300/include/asm/pgtable.h delete mode 100644 arch/h8300/include/asm/processor.h delete mode 100644 arch/h8300/include/asm/ptrace.h delete mode 100644 arch/h8300/include/asm/signal.h delete mode 100644 arch/h8300/include/asm/smp.h delete mode 100644 arch/h8300/include/asm/string.h delete mode 100644 arch/h8300/include/asm/switch_to.h delete mode 100644 arch/h8300/include/asm/syscall.h delete mode 100644 arch/h8300/include/asm/thread_info.h delete mode 100644 arch/h8300/include/asm/tlb.h delete mode 100644 arch/h8300/include/asm/traps.h delete mode 100644 arch/h8300/include/asm/user.h delete mode 100644 arch/h8300/include/asm/vmalloc.h delete mode 100644 arch/h8300/include/uapi/asm/Kbuild delete mode 100644 arch/h8300/include/uapi/asm/byteorder.h delete mode 100644 arch/h8300/include/uapi/asm/posix_types.h delete mode 100644 arch/h8300/include/uapi/asm/ptrace.h delete mode 100644 arch/h8300/include/uapi/asm/sigcontext.h delete mode 100644 arch/h8300/include/uapi/asm/signal.h delete mode 100644 arch/h8300/include/uapi/asm/unistd.h delete mode 100644 arch/h8300/kernel/.gitignore delete mode 100644 arch/h8300/kernel/Makefile delete mode 100644 arch/h8300/kernel/asm-offsets.c delete mode 100644 arch/h8300/kernel/entry.S delete mode 100644 arch/h8300/kernel/h8300_ksyms.c delete mode 100644 arch/h8300/kernel/head_ram.S delete mode 100644 arch/h8300/kernel/head_rom.S delete mode 100644 arch/h8300/kernel/irq.c delete mode 100644 arch/h8300/kernel/kgdb.c delete mode 100644 arch/h8300/kernel/module.c delete mode 100644 arch/h8300/kernel/process.c delete mode 100644 arch/h8300/kernel/ptrace.c delete mode 100644 arch/h8300/kernel/ptrace_h.c delete mode 100644 arch/h8300/kernel/ptrace_s.c delete mode 100644 arch/h8300/kernel/setup.c delete mode 100644 arch/h8300/kernel/signal.c delete mode 100644 arch/h8300/kernel/sim-console.c delete mode 100644 arch/h8300/kernel/syscalls.c delete mode 100644 arch/h8300/kernel/traps.c delete mode 100644 arch/h8300/kernel/vmlinux.lds.S delete mode 100644 arch/h8300/lib/Makefile delete mode 100644 arch/h8300/lib/abs.S delete mode 100644 arch/h8300/lib/ashldi3.c delete mode 100644 arch/h8300/lib/ashrdi3.c delete mode 100644 arch/h8300/lib/delay.c delete mode 100644 arch/h8300/lib/libgcc.h delete mode 100644 arch/h8300/lib/lshrdi3.c delete mode 100644 arch/h8300/lib/memcpy.S delete mode 100644 arch/h8300/lib/memset.S delete mode 100644 arch/h8300/lib/moddivsi3.S delete mode 100644 arch/h8300/lib/modsi3.S delete mode 100644 arch/h8300/lib/muldi3.c delete mode 100644 arch/h8300/lib/mulsi3.S delete mode 100644 arch/h8300/lib/ucmpdi2.c delete mode 100644 arch/h8300/lib/udivsi3.S delete mode 100644 arch/h8300/mm/Makefile delete mode 100644 arch/h8300/mm/fault.c delete mode 100644 arch/h8300/mm/init.c delete mode 100644 arch/h8300/mm/memory.c delete mode 100644 arch/openrisc/include/asm/spinlock.h delete mode 100644 arch/openrisc/include/asm/spinlock_types.h delete mode 100644 arch/riscv/include/asm/spinlock.h delete mode 100644 arch/riscv/include/asm/spinlock_types.h delete mode 100644 drivers/clk/h8300/Makefile delete mode 100644 drivers/clk/h8300/clk-div.c delete mode 100644 drivers/clk/h8300/clk-h8s2678.c delete mode 100644 drivers/clocksource/h8300_timer16.c delete mode 100644 drivers/clocksource/h8300_timer8.c delete mode 100644 drivers/clocksource/h8300_tpu.c delete mode 100644 drivers/irqchip/irq-renesas-h8300h.c delete mode 100644 drivers/irqchip/irq-renesas-h8s.c create mode 100644 include/asm-generic/spinlock_types.h delete mode 120000 scripts/dtc/include-prefixes/h8300 delete mode 100644 tools/arch/h8300/include/asm/bitsperlong.h delete mode 100644 tools/arch/h8300/include/uapi/asm/mman.h create mode 100644 usr/dummy-include/stdbool.h create mode 100644 usr/dummy-include/stdlib.h ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] asm-generic changes for 5.19 2022-05-26 15:00 [GIT PULL] asm-generic changes for 5.19 Arnd Bergmann @ 2022-05-26 18:20 ` pr-tracker-bot 2022-05-29 11:24 ` Arnd Bergmann 1 sibling, 0 replies; 26+ messages in thread From: pr-tracker-bot @ 2022-05-26 18:20 UTC (permalink / raw) To: Arnd Bergmann Cc: Linus Torvalds, linux-arch, Linux Kernel Mailing List, Yoshinori Sato, Palmer Dabbelt, Masahiro Yamada, Peter Zijlstra The pull request you sent on Thu, 26 May 2022 17:00:04 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-5.19 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/16477cdfefdb494235a675cc80563d736991d833 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] asm-generic changes for 5.19 2022-05-26 15:00 [GIT PULL] asm-generic changes for 5.19 Arnd Bergmann 2022-05-26 18:20 ` pr-tracker-bot @ 2022-05-29 11:24 ` Arnd Bergmann 2022-05-29 13:10 ` WANG Xuerui 2022-05-29 13:21 ` Marc Zyngier 1 sibling, 2 replies; 26+ messages in thread From: Arnd Bergmann @ 2022-05-29 11:24 UTC (permalink / raw) To: Linus Torvalds Cc: linux-arch, Linux Kernel Mailing List, Yoshinori Sato, Palmer Dabbelt, Masahiro Yamada, Peter Zijlstra, Huacai Chen, WANG Xuerui, Marc Zyngier, libc-alpha, musl, ardb, linux-acpi, linux-pci On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <arnd@kernel.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. Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] asm-generic changes for 5.19 2022-05-29 11:24 ` Arnd Bergmann @ 2022-05-29 13:10 ` WANG Xuerui 2022-05-30 8:20 ` Arnd Bergmann 2022-05-29 13:21 ` Marc Zyngier 1 sibling, 1 reply; 26+ messages in thread From: WANG Xuerui @ 2022-05-29 13:10 UTC (permalink / raw) To: Arnd Bergmann, Linus Torvalds Cc: linux-arch, Linux Kernel Mailing List, Yoshinori Sato, Palmer Dabbelt, Masahiro Yamada, Peter Zijlstra, Huacai Chen, WANG Xuerui, Marc Zyngier, libc-alpha, musl, ardb, linux-acpi, linux-pci, Jianmin Lv, Jiaxun Yang On 5/29/22 19:24, Arnd Bergmann wrote: > On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <arnd@kernel.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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] asm-generic changes for 5.19 2022-05-29 13:10 ` WANG Xuerui @ 2022-05-30 8:20 ` Arnd Bergmann 2022-05-30 13:01 ` Huacai Chen 0 siblings, 1 reply; 26+ messages in thread From: Arnd Bergmann @ 2022-05-30 8:20 UTC (permalink / raw) To: WANG Xuerui Cc: Linus Torvalds, linux-arch, libc-alpha, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, musl, Linux Kernel Mailing List, Jiaxun Yang, linux-acpi, Jianmin Lv, linux-pci, ardb, Huacai Chen On Sun, May 29, 2022 at 3:10 PM WANG Xuerui <kernel@xen0n.name> wrote: > 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? ... > 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. Your feedback has been extremely valuable, as always. I definitely don't want to hold up merging the port for the glibc-2.36 release. If that is a risk, and if merging the architecture port without the drivers helps with that, I agree we should just do that. This will also help with build testing and any treewide changes that are going to be done on top of v5.19-rc1. For the continuous maintenance, would you be available as an additional Reviewer or co-maintainer to be listed in the maintainers file? I think in general it is a good idea to have at least one maintainer that is not directly part of the organization that owns the product, and you are clearly the best person outside of loongson technology for this. Regarding the irqchip driver, merging those is entirely up to Marc and Thomas. Marc already brought up the precedent of merging arch/arm64 without the required irqchip driver support, and if it turns out that he find the latest driver submission acceptable, that might still make it in through the irqchip tree. Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] asm-generic changes for 5.19 2022-05-30 8:20 ` Arnd Bergmann @ 2022-05-30 13:01 ` Huacai Chen 2022-05-30 15:00 ` WANG Xuerui 0 siblings, 1 reply; 26+ messages in thread From: Huacai Chen @ 2022-05-30 13:01 UTC (permalink / raw) To: Arnd Bergmann Cc: WANG Xuerui, Linus Torvalds, linux-arch, libc-alpha, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, musl, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen Hi, Arnd, On Mon, May 30, 2022 at 4:21 PM Arnd Bergmann <arnd@kernel.org> wrote: > > On Sun, May 29, 2022 at 3:10 PM WANG Xuerui <kernel@xen0n.name> wrote: > > 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? > ... > > 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. > > Your feedback has been extremely valuable, as always. I definitely > don't want to hold up merging the port for the glibc-2.36 release. If > that is a risk, and if merging the architecture port without the drivers > helps with that, I agree we should just do that. This will also help > with build testing and any treewide changes that are going to be > done on top of v5.19-rc1. > > For the continuous maintenance, would you be available as an > additional Reviewer or co-maintainer to be listed in the maintainers > file? I think in general it is a good idea to have at least one maintainer > that is not directly part of the organization that owns the product, > and you are clearly the best person outside of loongson technology > for this. Yes, Xuerui is very suitable as a Reviewer. Huacai > > Regarding the irqchip driver, merging those is entirely up to Marc and > Thomas. Marc already brought up the precedent of merging arch/arm64 > without the required irqchip driver support, and if it turns out that he > find the latest driver submission acceptable, that might still make it in > through the irqchip tree. > > Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] asm-generic changes for 5.19 2022-05-30 13:01 ` Huacai Chen @ 2022-05-30 15:00 ` WANG Xuerui 2022-05-30 15:55 ` [musl] " Arnd Bergmann 0 siblings, 1 reply; 26+ messages in thread From: WANG Xuerui @ 2022-05-30 15:00 UTC (permalink / raw) To: Huacai Chen, Arnd Bergmann Cc: WANG Xuerui, Linus Torvalds, linux-arch, libc-alpha, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, musl, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen On 5/30/22 21:01, Huacai Chen wrote: > Hi, Arnd, > > On Mon, May 30, 2022 at 4:21 PM Arnd Bergmann <arnd@kernel.org> wrote: >> On Sun, May 29, 2022 at 3:10 PM WANG Xuerui <kernel@xen0n.name> wrote: >>> 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? >> ... >>> 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. >> Your feedback has been extremely valuable, as always. I definitely >> don't want to hold up merging the port for the glibc-2.36 release. If >> that is a risk, and if merging the architecture port without the drivers >> helps with that, I agree we should just do that. This will also help >> with build testing and any treewide changes that are going to be >> done on top of v5.19-rc1. >> >> For the continuous maintenance, would you be available as an >> additional Reviewer or co-maintainer to be listed in the maintainers >> file? I think in general it is a good idea to have at least one maintainer >> that is not directly part of the organization that owns the product, >> and you are clearly the best person outside of loongson technology >> for this. > Yes, Xuerui is very suitable as a Reviewer. Thanks for the recognition from both of you; it is my honor and pleasure to contribute to the LoongArch port and to Linux in general. As I'm still not entirely satisfied with my kernel development skills, plus my day job is not kernel-related nor Loongson/LoongArch-related at all, listing me as reviewer should be enough for now. I will take care of the arch as long as I have the hardware. BTW, there were already several breakages when rebasing the previous revision (I believe it's commit 215da6d2dac0 ("MAINTAINERS: Add maintainer information for LoongArch")) on top of linus' tree. Now I see the loongarch-next HEAD is already rebased on top of what I believe to be the current main branch, however I vaguely remember that it's not good to base one's patches on top of "some random commit", so I wonder whether the current branch state is appropriate for a PR? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-05-30 15:00 ` WANG Xuerui @ 2022-05-30 15:55 ` Arnd Bergmann 2022-05-31 7:50 ` Huacai Chen 0 siblings, 1 reply; 26+ messages in thread From: Arnd Bergmann @ 2022-05-30 15:55 UTC (permalink / raw) To: musl Cc: Huacai Chen, WANG Xuerui, Linus Torvalds, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@xen0n.name> wrote: > On 5/30/22 21:01, Huacai Chen wrote: > > Thanks for the recognition from both of you; it is my honor and pleasure > to contribute to the LoongArch port and to Linux in general. > > As I'm still not entirely satisfied with my kernel development skills, > plus my day job is not kernel-related nor Loongson/LoongArch-related at > all, listing me as reviewer should be enough for now. I will take care > of the arch as long as I have the hardware. Thanks, sounds good to me. > BTW, there were already several breakages when rebasing the previous > revision (I believe it's commit 215da6d2dac0 ("MAINTAINERS: Add > maintainer information for LoongArch")) on top of linus' tree. Right, at least most of these should be fairly easy to address by disabling the corresponding features. For the allmodconfig build, I see some warnings that are introduced in gcc-12.1 across all architectures, and those can be ignored for now. Some of the errors already have fixes on top of the 215da6d2dac0 commit, but some of the other commits look like we should leave them out here. I also see some conflicts between local symbol definitions and device drivers such as arch/loongarch/include/asm/loongarch.h:240:29: note: previous definition of 'csr_writel' with type 'void(u32, u32)' {aka 'void(unsigned int, unsigned int)'} 240 | static __always_inline void csr_writel(u32 val, u32 reg) | ^~~~~~~~~~ drivers/media/platform/amphion/vpu_core.h:10:5: error: conflicting types for 'csr_readl'; have 'u32(struct vpu_core *, u32)' {aka 'unsigned int(struct vpu_core *, unsigned int)'} and drivers/usb/cdns3/cdns3-imx.c:85: error: "PS_MASK" redefined [-Werror] I would suggest renaming the loongarch specific symbols here, though we may want to also change those drivers to use less generic identifiers. > Now I see > the loongarch-next HEAD is already rebased on top of what I believe to > be the current main branch, however I vaguely remember that it's not > good to base one's patches on top of "some random commit", so I wonder > whether the current branch state is appropriate for a PR? You are correct, a pull request should always be based on an -rc, orat least have the minimum set of dependencies. The branch was previously based on top of the spinlock implementation, which is still the best place to start here. Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-05-30 15:55 ` [musl] " Arnd Bergmann @ 2022-05-31 7:50 ` Huacai Chen 2022-05-31 8:09 ` Arnd Bergmann 0 siblings, 1 reply; 26+ messages in thread From: Huacai Chen @ 2022-05-31 7:50 UTC (permalink / raw) To: Arnd Bergmann Cc: musl, WANG Xuerui, Linus Torvalds, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen Hi, Arnd, On Mon, May 30, 2022 at 11:56 PM Arnd Bergmann <arnd@kernel.org> wrote: > > On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@xen0n.name> wrote: > > On 5/30/22 21:01, Huacai Chen wrote: > > > > Thanks for the recognition from both of you; it is my honor and pleasure > > to contribute to the LoongArch port and to Linux in general. > > > > As I'm still not entirely satisfied with my kernel development skills, > > plus my day job is not kernel-related nor Loongson/LoongArch-related at > > all, listing me as reviewer should be enough for now. I will take care > > of the arch as long as I have the hardware. > > Thanks, sounds good to me. > > > BTW, there were already several breakages when rebasing the previous > > revision (I believe it's commit 215da6d2dac0 ("MAINTAINERS: Add > > maintainer information for LoongArch")) on top of linus' tree. > > Right, at least most of these should be fairly easy to address by disabling > the corresponding features. For the allmodconfig build, I see some > warnings that are introduced in gcc-12.1 across all architectures, and > those can be ignored for now. > > Some of the errors already have fixes on top of the 215da6d2dac0 > commit, but some of the other commits look like we should leave > them out here. > > I also see some conflicts between local symbol definitions and device > drivers such as > > arch/loongarch/include/asm/loongarch.h:240:29: note: previous > definition of 'csr_writel' with type 'void(u32, u32)' {aka > 'void(unsigned int, unsigned int)'} > 240 | static __always_inline void csr_writel(u32 val, u32 reg) > | ^~~~~~~~~~ > drivers/media/platform/amphion/vpu_core.h:10:5: error: conflicting > types for 'csr_readl'; have 'u32(struct vpu_core *, u32)' {aka > 'unsigned int(struct vpu_core *, unsigned int)'} > > and > > drivers/usb/cdns3/cdns3-imx.c:85: error: "PS_MASK" redefined [-Werror] > > I would suggest renaming the loongarch specific symbols here, though we > may want to also change those drivers to use less generic identifiers. OK, loongarch specific symbols will be renamed. > > > Now I see > > the loongarch-next HEAD is already rebased on top of what I believe to > > be the current main branch, however I vaguely remember that it's not > > good to base one's patches on top of "some random commit", so I wonder > > whether the current branch state is appropriate for a PR? > > You are correct, a pull request should always be based on an -rc, orat least > have the minimum set of dependencies. The branch was previously > based on top of the spinlock implementation, which is still the best > place to start here. I have a difficult problem to select the base. Take swiotlb_init() as an example: If I select 5.18-rc1, I should use swiotlb_init(1); if I select Linus' latest tree, I should use swiotlb_init(true, SWIOTLB_VERBOSE). However, if I select 5.18-rc1, linux-next will have a build error because the code there expect swiotlb_init(true, SWIOTLB_VERBOSE). Huacai > > Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-05-31 7:50 ` Huacai Chen @ 2022-05-31 8:09 ` Arnd Bergmann 2022-05-31 8:17 ` Huacai Chen 0 siblings, 1 reply; 26+ messages in thread From: Arnd Bergmann @ 2022-05-31 8:09 UTC (permalink / raw) To: Huacai Chen Cc: musl, WANG Xuerui, Linus Torvalds, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen On Tue, May 31, 2022 at 9:50 AM Huacai Chen <chenhuacai@kernel.org> wrote: > On Mon, May 30, 2022 at 11:56 PM Arnd Bergmann <arnd@kernel.org> wrote: > > On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@xen0n.name> wrote: > > > Now I see > > > the loongarch-next HEAD is already rebased on top of what I believe to > > > be the current main branch, however I vaguely remember that it's not > > > good to base one's patches on top of "some random commit", so I wonder > > > whether the current branch state is appropriate for a PR? > > > > You are correct, a pull request should always be based on an -rc, orat least > > have the minimum set of dependencies. The branch was previously > > based on top of the spinlock implementation, which is still the best > > place to start here. > I have a difficult problem to select the base. Take swiotlb_init() as > an example: If I select 5.18-rc1, I should use swiotlb_init(1); if I > select Linus' latest tree, I should use swiotlb_init(true, > SWIOTLB_VERBOSE). However, if I select 5.18-rc1, linux-next will have > a build error because the code there expect swiotlb_init(true, > SWIOTLB_VERBOSE). Ok, I see. This is the kind of thing we normally prevent by having everything in linux-next for a few weeks before the merge window. How many issues like this are you aware of? If it's just the swiotlb, you could try merging the swiotlb branch that is in mainline now on top of the spinlock branch, and still get a minimum set of dependencies. If there are many more, then basing on top of the current mainline is probably less intrusive after all. Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-05-31 8:09 ` Arnd Bergmann @ 2022-05-31 8:17 ` Huacai Chen 2022-05-31 11:15 ` Arnd Bergmann 0 siblings, 1 reply; 26+ messages in thread From: Huacai Chen @ 2022-05-31 8:17 UTC (permalink / raw) To: Arnd Bergmann Cc: musl, WANG Xuerui, Linus Torvalds, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen Hi, Arnd, On Tue, May 31, 2022 at 4:09 PM Arnd Bergmann <arnd@kernel.org> wrote: > > On Tue, May 31, 2022 at 9:50 AM Huacai Chen <chenhuacai@kernel.org> wrote: > > On Mon, May 30, 2022 at 11:56 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@xen0n.name> wrote: > > > > Now I see > > > > the loongarch-next HEAD is already rebased on top of what I believe to > > > > be the current main branch, however I vaguely remember that it's not > > > > good to base one's patches on top of "some random commit", so I wonder > > > > whether the current branch state is appropriate for a PR? > > > > > > You are correct, a pull request should always be based on an -rc, orat least > > > have the minimum set of dependencies. The branch was previously > > > based on top of the spinlock implementation, which is still the best > > > place to start here. > > I have a difficult problem to select the base. Take swiotlb_init() as > > an example: If I select 5.18-rc1, I should use swiotlb_init(1); if I > > select Linus' latest tree, I should use swiotlb_init(true, > > SWIOTLB_VERBOSE). However, if I select 5.18-rc1, linux-next will have > > a build error because the code there expect swiotlb_init(true, > > SWIOTLB_VERBOSE). > > Ok, I see. This is the kind of thing we normally prevent by having everything > in linux-next for a few weeks before the merge window. How many issues > like this are you aware of? If it's just the swiotlb, you could try merging > the swiotlb branch that is in mainline now on top of the spinlock branch, > and still get a minimum set of dependencies. If there are many more, > then basing on top of the current mainline is probably less intrusive after > all. I have 3 issues: 1, swiotlb_init(1) --> swiotlb_init(true, SWIOTLB_VERBOSE); 2, the prototype of handle_kernel_image() should be changed from 5 parameters to 6 parameters; 3, the return value type of huge_ptep_get_and_clear() should be changed from void to pte_t (and the function implementation should be also changed). Huacai > > Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-05-31 8:17 ` Huacai Chen @ 2022-05-31 11:15 ` Arnd Bergmann 2022-05-31 16:01 ` Huacai Chen 0 siblings, 1 reply; 26+ messages in thread From: Arnd Bergmann @ 2022-05-31 11:15 UTC (permalink / raw) To: Huacai Chen Cc: musl, WANG Xuerui, Linus Torvalds, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen On Tue, May 31, 2022 at 10:17 AM Huacai Chen <chenhuacai@kernel.org> wrote: > On Tue, May 31, 2022 at 4:09 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > On Tue, May 31, 2022 at 9:50 AM Huacai Chen <chenhuacai@kernel.org> wrote: > > > On Mon, May 30, 2022 at 11:56 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@xen0n.name> wrote: > > > > > Now I see > > > > > the loongarch-next HEAD is already rebased on top of what I believe to > > > > > be the current main branch, however I vaguely remember that it's not > > > > > good to base one's patches on top of "some random commit", so I wonder > > > > > whether the current branch state is appropriate for a PR? > > > > > > > > You are correct, a pull request should always be based on an -rc, orat least > > > > have the minimum set of dependencies. The branch was previously > > > > based on top of the spinlock implementation, which is still the best > > > > place to start here. > > > I have a difficult problem to select the base. Take swiotlb_init() as > > > an example: If I select 5.18-rc1, I should use swiotlb_init(1); if I > > > select Linus' latest tree, I should use swiotlb_init(true, > > > SWIOTLB_VERBOSE). However, if I select 5.18-rc1, linux-next will have > > > a build error because the code there expect swiotlb_init(true, > > > SWIOTLB_VERBOSE). > > > > Ok, I see. This is the kind of thing we normally prevent by having everything > > in linux-next for a few weeks before the merge window. How many issues > > like this are you aware of? If it's just the swiotlb, you could try merging > > the swiotlb branch that is in mainline now on top of the spinlock branch, > > and still get a minimum set of dependencies. If there are many more, > > then basing on top of the current mainline is probably less intrusive after > > all. > I have 3 issues: > 1, swiotlb_init(1) --> swiotlb_init(true, SWIOTLB_VERBOSE); > 2, the prototype of handle_kernel_image() should be changed from 5 > parameters to 6 parameters; > 3, the return value type of huge_ptep_get_and_clear() should be > changed from void to pte_t (and the function implementation should be > also changed). Ok, I see. Let's stay with the base on top of a mainline snapshot then. Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-05-31 11:15 ` Arnd Bergmann @ 2022-05-31 16:01 ` Huacai Chen 2022-05-31 20:07 ` Arnd Bergmann 2022-06-01 5:52 ` WANG Xuerui 0 siblings, 2 replies; 26+ messages in thread From: Huacai Chen @ 2022-05-31 16:01 UTC (permalink / raw) To: Arnd Bergmann Cc: musl, WANG Xuerui, Linus Torvalds, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen Hi, Arnd, On Tue, May 31, 2022 at 7:15 PM Arnd Bergmann <arnd@kernel.org> wrote: > > On Tue, May 31, 2022 at 10:17 AM Huacai Chen <chenhuacai@kernel.org> wrote: > > On Tue, May 31, 2022 at 4:09 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > > > On Tue, May 31, 2022 at 9:50 AM Huacai Chen <chenhuacai@kernel.org> wrote: > > > > On Mon, May 30, 2022 at 11:56 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > > On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@xen0n.name> wrote: > > > > > > Now I see > > > > > > the loongarch-next HEAD is already rebased on top of what I believe to > > > > > > be the current main branch, however I vaguely remember that it's not > > > > > > good to base one's patches on top of "some random commit", so I wonder > > > > > > whether the current branch state is appropriate for a PR? > > > > > > > > > > You are correct, a pull request should always be based on an -rc, orat least > > > > > have the minimum set of dependencies. The branch was previously > > > > > based on top of the spinlock implementation, which is still the best > > > > > place to start here. > > > > I have a difficult problem to select the base. Take swiotlb_init() as > > > > an example: If I select 5.18-rc1, I should use swiotlb_init(1); if I > > > > select Linus' latest tree, I should use swiotlb_init(true, > > > > SWIOTLB_VERBOSE). However, if I select 5.18-rc1, linux-next will have > > > > a build error because the code there expect swiotlb_init(true, > > > > SWIOTLB_VERBOSE). > > > > > > Ok, I see. This is the kind of thing we normally prevent by having everything > > > in linux-next for a few weeks before the merge window. How many issues > > > like this are you aware of? If it's just the swiotlb, you could try merging > > > the swiotlb branch that is in mainline now on top of the spinlock branch, > > > and still get a minimum set of dependencies. If there are many more, > > > then basing on top of the current mainline is probably less intrusive after > > > all. > > I have 3 issues: > > 1, swiotlb_init(1) --> swiotlb_init(true, SWIOTLB_VERBOSE); > > 2, the prototype of handle_kernel_image() should be changed from 5 > > parameters to 6 parameters; > > 3, the return value type of huge_ptep_get_and_clear() should be > > changed from void to pte_t (and the function implementation should be > > also changed). > > Ok, I see. Let's stay with the base on top of a mainline snapshot then. 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 Huacai > > Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-05-31 16:01 ` Huacai Chen @ 2022-05-31 20:07 ` Arnd Bergmann 2022-05-31 20:40 ` Arnd Bergmann 2022-06-01 1:13 ` WANG Xuerui 2022-06-01 5:52 ` WANG Xuerui 1 sibling, 2 replies; 26+ messages in thread From: Arnd Bergmann @ 2022-05-31 20:07 UTC (permalink / raw) To: Huacai Chen Cc: musl, WANG Xuerui, Linus Torvalds, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen On Tue, May 31, 2022 at 6:01 PM Huacai Chen <chenhuacai@kernel.org> wrote: > On Tue, May 31, 2022 at 7:15 PM Arnd Bergmann <arnd@kernel.org> wrote: > > On Tue, May 31, 2022 at 10:17 AM Huacai Chen <chenhuacai@kernel.org> 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. Ok, glad you got that working. What about the ACPI changes? I see that these are needed to get a clean build, and as I understood it, they are supposed to get merged through the acpica tree. > 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). Right, that is ok to keep in there, we should fix that by adding a Kconfig dependency for the driver. It looks like it has a CONFIG_ACPI dependency, so it is currently limited to x86/arm64/ia64, which all have the short cmpxchg(), but in reality this driver can only work on x86 and arm64. Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-05-31 20:07 ` Arnd Bergmann @ 2022-05-31 20:40 ` Arnd Bergmann 2022-06-01 0:41 ` WANG Xuerui 2022-06-01 1:13 ` WANG Xuerui 1 sibling, 1 reply; 26+ messages in thread From: Arnd Bergmann @ 2022-05-31 20:40 UTC (permalink / raw) To: Huacai Chen Cc: musl, WANG Xuerui, Linus Torvalds, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen On Tue, May 31, 2022 at 10:07 PM Arnd Bergmann <arnd@kernel.org> wrote: > > On Tue, May 31, 2022 at 6:01 PM Huacai Chen <chenhuacai@kernel.org> wrote: > > On Tue, May 31, 2022 at 7:15 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > On Tue, May 31, 2022 at 10:17 AM Huacai Chen <chenhuacai@kernel.org> 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. > > Ok, glad you got that working. > From an allmodconfig build, I see two more things that could be addressed first: drivers/pci/probe.c: In function 'pci_scan_bridge_extend': drivers/pci/probe.c:1298:44: error: implicit declaration of function 'pcibios_assign_all_busses' [-Werror=implicit-function-declaration] 1298 | if ((secondary || subordinate) && !pcibios_assign_all_busses() && | ^~~~~~~~~~~~~~~~~~~~~~~~~ drivers/pci/setup-res.c: In function '__pci_assign_resource': drivers/pci/setup-res.c:257:46: error: 'PCIBIOS_MIN_IO' undeclared (first use in this function) 257 | min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM; | ^~~~~~~~~~~~~~ drivers/pci/setup-res.c:257:46: note: each undeclared identifier is reported only once for each function it appears in drivers/pci/setup-res.c:257:63: error: 'PCIBIOS_MIN_MEM' undeclared (first use in this function) 257 | min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM; | ^~~~~~~~~~~~~~~ drivers/pci/quirks.c: In function 'quirk_isa_dma_hangs': drivers/pci/quirks.c:252:14: error: 'isa_dma_bridge_buggy' undeclared (first use in this function) 252 | if (!isa_dma_bridge_buggy) { | ^~~~~~~~~~~~~~~~~~~~ I think you accidentally dropped the asm/pci.h header, so adding that one back should make it build again. lib/test_printf.c:215: warning: "PTR" redefined 215 | #define PTR ((void *)0xffff0123456789abUL) | In file included from /git/arm-soc/arch/loongarch/include/asm/vdso/vdso.h:9, from /git/arm-soc/arch/loongarch/include/asm/vdso/gettimeofday.h:13, from /git/arm-soc/include/vdso/datapage.h:137, from /git/arm-soc/arch/loongarch/include/asm/vdso.h:11, from /git/arm-soc/arch/loongarch/include/asm/elf.h:13, from /git/arm-soc/include/linux/elf.h:6, from /git/arm-soc/include/linux/module.h:19, from /git/arm-soc/lib/test_printf.c:10: /git/arm-soc/arch/loongarch/include/asm/asm.h:182: note: this is the location of the previous definition 182 | #define PTR .dword | Not sure what the best fix is for this, maybe the contents of asm/asm.h could just be hidden in an "#idef __ASSEMBLER__" check. This can be a follow-up patch when the branch is merged. Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-05-31 20:40 ` Arnd Bergmann @ 2022-06-01 0:41 ` WANG Xuerui 0 siblings, 0 replies; 26+ messages in thread From: WANG Xuerui @ 2022-06-01 0:41 UTC (permalink / raw) To: Arnd Bergmann, Huacai Chen Cc: musl, WANG Xuerui, Linus Torvalds, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen On 6/1/22 04:40, Arnd Bergmann wrote: > lib/test_printf.c:215: warning: "PTR" redefined > 215 | #define PTR ((void *)0xffff0123456789abUL) > | > In file included from /git/arm-soc/arch/loongarch/include/asm/vdso/vdso.h:9, > from > /git/arm-soc/arch/loongarch/include/asm/vdso/gettimeofday.h:13, > from /git/arm-soc/include/vdso/datapage.h:137, > from /git/arm-soc/arch/loongarch/include/asm/vdso.h:11, > from /git/arm-soc/arch/loongarch/include/asm/elf.h:13, > from /git/arm-soc/include/linux/elf.h:6, > from /git/arm-soc/include/linux/module.h:19, > from /git/arm-soc/lib/test_printf.c:10: > /git/arm-soc/arch/loongarch/include/asm/asm.h:182: note: this is the > location of the previous definition > 182 | #define PTR .dword > | > > Not sure what the best fix is for this, maybe the contents of asm/asm.h could > just be hidden in an "#idef __ASSEMBLER__" check. This can be a follow-up > patch when the branch is merged. Ah, the dreaded PTR... This has plagued Loongson users since antiquity (i.e. the MIPS era). It must have been the case that the arch/loongarch was based on an earlier version of arch/mips, that didn't have the commit fa62f39dc7e25 ("MIPS: Fix build error due to PTR used in more places"). So the fix would be simple: just rename the PTR to something else. MIPS changed that to PTR_WD and maybe we could re-use that name. But I agree that wrapping the whole asm/asm.h with an #ifdef __ASSEMBLY__ is very reasonable regardless. Maybe both could be done. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-05-31 20:07 ` Arnd Bergmann 2022-05-31 20:40 ` Arnd Bergmann @ 2022-06-01 1:13 ` WANG Xuerui 1 sibling, 0 replies; 26+ messages in thread From: WANG Xuerui @ 2022-06-01 1:13 UTC (permalink / raw) To: Arnd Bergmann, Huacai Chen Cc: musl, WANG Xuerui, Linus Torvalds, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen On 6/1/22 04:07, Arnd Bergmann wrote: > On Tue, May 31, 2022 at 6:01 PM Huacai Chen <chenhuacai@kernel.org> wrote: >> On Tue, May 31, 2022 at 7:15 PM Arnd Bergmann <arnd@kernel.org> wrote: >>> On Tue, May 31, 2022 at 10:17 AM Huacai Chen <chenhuacai@kernel.org> 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. > Ok, glad you got that working. > > What about the ACPI changes? I see that these are needed to get a clean build, > and as I understood it, they are supposed to get merged through the > acpica tree. I think the acpica bits could be dropped with some effort too; the main dependency on the various ACPI 6.5 tables are the SMP bits, which relies on the new MADT CPUINTC tables. While the others also provide information, they're not as fundamental as this, and even this CPUINTC piece can be taken out given we can't run this branch on any real LoongArch hardware after all (due to the irqchip changes being backed out), I think we can just leave the remaining bits dummy-initialized with some simple comment. We can review once the new branch with only arch/loongarch changes is out. >> 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). > Right, that is ok to keep in there, we should fix that by adding a Kconfig > dependency for the driver. It looks like it has a CONFIG_ACPI dependency, > so it is currently limited to x86/arm64/ia64, which all have the short > cmpxchg(), > but in reality this driver can only work on x86 and arm64. In case this isn't obvious to any non-native English speaker: the driver is written for the Microsoft Surface, which only has x86 and arm64 variants to this date and the list is probably not going to expand in the foreseeable future, so the word "work" here takes a quite literal sense. ;-) I agree a tiny fix for that driver could be added later that limits the driver to X86 || ARM64. As a popular product line, adding support for yet another architecture would be a news visible enough for the crowd that they'll come and tweak the Kconfig themselves. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-05-31 16:01 ` Huacai Chen 2022-05-31 20:07 ` Arnd Bergmann @ 2022-06-01 5:52 ` WANG Xuerui 2022-06-01 7:41 ` Arnd Bergmann 1 sibling, 1 reply; 26+ messages in thread From: WANG Xuerui @ 2022-06-01 5:52 UTC (permalink / raw) To: Huacai Chen, Arnd Bergmann Cc: musl, WANG Xuerui, Linus Torvalds, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Ard Biesheuvel, Huacai Chen 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. After some small tweaks: - adding "#include <asm/irqflags.h>" 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 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. 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. Arnd, what do you think about the current branch's status? Do Huacai need to send a quick final v12 to gather tags? [1]: https://lore.kernel.org/all/20220518092619.1269111-1-chenhuacai@loongson.cn/ [2]: https://sourceware.org/pipermail/libc-alpha/2022-May/139127.html [3]: https://go-review.googlesource.com/c/go/+/407694 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-06-01 5:52 ` WANG Xuerui @ 2022-06-01 7:41 ` Arnd Bergmann 2022-06-01 16:01 ` Ard Biesheuvel 0 siblings, 1 reply; 26+ messages in thread From: Arnd Bergmann @ 2022-06-01 7:41 UTC (permalink / raw) To: WANG Xuerui Cc: Huacai Chen, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, musl, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Linus Torvalds, Ard Biesheuvel, Huacai Chen On Wed, Jun 1, 2022 at 7:52 AM WANG Xuerui <kernel@xen0n.name> 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 <asm/irqflags.h>" 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? > Arnd, what do you think about the current branch's status? Do Huacai > need to send a quick final v12 to gather tags? I think that would be good, yes. Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-06-01 7:41 ` Arnd Bergmann @ 2022-06-01 16:01 ` Ard Biesheuvel 2022-06-01 16:44 ` WANG Xuerui 0 siblings, 1 reply; 26+ messages in thread From: Ard Biesheuvel @ 2022-06-01 16:01 UTC (permalink / raw) To: Arnd Bergmann Cc: WANG Xuerui, Huacai Chen, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, musl, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Linus Torvalds, Huacai Chen On Wed, 1 Jun 2022 at 09:41, Arnd Bergmann <arnd@kernel.org> wrote: > > On Wed, Jun 1, 2022 at 7:52 AM WANG Xuerui <kernel@xen0n.name> 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 <asm/irqflags.h>" 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-06-01 16:01 ` Ard Biesheuvel @ 2022-06-01 16:44 ` WANG Xuerui 2022-06-02 10:02 ` Huacai Chen 0 siblings, 1 reply; 26+ messages in thread From: WANG Xuerui @ 2022-06-01 16:44 UTC (permalink / raw) To: Ard Biesheuvel, Arnd Bergmann Cc: WANG Xuerui, Huacai Chen, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, musl, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Linus Torvalds, Huacai Chen Hi Ard, On 6/2/22 00:01, Ard Biesheuvel wrote: > On Wed, 1 Jun 2022 at 09:41, Arnd Bergmann <arnd@kernel.org> wrote: >> On Wed, Jun 1, 2022 at 7:52 AM WANG Xuerui <kernel@xen0n.name> 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 <asm/irqflags.h>" 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? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-06-01 16:44 ` WANG Xuerui @ 2022-06-02 10:02 ` Huacai Chen 0 siblings, 0 replies; 26+ messages in thread From: Huacai Chen @ 2022-06-02 10:02 UTC (permalink / raw) To: WANG Xuerui, Ard Biesheuvel Cc: Arnd Bergmann, linux-arch, GNU C Library, Yoshinori Sato, Peter Zijlstra, Marc Zyngier, Masahiro Yamada, musl, Linux Kernel Mailing List, Jiaxun Yang, ACPI Devel Maling List, Jianmin Lv, linux-pci, Linus Torvalds, Huacai Chen Hi, Ard, On Thu, Jun 2, 2022 at 12:44 AM WANG Xuerui <kernel@xen0n.name> wrote: > > Hi Ard, > > On 6/2/22 00:01, Ard Biesheuvel wrote: > > On Wed, 1 Jun 2022 at 09:41, Arnd Bergmann <arnd@kernel.org> wrote: > >> On Wed, Jun 1, 2022 at 7:52 AM WANG Xuerui <kernel@xen0n.name> 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 <asm/irqflags.h>" 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... I'm sorry that you haven't seen my reply, but as Xuerui said, I have replied to your review. :) Since you didn't reply to my answers again, I supposed that you consider "everything is OK". :) Now I plan to send V13, with the following changes: 1, Remove kernel_version string in efistub; 2, Remove the boardinfo knob in /sys/firmware/efi; 3, Add a reference in the commit message to explain while we need a magic number [1]. [1] https://lists.gnu.org/archive/html/grub-devel/2021-10/msg00215.html Huacai > > 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? > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] asm-generic changes for 5.19 2022-05-29 11:24 ` Arnd Bergmann 2022-05-29 13:10 ` WANG Xuerui @ 2022-05-29 13:21 ` Marc Zyngier 2022-05-30 6:28 ` Huacai Chen 2022-05-30 8:23 ` Arnd Bergmann 1 sibling, 2 replies; 26+ messages in thread From: Marc Zyngier @ 2022-05-29 13:21 UTC (permalink / raw) To: Arnd Bergmann Cc: Linus Torvalds, linux-arch, Linux Kernel Mailing List, Yoshinori Sato, Palmer Dabbelt, Masahiro Yamada, Peter Zijlstra, Huacai Chen, WANG Xuerui, libc-alpha, musl, ardb, linux-acpi, linux-pci On Sun, 29 May 2022 12:24:29 +0100, Arnd Bergmann <arnd@kernel.org> wrote: > > On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <arnd@kernel.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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] asm-generic changes for 5.19 2022-05-29 13:21 ` Marc Zyngier @ 2022-05-30 6:28 ` Huacai Chen 2022-05-30 8:36 ` [musl] " Arnd Bergmann 2022-05-30 8:23 ` Arnd Bergmann 1 sibling, 1 reply; 26+ messages in thread From: Huacai Chen @ 2022-05-30 6:28 UTC (permalink / raw) To: Marc Zyngier Cc: Arnd Bergmann, Linus Torvalds, linux-arch, Linux Kernel Mailing List, Yoshinori Sato, Palmer Dabbelt, Masahiro Yamada, Peter Zijlstra, Huacai Chen, WANG Xuerui, libc-alpha, musl, Ard Biesheuvel, ACPI Devel Maling List, linux-pci, Rafael J. Wysocki, Bjorn Helgaas On Sun, May 29, 2022 at 9:21 PM Marc Zyngier <maz@kernel.org> wrote: > > On Sun, 29 May 2022 12:24:29 +0100, > Arnd Bergmann <arnd@kernel.org> wrote: > > > > On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <arnd@kernel.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). (adding linux-pci and linux-acpi maintainers to Cc) Hi Bjorn and Rafael, I'd like to confirm the review status of the respective LoongArch patchsets ([1], [2]), to see if we can make it into this merge window. Specifically: I'd like to confirm with Bjorn, if the PCI patches are in a reasonable shape and can get an Acked-by. And Rafael: would you sync with the ACPICA repos to bring in the LoongArch changes upstreamed there? [1]: https://lore.kernel.org/linux-pci/20220430084846.3127041-1-chenhuacai@loongson.cn/T/#t [2]: https://lore.kernel.org/linux-acpi/20220306111838.810959-1-chenhuacai@loongson.cn/T/#t Thanks, Huacai > > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 2022-05-30 6:28 ` Huacai Chen @ 2022-05-30 8:36 ` Arnd Bergmann 0 siblings, 0 replies; 26+ messages in thread From: Arnd Bergmann @ 2022-05-30 8:36 UTC (permalink / raw) To: musl Cc: Marc Zyngier, Linus Torvalds, linux-arch, Linux Kernel Mailing List, Yoshinori Sato, Palmer Dabbelt, Masahiro Yamada, Peter Zijlstra, Huacai Chen, WANG Xuerui, libc-alpha, Ard Biesheuvel, ACPI Devel Maling List, linux-pci, Rafael J. Wysocki, Bjorn Helgaas On Mon, May 30, 2022 at 8:28 AM Huacai Chen <chenhuacai@kernel.org> wrote: > On Sun, May 29, 2022 at 9:21 PM Marc Zyngier <maz@kernel.org> wrote: > > On Sun, 29 May 2022 12:24:29 +0100, Arnd Bergmann <arnd@kernel.org> wrote: > > > > 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). > (adding linux-pci and linux-acpi maintainers to Cc) > > I'd like to confirm the review status of the respective LoongArch > patchsets ([1], [2]), to see if we can make it into this merge window. In the meantime, can you rebase the tree once more to split out the driver patches and make sure the architecture port without the drivers still builds cleanly (at least defconfig and allmodconfig) using the compiler from [1]? If this requires additional patches, please add them on top. Once that is done, we can ask Linus to consider merging the branch for the architecture port, while you keep working with the pci and irqchip maintainers to merge the drivers either for 5.19 or a future release. While this means merging a branch that does not actually work on any hardware by itself, it should be sufficient for the libc patches to consider the ABI stable, and it is consistent with how we keep CPU architecture support separate from platform driver support elsewhere. Arnd [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.1.0/x86_64-gcc-12.1.0-nolibc-loongarch64-linux.tar.xz ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] asm-generic changes for 5.19 2022-05-29 13:21 ` Marc Zyngier 2022-05-30 6:28 ` Huacai Chen @ 2022-05-30 8:23 ` Arnd Bergmann 1 sibling, 0 replies; 26+ messages in thread From: Arnd Bergmann @ 2022-05-30 8:23 UTC (permalink / raw) To: Marc Zyngier Cc: Linus Torvalds, linux-arch, Linux Kernel Mailing List, Yoshinori Sato, Palmer Dabbelt, Masahiro Yamada, Peter Zijlstra, Huacai Chen, WANG Xuerui, libc-alpha, musl, ardb, linux-acpi, linux-pci On Sun, May 29, 2022 at 3:21 PM Marc Zyngier <maz@kernel.org> wrote: > > 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). Ok, thanks for taking another look. I think we should just merge the port without the drivers then, and you can make a decision on the irqchip drivers after you've reviewed the latest version. Arnd ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2022-06-02 10:02 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-26 15:00 [GIT PULL] asm-generic changes for 5.19 Arnd Bergmann 2022-05-26 18:20 ` pr-tracker-bot 2022-05-29 11:24 ` Arnd Bergmann 2022-05-29 13:10 ` WANG Xuerui 2022-05-30 8:20 ` Arnd Bergmann 2022-05-30 13:01 ` Huacai Chen 2022-05-30 15:00 ` WANG Xuerui 2022-05-30 15:55 ` [musl] " Arnd Bergmann 2022-05-31 7:50 ` Huacai Chen 2022-05-31 8:09 ` Arnd Bergmann 2022-05-31 8:17 ` Huacai Chen 2022-05-31 11:15 ` Arnd Bergmann 2022-05-31 16:01 ` Huacai Chen 2022-05-31 20:07 ` Arnd Bergmann 2022-05-31 20:40 ` Arnd Bergmann 2022-06-01 0:41 ` WANG Xuerui 2022-06-01 1:13 ` WANG Xuerui 2022-06-01 5:52 ` WANG Xuerui 2022-06-01 7:41 ` Arnd Bergmann 2022-06-01 16:01 ` Ard Biesheuvel 2022-06-01 16:44 ` WANG Xuerui 2022-06-02 10:02 ` Huacai Chen 2022-05-29 13:21 ` Marc Zyngier 2022-05-30 6:28 ` Huacai Chen 2022-05-30 8:36 ` [musl] " Arnd Bergmann 2022-05-30 8:23 ` Arnd Bergmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).