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
On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <[email protected]> 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
On Sun, 29 May 2022 12:24:29 +0100,
Arnd Bergmann <[email protected]> wrote:
>
> On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <[email protected]> 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.
On 5/29/22 19:24, Arnd Bergmann wrote:
> On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <[email protected]> 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
On Sun, May 29, 2022 at 3:10 PM WANG Xuerui <[email protected]> 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
Hi, Arnd,
On Mon, May 30, 2022 at 4:21 PM Arnd Bergmann <[email protected]> wrote:
>
> On Sun, May 29, 2022 at 3:10 PM WANG Xuerui <[email protected]> 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
On Sun, May 29, 2022 at 9:21 PM Marc Zyngier <[email protected]> wrote:
>
> On Sun, 29 May 2022 12:24:29 +0100,
> Arnd Bergmann <[email protected]> wrote:
> >
> > On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <[email protected]> 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/[email protected]/T/#t
[2]: https://lore.kernel.org/linux-acpi/[email protected]/T/#t
Thanks,
Huacai
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
On Sun, May 29, 2022 at 3:21 PM Marc Zyngier <[email protected]> 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
On 5/30/22 21:01, Huacai Chen wrote:
> Hi, Arnd,
>
> On Mon, May 30, 2022 at 4:21 PM Arnd Bergmann <[email protected]> wrote:
>> On Sun, May 29, 2022 at 3:10 PM WANG Xuerui <[email protected]> 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?
On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <[email protected]> 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