From: Nathan Chancellor <nathan@kernel.org>
To: Jinjie Ruan <ruanjinjie@huawei.com>, yury.norov@gmail.com
Cc: pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
alex@ghiti.fr, linux@rasmusvillemoes.dk, arnd@arndb.de,
cp0613@linux.alibaba.com, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8
Date: Thu, 16 Apr 2026 16:14:41 -0700 [thread overview]
Message-ID: <20260416231441.GA12905@ax162> (raw)
In-Reply-To: <20260415093827.2776328-3-ruanjinjie@huawei.com>
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
next prev parent reply other threads:[~2026-04-16 23:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 9:38 [PATCH v2 0/2] arch/riscv: Add bitrev.h file to support rev8 and brev8 Jinjie Ruan
2026-04-15 9:38 ` [PATCH v2 1/2] bitops: Define generic __bitrev8/16/32 for reuse Jinjie Ruan
2026-04-15 18:30 ` Yury Norov
2026-04-15 9:38 ` [PATCH v2 2/2] arch/riscv: Add bitrev.h file to support rev8 and brev8 Jinjie Ruan
2026-04-15 11:32 ` David Laight
2026-04-16 23:14 ` Nathan Chancellor [this message]
2026-04-17 0:34 ` Yury Norov
2026-04-17 3:29 ` Nathan Chancellor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260416231441.GA12905@ax162 \
--to=nathan@kernel.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=cp0613@linux.alibaba.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux@rasmusvillemoes.dk \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox