kernel/arch/riscv/include/asm/bitops.h, branch linux-rolling-stable

riscv: remove irqflags.h inclusion in asm/bitops.h

2026-01-07T20:16:38Z

The arch/riscv/include/asm/bitops.h does not functionally require including /linux/irqflags.h. Additionally, adding arch/riscv/include/asm/percpu.h causes a circular inclusion: kernel/bounds.c ->include/linux/log2.h ->include/linux/bitops.h ->arch/riscv/include/asm/bitops.h ->include/linux/irqflags.h ->include/linux/find.h ->return val ? __ffs(val) : size; ->arch/riscv/include/asm/bitops.h The compilation log is as follows: CC kernel/bounds.s In file included from ./include/linux/bitmap.h:11, from ./include/linux/cpumask.h:12, from ./arch/riscv/include/asm/processor.h:55, from ./arch/riscv/include/asm/thread_info.h:42, from ./include/linux/thread_info.h:60, from ./include/asm-generic/preempt.h:5, from ./arch/riscv/include/generated/asm/preempt.h:1, from ./include/linux/preempt.h:79, from ./arch/riscv/include/asm/percpu.h:8, from ./include/linux/irqflags.h:19, from ./arch/riscv/include/asm/bitops.h:14, from ./include/linux/bitops.h:68, from ./include/linux/log2.h:12, from kernel/bounds.c:13: ./include/linux/find.h: In function 'find_next_bit': ./include/linux/find.h:66:30: error: implicit declaration of function '__ffs' [-Wimplicit-function-declaration] 66 | return val ? __ffs(val) : size; | ^~~~~ Signed-off-by: Yunhui Cui Acked-by: Yury Norov (NVIDIA) Link: https://patch.msgid.link/20251216014721.42262-2-cuiyunhui@bytedance.com Signed-off-by: Paul Walmsley

riscv: bitops: Use riscv_has_extension_likely

2025-11-19T16:19:28Z

Use riscv_has_extension_likely() to check for RISCV_ISA_EXT_ZBB, replacing the use of asm goto with ALTERNATIVE. The "likely" variant is used to match the behavior of the original implementation using ALTERNATIVE("j %l[legacy]", "nop", ...). Signed-off-by: Vivian Wang Link: https://patch.msgid.link/20251020-riscv-altn-helper-wip-v4-4-ef941c87669a@iscas.ac.cn Signed-off-by: Paul Walmsley

riscv: Add __attribute_const__ to ffs()-family implementations

2025-09-08T21:58:51Z

While tracking down a problem where constant expressions used by BUILD_BUG_ON() suddenly stopped working[1], we found that an added static initializer was convincing the compiler that it couldn't track the state of the prior statically initialized value. Tracing this down found that ffs() was used in the initializer macro, but since it wasn't marked with __attribute__const__, the compiler had to assume the function might change variable states as a side-effect (which is not true for ffs(), which provides deterministic math results). Add missing __attribute_const__ annotations to RISC-V's implementations of variable__ffs(), variable__fls(), and variable_ffs() functions. These are pure mathematical functions that always return the same result for the same input with no side effects, making them eligible for compiler optimization. Build tested ARCH=riscv defconfig with GCC riscv64-linux-gnu 14.2.0. Link: https://github.com/KSPP/linux/issues/364 [1] Tested-by: Alexandre Ghiti Acked-by: Alexandre Ghiti Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20250804164417.1612371-9-kees@kernel.org Signed-off-by: Kees Cook

Merge tag 'riscv-for-linus-6.15-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux

2025-04-04T16:49:17Z

Pull RISC-V updates from Palmer Dabbelt: - The sub-architecture selection Kconfig system has been cleaned up, the documentation has been improved, and various detections have been fixed - The vector-related extensions dependencies are now validated when parsing from device tree and in the DT bindings - Misaligned access probing can be overridden via a kernel command-line parameter, along with various fixes to misalign access handling - Support for relocatable !MMU kernels builds - Support for hpge pfnmaps, which should improve TLB utilization - Support for runtime constants, which improves the d_hash() performance - Support for bfloat16, Zicbom, Zaamo, Zalrsc, Zicntr, Zihpm - Various fixes, including: - We were missing a secondary mmu notifier call when flushing the tlb which is required for IOMMU - Fix ftrace panics by saving the registers as expected by ftrace - Fix a couple of stimecmp usage related to cpu hotplug - purgatory_start is now aligned as per the STVEC requirements - A fix for hugetlb when calculating the size of non-present PTEs * tag 'riscv-for-linus-6.15-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: (65 commits) riscv: Add norvc after .option arch in runtime const riscv: Make sure toolchain supports zba before using zba instructions riscv/purgatory: 4B align purgatory_start riscv/kexec_file: Handle R_RISCV_64 in purgatory relocator selftests: riscv: fix v_exec_initval_nolibc.c riscv: Fix hugetlb retrieval of number of ptes in case of !present pte riscv: print hartid on bringup riscv: Add norvc after .option arch in runtime const riscv: Remove CONFIG_PAGE_OFFSET riscv: Support CONFIG_RELOCATABLE on riscv32 asm-generic: Always define Elf_Rel and Elf_Rela riscv: Support CONFIG_RELOCATABLE on NOMMU riscv: Allow NOMMU kernels to access all of RAM riscv: Remove duplicate CONFIG_PAGE_OFFSET definition RISC-V: errata: Use medany for relocatable builds dt-bindings: riscv: document vector crypto requirements dt-bindings: riscv: add vector sub-extension dependencies dt-bindings: riscv: d requires f RISC-V: add f & d extension validation checks RISC-V: add vector crypto extension validation checks ...

Merge patch series "RISC-V: clarify what some RISCV_ISA* config options do & redo Zbb toolchain dependency"

2025-03-18T08:53:10Z

Conor Dooley says: Since one depends on the other, albeit trivially, here's a v4 of the Zbb toolchain dep removal alongside the rewording of Kconfig options I'd sent out before the merge window. I think I like this implementation better than v1, but I couldn't think of a good name for a "public" version of __ALTERNATIVE(), so I used it here directly. Unfortunately "ALTERNATIVE_2_CFG" already exists and I couldn't think of a good way to name an alternative macro that allows for several config options that didn't make the distinction sufficiently clear.. Yell if you have better suggestions than I did. I am a wee bit "worried" that this makes the Kconfig option confusing as it isn't immediately obvious if someone is or is not going to get the toolchain based optimisations. Cheers, Conor. * patches from https://lore.kernel.org/r/20241024-aspire-rectify-9982da6943e5@spud: RISC-V: separate Zbb optimisations requiring and not requiring toolchain support RISC-V: clarify what some RISCV_ISA* config options do Link: https://lore.kernel.org/r/20241024-aspire-rectify-9982da6943e5@spud Signed-off-by: Alexandre Ghiti

RISC-V: separate Zbb optimisations requiring and not requiring toolchain support

2025-03-18T08:53:02Z

It seems a bit ridiculous to require toolchain support for BPF to assemble Zbb instructions, so move the dependency on toolchain support for Zbb optimisations out of the Kconfig option and to the callsites. Zbb support has always depended on alternatives, so while adjusting the config options guarding optimisations, remove any checks for whether or not alternatives are enabled. Reviewed-by: Andrew Jones Signed-off-by: Conor Dooley Reviewed-by: Charlie Jenkins Reviewed-by: Samuel Holland Link: https://lore.kernel.org/r/20241024-chump-freebase-d26b6d81af33@spud Signed-off-by: Alexandre Ghiti

riscv: fix test_and_{set,clear}_bit ordering documentation

2025-03-12T23:27:15Z

test_and_{set,clear}_bit are fully ordered as specified in Documentation/atomic_bitops.txt. Fix incorrect comment stating otherwise. Note that the implementation is correct since commit 9347ce54cd69 ("RISC-V: __test_and_op_bit_ord should be strongly ordered") was introduced. Signed-off-by: Ignacio Encinas Signed-off-by: Yury Norov

riscv: Always inline bitops

2024-12-30T18:29:25Z

When building allmodconfig + ThinLTO with certain versions of clang, arch_set_bit() may not be inlined, resulting in a modpost warning: WARNING: modpost: vmlinux: section mismatch in reference: arch_set_bit+0x58 (section: .text.arch_set_bit) -> numa_nodes_parsed (section: .init.data) acpi_numa_rintc_affinity_init() calls arch_set_bit() via __node_set() with numa_nodes_parsed, which is marked as __initdata. If arch_set_bit() is not inlined, modpost will flag that it is being called with data that will be freed after init. As acpi_numa_rintc_affinity_init() is marked as __init, there is not actually a functional issue here. However, the bitop functions should be marked as __always_inline, so that they work consistently for init and non-init code, which the comment in include/linux/nodemask.h alludes to. This matches s390 and x86's implementations. Signed-off-by: Nathan Chancellor Signed-off-by: Yury Norov

riscv: Enable bitops instrumentation

2024-09-19T08:10:04Z

Instead of implementing the bitops functions directly in assembly, provide the arch_-prefixed versions and use the wrappers from asm-generic to add instrumentation. This improves KASAN coverage and fixes the kasan_bitops_generic() unit test. Signed-off-by: Samuel Holland Reviewed-by: Alexandre Ghiti Tested-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20240801033725.28816-3-samuel.holland@sifive.com Signed-off-by: Palmer Dabbelt

riscv: Remove unnecessary int cast in variable_fls()

2024-07-10T21:30:35Z

__builtin_clz() returns an int and casting the whole expression to int is unnecessary. Remove it. Signed-off-by: Thorsten Blum Signed-off-by: Yury Norov