* [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8
@ 2026-04-15 9:38 ` Jinjie Ruan
0 siblings, 0 replies; 18+ messages in thread
From: Jinjie Ruan @ 2026-04-15 9:38 UTC (permalink / raw)
To: pjw, palmer, aou, alex, yury.norov, linux, arnd, cp0613,
linux-riscv, linux-kernel, linux-arch
Cc: ruanjinjie
The RISC-V Bit-manipulation Extension for Cryptography (Zbkb) provides
the 'brev8' instruction, which reverses the bits within each byte.
Combined with the 'rev8' instruction (from Zbb or Zbkb), which reverses
the byte order of a register, we can efficiently implement 16-bit,
32-bit, and (on RV64) 64-bit bit reversal.
This is significantly faster than the default software table-lookup
implementation in lib/bitrev.c, as it replaces memory accesses and
multiple arithmetic operations with just two or three hardware
instructions.
Select HAVE_ARCH_BITREVERSE and provide <asm/bitrev.h> to utilize
these instructions when the Zbkb extension is available at runtime
via the alternatives mechanism.
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/bitrev.h | 41 +++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+)
create mode 100644 arch/riscv/include/asm/bitrev.h
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 90c531e6abf5..05f2b2166a83 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -128,6 +128,7 @@ config RISCV
select HAS_IOPORT if MMU
select HAVE_ALIGNED_STRUCT_PAGE
select HAVE_ARCH_AUDITSYSCALL
+ select HAVE_ARCH_BITREVERSE if RISCV_ISA_ZBKB
select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
diff --git a/arch/riscv/include/asm/bitrev.h b/arch/riscv/include/asm/bitrev.h
new file mode 100644
index 000000000000..9f205ac84796
--- /dev/null
+++ b/arch/riscv/include/asm/bitrev.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_BITREV_H
+#define __ASM_BITREV_H
+
+#include <linux/types.h>
+#include <asm/cpufeature-macros.h>
+#include <asm/hwcap.h>
+#include <asm-generic/bitops/__bitrev.h>
+
+static __always_inline __attribute_const__ u32 __arch_bitrev32(u32 x)
+{
+ unsigned long result = x;
+
+ if (!riscv_has_extension_likely(RISCV_ISA_EXT_ZBKB))
+ return generic___bitrev32(x);
+
+ asm volatile(
+ ".option push\n"
+ ".option arch,+zbkb\n"
+ "rev8 %0, %0\n"
+ "brev8 %0, %0\n"
+ ".option pop"
+ : "+r" (result)
+ );
+
+ if (__riscv_xlen == 64)
+ return (u32)(result >> 32);
+
+ return (u32)result;
+}
+
+static __always_inline __attribute_const__ u16 __arch_bitrev16(u16 x)
+{
+ return __arch_bitrev32((u32)x) >> 16;
+}
+
+static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
+{
+ return __arch_bitrev32((u32)x) >> 24;
+}
+#endif
--
2.34.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8
2026-04-15 9:38 ` Jinjie Ruan
@ 2026-04-15 11:32 ` David Laight
-1 siblings, 0 replies; 18+ messages in thread
From: David Laight @ 2026-04-15 11:32 UTC (permalink / raw)
To: Jinjie Ruan
Cc: pjw, palmer, aou, alex, yury.norov, linux, arnd, cp0613,
linux-riscv, linux-kernel, linux-arch
On Wed, 15 Apr 2026 17:38:27 +0800
Jinjie Ruan <ruanjinjie@huawei.com> wrote:
> The RISC-V Bit-manipulation Extension for Cryptography (Zbkb) provides
> the 'brev8' instruction, which reverses the bits within each byte.
> Combined with the 'rev8' instruction (from Zbb or Zbkb), which reverses
> the byte order of a register, we can efficiently implement 16-bit,
> 32-bit, and (on RV64) 64-bit bit reversal.
>
> This is significantly faster than the default software table-lookup
> implementation in lib/bitrev.c, as it replaces memory accesses and
> multiple arithmetic operations with just two or three hardware
> instructions.
>
> Select HAVE_ARCH_BITREVERSE and provide <asm/bitrev.h> to utilize
> these instructions when the Zbkb extension is available at runtime
> via the alternatives mechanism.
>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/riscv/Kconfig | 1 +
> arch/riscv/include/asm/bitrev.h | 41 +++++++++++++++++++++++++++++++++
> 2 files changed, 42 insertions(+)
> create mode 100644 arch/riscv/include/asm/bitrev.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 90c531e6abf5..05f2b2166a83 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -128,6 +128,7 @@ config RISCV
> select HAS_IOPORT if MMU
> select HAVE_ALIGNED_STRUCT_PAGE
> select HAVE_ARCH_AUDITSYSCALL
> + select HAVE_ARCH_BITREVERSE if RISCV_ISA_ZBKB
> select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
> select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT
> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
> diff --git a/arch/riscv/include/asm/bitrev.h b/arch/riscv/include/asm/bitrev.h
> new file mode 100644
> index 000000000000..9f205ac84796
> --- /dev/null
> +++ b/arch/riscv/include/asm/bitrev.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __ASM_BITREV_H
> +#define __ASM_BITREV_H
> +
> +#include <linux/types.h>
> +#include <asm/cpufeature-macros.h>
> +#include <asm/hwcap.h>
> +#include <asm-generic/bitops/__bitrev.h>
> +
> +static __always_inline __attribute_const__ u32 __arch_bitrev32(u32 x)
> +{
> + unsigned long result = x;
> +
> + if (!riscv_has_extension_likely(RISCV_ISA_EXT_ZBKB))
> + return generic___bitrev32(x);
> +
> + asm volatile(
> + ".option push\n"
> + ".option arch,+zbkb\n"
> + "rev8 %0, %0\n"
It would be better to pass (long)x in for the source.
Might save the compiler doing a register-register move.
> + "brev8 %0, %0\n"
> + ".option pop"
> + : "+r" (result)
> + );
> +
> + if (__riscv_xlen == 64)
> + return (u32)(result >> 32);
Is that right?
ACAICT __riscv_xlen is 32 for 32bit builds and 64 otherwise.
(No idea why riscv has its own private constant for that.)
I'm guessing that 'brev' is bit-reverse (or each byte) and 'rev'
a byteswap, the '8' suffix rather implies it acts on 8 bytes
which makes is 64bit only.
So does 'rev8' even compile for 32bit.
You are also likely to get a warning on 32bit for 'result >> 32'.
> +
> + return (u32)result;
> +}
I'm not sure is is a good idea inline that into its callers.
But I can't think of a way to get either the instructions or
a call patched in at the call site.
> +
> +static __always_inline __attribute_const__ u16 __arch_bitrev16(u16 x)
> +{
> + return __arch_bitrev32((u32)x) >> 16;
> +}
> +
> +static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
> +{
> + return __arch_bitrev32((u32)x) >> 24;
That seems excessive when it could just be a 'brev' instruction.
Oh, and none of the casts on the function call parameters or results
are needed - they are all implied.
David
> +}
> +#endif
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8
@ 2026-04-15 11:32 ` David Laight
0 siblings, 0 replies; 18+ messages in thread
From: David Laight @ 2026-04-15 11:32 UTC (permalink / raw)
To: Jinjie Ruan
Cc: pjw, palmer, aou, alex, yury.norov, linux, arnd, cp0613,
linux-riscv, linux-kernel, linux-arch
On Wed, 15 Apr 2026 17:38:27 +0800
Jinjie Ruan <ruanjinjie@huawei.com> wrote:
> The RISC-V Bit-manipulation Extension for Cryptography (Zbkb) provides
> the 'brev8' instruction, which reverses the bits within each byte.
> Combined with the 'rev8' instruction (from Zbb or Zbkb), which reverses
> the byte order of a register, we can efficiently implement 16-bit,
> 32-bit, and (on RV64) 64-bit bit reversal.
>
> This is significantly faster than the default software table-lookup
> implementation in lib/bitrev.c, as it replaces memory accesses and
> multiple arithmetic operations with just two or three hardware
> instructions.
>
> Select HAVE_ARCH_BITREVERSE and provide <asm/bitrev.h> to utilize
> these instructions when the Zbkb extension is available at runtime
> via the alternatives mechanism.
>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/riscv/Kconfig | 1 +
> arch/riscv/include/asm/bitrev.h | 41 +++++++++++++++++++++++++++++++++
> 2 files changed, 42 insertions(+)
> create mode 100644 arch/riscv/include/asm/bitrev.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 90c531e6abf5..05f2b2166a83 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -128,6 +128,7 @@ config RISCV
> select HAS_IOPORT if MMU
> select HAVE_ALIGNED_STRUCT_PAGE
> select HAVE_ARCH_AUDITSYSCALL
> + select HAVE_ARCH_BITREVERSE if RISCV_ISA_ZBKB
> select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
> select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT
> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
> diff --git a/arch/riscv/include/asm/bitrev.h b/arch/riscv/include/asm/bitrev.h
> new file mode 100644
> index 000000000000..9f205ac84796
> --- /dev/null
> +++ b/arch/riscv/include/asm/bitrev.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __ASM_BITREV_H
> +#define __ASM_BITREV_H
> +
> +#include <linux/types.h>
> +#include <asm/cpufeature-macros.h>
> +#include <asm/hwcap.h>
> +#include <asm-generic/bitops/__bitrev.h>
> +
> +static __always_inline __attribute_const__ u32 __arch_bitrev32(u32 x)
> +{
> + unsigned long result = x;
> +
> + if (!riscv_has_extension_likely(RISCV_ISA_EXT_ZBKB))
> + return generic___bitrev32(x);
> +
> + asm volatile(
> + ".option push\n"
> + ".option arch,+zbkb\n"
> + "rev8 %0, %0\n"
It would be better to pass (long)x in for the source.
Might save the compiler doing a register-register move.
> + "brev8 %0, %0\n"
> + ".option pop"
> + : "+r" (result)
> + );
> +
> + if (__riscv_xlen == 64)
> + return (u32)(result >> 32);
Is that right?
ACAICT __riscv_xlen is 32 for 32bit builds and 64 otherwise.
(No idea why riscv has its own private constant for that.)
I'm guessing that 'brev' is bit-reverse (or each byte) and 'rev'
a byteswap, the '8' suffix rather implies it acts on 8 bytes
which makes is 64bit only.
So does 'rev8' even compile for 32bit.
You are also likely to get a warning on 32bit for 'result >> 32'.
> +
> + return (u32)result;
> +}
I'm not sure is is a good idea inline that into its callers.
But I can't think of a way to get either the instructions or
a call patched in at the call site.
> +
> +static __always_inline __attribute_const__ u16 __arch_bitrev16(u16 x)
> +{
> + return __arch_bitrev32((u32)x) >> 16;
> +}
> +
> +static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
> +{
> + return __arch_bitrev32((u32)x) >> 24;
That seems excessive when it could just be a 'brev' instruction.
Oh, and none of the casts on the function call parameters or results
are needed - they are all implied.
David
> +}
> +#endif
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8
2026-04-15 9:38 ` Jinjie Ruan
@ 2026-04-16 23:14 ` Nathan Chancellor
-1 siblings, 0 replies; 18+ messages in thread
From: Nathan Chancellor @ 2026-04-16 23:14 UTC (permalink / raw)
To: Jinjie Ruan, yury.norov
Cc: pjw, palmer, aou, alex, linux, arnd, cp0613, linux-riscv,
linux-kernel, linux-arch
On Wed, Apr 15, 2026 at 05:38:27PM +0800, Jinjie Ruan wrote:
> The RISC-V Bit-manipulation Extension for Cryptography (Zbkb) provides
> the 'brev8' instruction, which reverses the bits within each byte.
> Combined with the 'rev8' instruction (from Zbb or Zbkb), which reverses
> the byte order of a register, we can efficiently implement 16-bit,
> 32-bit, and (on RV64) 64-bit bit reversal.
>
> This is significantly faster than the default software table-lookup
> implementation in lib/bitrev.c, as it replaces memory accesses and
> multiple arithmetic operations with just two or three hardware
> instructions.
>
> Select HAVE_ARCH_BITREVERSE and provide <asm/bitrev.h> to utilize
> these instructions when the Zbkb extension is available at runtime
> via the alternatives mechanism.
>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/riscv/Kconfig | 1 +
> arch/riscv/include/asm/bitrev.h | 41 +++++++++++++++++++++++++++++++++
> 2 files changed, 42 insertions(+)
> create mode 100644 arch/riscv/include/asm/bitrev.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 90c531e6abf5..05f2b2166a83 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -128,6 +128,7 @@ config RISCV
> select HAS_IOPORT if MMU
> select HAVE_ALIGNED_STRUCT_PAGE
> select HAVE_ARCH_AUDITSYSCALL
> + select HAVE_ARCH_BITREVERSE if RISCV_ISA_ZBKB
> select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
> select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT
> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
> diff --git a/arch/riscv/include/asm/bitrev.h b/arch/riscv/include/asm/bitrev.h
> new file mode 100644
> index 000000000000..9f205ac84796
> --- /dev/null
> +++ b/arch/riscv/include/asm/bitrev.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __ASM_BITREV_H
> +#define __ASM_BITREV_H
> +
> +#include <linux/types.h>
> +#include <asm/cpufeature-macros.h>
> +#include <asm/hwcap.h>
> +#include <asm-generic/bitops/__bitrev.h>
> +
> +static __always_inline __attribute_const__ u32 __arch_bitrev32(u32 x)
> +{
> + unsigned long result = x;
> +
> + if (!riscv_has_extension_likely(RISCV_ISA_EXT_ZBKB))
> + return generic___bitrev32(x);
This breaks the build when CONFIG_HAVE_ARCH_BITREVERSE is set because
generic___bitrev32() ultimately calls generic___bitrev8(), which uses
byte_rev_table but that is only included in lib/bitrev.c when
CONFIG_HAVE_ARCH_BITREVERSE is not set. How was this tested? This seems
a pretty basic build problem that has showed up in a variety of
configurations (at least all the configurations that our CI tests).
$ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- mrproper defconfig all
ERROR: modpost: "byte_rev_table" [lib/zlib_deflate/zlib_deflate.ko] undefined!
ERROR: modpost: "byte_rev_table" [drivers/net/ethernet/spacemit/k1_emac.ko] undefined!
ERROR: modpost: "byte_rev_table" [drivers/net/ethernet/stmicro/stmmac/stmmac.ko] undefined!
https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/24529356842
https://lore.kernel.org/177635154368.6552.7060101263009785041@8692ffc4d55e/
Yury, are you intending to send this series to Linus in the 7.1 merge
window? If not, it shouldn't be in -next at this point.
> + asm volatile(
> + ".option push\n"
> + ".option arch,+zbkb\n"
> + "rev8 %0, %0\n"
> + "brev8 %0, %0\n"
> + ".option pop"
> + : "+r" (result)
> + );
> +
> + if (__riscv_xlen == 64)
> + return (u32)(result >> 32);
> +
> + return (u32)result;
> +}
> +
> +static __always_inline __attribute_const__ u16 __arch_bitrev16(u16 x)
> +{
> + return __arch_bitrev32((u32)x) >> 16;
> +}
> +
> +static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
> +{
> + return __arch_bitrev32((u32)x) >> 24;
> +}
> +#endif
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8
@ 2026-04-16 23:14 ` Nathan Chancellor
0 siblings, 0 replies; 18+ messages in thread
From: Nathan Chancellor @ 2026-04-16 23:14 UTC (permalink / raw)
To: Jinjie Ruan, yury.norov
Cc: pjw, palmer, aou, alex, linux, arnd, cp0613, linux-riscv,
linux-kernel, linux-arch
On Wed, Apr 15, 2026 at 05:38:27PM +0800, Jinjie Ruan wrote:
> The RISC-V Bit-manipulation Extension for Cryptography (Zbkb) provides
> the 'brev8' instruction, which reverses the bits within each byte.
> Combined with the 'rev8' instruction (from Zbb or Zbkb), which reverses
> the byte order of a register, we can efficiently implement 16-bit,
> 32-bit, and (on RV64) 64-bit bit reversal.
>
> This is significantly faster than the default software table-lookup
> implementation in lib/bitrev.c, as it replaces memory accesses and
> multiple arithmetic operations with just two or three hardware
> instructions.
>
> Select HAVE_ARCH_BITREVERSE and provide <asm/bitrev.h> to utilize
> these instructions when the Zbkb extension is available at runtime
> via the alternatives mechanism.
>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/riscv/Kconfig | 1 +
> arch/riscv/include/asm/bitrev.h | 41 +++++++++++++++++++++++++++++++++
> 2 files changed, 42 insertions(+)
> create mode 100644 arch/riscv/include/asm/bitrev.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 90c531e6abf5..05f2b2166a83 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -128,6 +128,7 @@ config RISCV
> select HAS_IOPORT if MMU
> select HAVE_ALIGNED_STRUCT_PAGE
> select HAVE_ARCH_AUDITSYSCALL
> + select HAVE_ARCH_BITREVERSE if RISCV_ISA_ZBKB
> select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
> select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT
> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
> diff --git a/arch/riscv/include/asm/bitrev.h b/arch/riscv/include/asm/bitrev.h
> new file mode 100644
> index 000000000000..9f205ac84796
> --- /dev/null
> +++ b/arch/riscv/include/asm/bitrev.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __ASM_BITREV_H
> +#define __ASM_BITREV_H
> +
> +#include <linux/types.h>
> +#include <asm/cpufeature-macros.h>
> +#include <asm/hwcap.h>
> +#include <asm-generic/bitops/__bitrev.h>
> +
> +static __always_inline __attribute_const__ u32 __arch_bitrev32(u32 x)
> +{
> + unsigned long result = x;
> +
> + if (!riscv_has_extension_likely(RISCV_ISA_EXT_ZBKB))
> + return generic___bitrev32(x);
This breaks the build when CONFIG_HAVE_ARCH_BITREVERSE is set because
generic___bitrev32() ultimately calls generic___bitrev8(), which uses
byte_rev_table but that is only included in lib/bitrev.c when
CONFIG_HAVE_ARCH_BITREVERSE is not set. How was this tested? This seems
a pretty basic build problem that has showed up in a variety of
configurations (at least all the configurations that our CI tests).
$ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- mrproper defconfig all
ERROR: modpost: "byte_rev_table" [lib/zlib_deflate/zlib_deflate.ko] undefined!
ERROR: modpost: "byte_rev_table" [drivers/net/ethernet/spacemit/k1_emac.ko] undefined!
ERROR: modpost: "byte_rev_table" [drivers/net/ethernet/stmicro/stmmac/stmmac.ko] undefined!
https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/24529356842
https://lore.kernel.org/177635154368.6552.7060101263009785041@8692ffc4d55e/
Yury, are you intending to send this series to Linus in the 7.1 merge
window? If not, it shouldn't be in -next at this point.
> + asm volatile(
> + ".option push\n"
> + ".option arch,+zbkb\n"
> + "rev8 %0, %0\n"
> + "brev8 %0, %0\n"
> + ".option pop"
> + : "+r" (result)
> + );
> +
> + if (__riscv_xlen == 64)
> + return (u32)(result >> 32);
> +
> + return (u32)result;
> +}
> +
> +static __always_inline __attribute_const__ u16 __arch_bitrev16(u16 x)
> +{
> + return __arch_bitrev32((u32)x) >> 16;
> +}
> +
> +static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
> +{
> + return __arch_bitrev32((u32)x) >> 24;
> +}
> +#endif
> --
> 2.34.1
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8
2026-04-16 23:14 ` Nathan Chancellor
@ 2026-04-17 0:34 ` Yury Norov
-1 siblings, 0 replies; 18+ messages in thread
From: Yury Norov @ 2026-04-17 0:34 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Jinjie Ruan, yury.norov, pjw, palmer, aou, alex, linux, arnd,
cp0613, linux-riscv, linux-kernel, linux-arch
On Thu, Apr 16, 2026 at 04:14:41PM -0700, Nathan Chancellor wrote:
> On Wed, Apr 15, 2026 at 05:38:27PM +0800, Jinjie Ruan wrote:
> > The RISC-V Bit-manipulation Extension for Cryptography (Zbkb) provides
...
> > +static __always_inline __attribute_const__ u32 __arch_bitrev32(u32 x)
> > +{
> > + unsigned long result = x;
> > +
> > + if (!riscv_has_extension_likely(RISCV_ISA_EXT_ZBKB))
> > + return generic___bitrev32(x);
Hi Nathan,
> This breaks the build when CONFIG_HAVE_ARCH_BITREVERSE is set because
> generic___bitrev32() ultimately calls generic___bitrev8(), which uses
> byte_rev_table but that is only included in lib/bitrev.c when
> CONFIG_HAVE_ARCH_BITREVERSE is not set. How was this tested? This seems
> a pretty basic build problem that has showed up in a variety of
> configurations (at least all the configurations that our CI tests).
>
> $ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- mrproper defconfig all
> ERROR: modpost: "byte_rev_table" [lib/zlib_deflate/zlib_deflate.ko] undefined!
> ERROR: modpost: "byte_rev_table" [drivers/net/ethernet/spacemit/k1_emac.ko] undefined!
> ERROR: modpost: "byte_rev_table" [drivers/net/ethernet/stmicro/stmmac/stmmac.ko] undefined!
>
> https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/24529356842
> https://lore.kernel.org/177635154368.6552.7060101263009785041@8692ffc4d55e/
> Yury, are you intending to send this series to Linus in the 7.1 merge
> window?
No, I'm already done with this merge window. This is the material for
the next one, if ever.
Just as said, I added this one for testing. I am so far have no feedback
from robots. But your report is enough to drop it.
> If not, it shouldn't be in -next at this point.
What for do we need -next, if not for early testing?
Thanks,
Yury
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8
@ 2026-04-17 0:34 ` Yury Norov
0 siblings, 0 replies; 18+ messages in thread
From: Yury Norov @ 2026-04-17 0:34 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Jinjie Ruan, yury.norov, pjw, palmer, aou, alex, linux, arnd,
cp0613, linux-riscv, linux-kernel, linux-arch
On Thu, Apr 16, 2026 at 04:14:41PM -0700, Nathan Chancellor wrote:
> On Wed, Apr 15, 2026 at 05:38:27PM +0800, Jinjie Ruan wrote:
> > The RISC-V Bit-manipulation Extension for Cryptography (Zbkb) provides
...
> > +static __always_inline __attribute_const__ u32 __arch_bitrev32(u32 x)
> > +{
> > + unsigned long result = x;
> > +
> > + if (!riscv_has_extension_likely(RISCV_ISA_EXT_ZBKB))
> > + return generic___bitrev32(x);
Hi Nathan,
> This breaks the build when CONFIG_HAVE_ARCH_BITREVERSE is set because
> generic___bitrev32() ultimately calls generic___bitrev8(), which uses
> byte_rev_table but that is only included in lib/bitrev.c when
> CONFIG_HAVE_ARCH_BITREVERSE is not set. How was this tested? This seems
> a pretty basic build problem that has showed up in a variety of
> configurations (at least all the configurations that our CI tests).
>
> $ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- mrproper defconfig all
> ERROR: modpost: "byte_rev_table" [lib/zlib_deflate/zlib_deflate.ko] undefined!
> ERROR: modpost: "byte_rev_table" [drivers/net/ethernet/spacemit/k1_emac.ko] undefined!
> ERROR: modpost: "byte_rev_table" [drivers/net/ethernet/stmicro/stmmac/stmmac.ko] undefined!
>
> https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/24529356842
> https://lore.kernel.org/177635154368.6552.7060101263009785041@8692ffc4d55e/
> Yury, are you intending to send this series to Linus in the 7.1 merge
> window?
No, I'm already done with this merge window. This is the material for
the next one, if ever.
Just as said, I added this one for testing. I am so far have no feedback
from robots. But your report is enough to drop it.
> If not, it shouldn't be in -next at this point.
What for do we need -next, if not for early testing?
Thanks,
Yury
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8
2026-04-17 0:34 ` Yury Norov
@ 2026-04-17 3:29 ` Nathan Chancellor
-1 siblings, 0 replies; 18+ messages in thread
From: Nathan Chancellor @ 2026-04-17 3:29 UTC (permalink / raw)
To: Yury Norov
Cc: Jinjie Ruan, yury.norov, pjw, palmer, aou, alex, linux, arnd,
cp0613, linux-riscv, linux-kernel, linux-arch
On Thu, Apr 16, 2026 at 08:34:28PM -0400, Yury Norov wrote:
> On Thu, Apr 16, 2026 at 04:14:41PM -0700, Nathan Chancellor wrote:
> > Yury, are you intending to send this series to Linus in the 7.1 merge
> > window?
>
> No, I'm already done with this merge window. This is the material for
> the next one, if ever.
>
> Just as said, I added this one for testing. I am so far have no feedback
> from robots. But your report is enough to drop it.
The lore.kernel.org link came from KernelCI but it does not look like
they do bisecting to identify the commit and notify the authors. It was
just sent to the linux-next mailing list.
> > If not, it shouldn't be in -next at this point.
>
> What for do we need -next, if not for early testing?
It is just for the two weeks of the merge window to ensure the tree
actually stabilizes. This is how it has always been.
https://lore.kernel.org/linux-next/aeDrt2FkMD6ZWaVS@sirena.org.uk/
https://lore.kernel.org/linux-next/ad9r3jEtJJNv0IiA@sirena.org.uk/
I think Mark meant to say 7.2 but still. Not trying to sound like a cop
or anything but the more problems there are in the tree, the harder it
is to triage new failures and perform additional testing.
Cheers,
Nathan
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8
@ 2026-04-17 3:29 ` Nathan Chancellor
0 siblings, 0 replies; 18+ messages in thread
From: Nathan Chancellor @ 2026-04-17 3:29 UTC (permalink / raw)
To: Yury Norov
Cc: Jinjie Ruan, yury.norov, pjw, palmer, aou, alex, linux, arnd,
cp0613, linux-riscv, linux-kernel, linux-arch
On Thu, Apr 16, 2026 at 08:34:28PM -0400, Yury Norov wrote:
> On Thu, Apr 16, 2026 at 04:14:41PM -0700, Nathan Chancellor wrote:
> > Yury, are you intending to send this series to Linus in the 7.1 merge
> > window?
>
> No, I'm already done with this merge window. This is the material for
> the next one, if ever.
>
> Just as said, I added this one for testing. I am so far have no feedback
> from robots. But your report is enough to drop it.
The lore.kernel.org link came from KernelCI but it does not look like
they do bisecting to identify the commit and notify the authors. It was
just sent to the linux-next mailing list.
> > If not, it shouldn't be in -next at this point.
>
> What for do we need -next, if not for early testing?
It is just for the two weeks of the merge window to ensure the tree
actually stabilizes. This is how it has always been.
https://lore.kernel.org/linux-next/aeDrt2FkMD6ZWaVS@sirena.org.uk/
https://lore.kernel.org/linux-next/ad9r3jEtJJNv0IiA@sirena.org.uk/
I think Mark meant to say 7.2 but still. Not trying to sound like a cop
or anything but the more problems there are in the tree, the harder it
is to triage new failures and perform additional testing.
Cheers,
Nathan
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8
2026-04-17 3:29 ` Nathan Chancellor
@ 2026-04-17 19:27 ` Yury Norov
-1 siblings, 0 replies; 18+ messages in thread
From: Yury Norov @ 2026-04-17 19:27 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Jinjie Ruan, yury.norov, pjw, palmer, aou, alex, linux, arnd,
cp0613, linux-riscv, linux-kernel, linux-arch
On Thu, Apr 16, 2026 at 08:29:17PM -0700, Nathan Chancellor wrote:
> On Thu, Apr 16, 2026 at 08:34:28PM -0400, Yury Norov wrote:
> > On Thu, Apr 16, 2026 at 04:14:41PM -0700, Nathan Chancellor wrote:
> > > Yury, are you intending to send this series to Linus in the 7.1 merge
> > > window?
> >
> > No, I'm already done with this merge window. This is the material for
> > the next one, if ever.
> >
> > Just as said, I added this one for testing. I am so far have no feedback
> > from robots. But your report is enough to drop it.
>
> The lore.kernel.org link came from KernelCI but it does not look like
> they do bisecting to identify the commit and notify the authors. It was
> just sent to the linux-next mailing list.
>
> > > If not, it shouldn't be in -next at this point.
> >
> > What for do we need -next, if not for early testing?
>
> It is just for the two weeks of the merge window to ensure the tree
> actually stabilizes. This is how it has always been.
>
> https://lore.kernel.org/linux-next/aeDrt2FkMD6ZWaVS@sirena.org.uk/
> https://lore.kernel.org/linux-next/ad9r3jEtJJNv0IiA@sirena.org.uk/
>
> I think Mark meant to say 7.2 but still. Not trying to sound like a cop
> or anything but the more problems there are in the tree, the harder it
> is to triage new failures and perform additional testing.
OK, roger. The material is removed already.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8
@ 2026-04-17 19:27 ` Yury Norov
0 siblings, 0 replies; 18+ messages in thread
From: Yury Norov @ 2026-04-17 19:27 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Jinjie Ruan, yury.norov, pjw, palmer, aou, alex, linux, arnd,
cp0613, linux-riscv, linux-kernel, linux-arch
On Thu, Apr 16, 2026 at 08:29:17PM -0700, Nathan Chancellor wrote:
> On Thu, Apr 16, 2026 at 08:34:28PM -0400, Yury Norov wrote:
> > On Thu, Apr 16, 2026 at 04:14:41PM -0700, Nathan Chancellor wrote:
> > > Yury, are you intending to send this series to Linus in the 7.1 merge
> > > window?
> >
> > No, I'm already done with this merge window. This is the material for
> > the next one, if ever.
> >
> > Just as said, I added this one for testing. I am so far have no feedback
> > from robots. But your report is enough to drop it.
>
> The lore.kernel.org link came from KernelCI but it does not look like
> they do bisecting to identify the commit and notify the authors. It was
> just sent to the linux-next mailing list.
>
> > > If not, it shouldn't be in -next at this point.
> >
> > What for do we need -next, if not for early testing?
>
> It is just for the two weeks of the merge window to ensure the tree
> actually stabilizes. This is how it has always been.
>
> https://lore.kernel.org/linux-next/aeDrt2FkMD6ZWaVS@sirena.org.uk/
> https://lore.kernel.org/linux-next/ad9r3jEtJJNv0IiA@sirena.org.uk/
>
> I think Mark meant to say 7.2 but still. Not trying to sound like a cop
> or anything but the more problems there are in the tree, the harder it
> is to triage new failures and perform additional testing.
OK, roger. The material is removed already.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 18+ messages in thread