From: Yury Norov <ynorov@nvidia.com>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Jinjie Ruan <ruanjinjie@huawei.com>,
yury.norov@gmail.com, 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 20:34:28 -0400 [thread overview]
Message-ID: <aeF5Q2XauRKBDssy@yury> (raw)
In-Reply-To: <20260416231441.GA12905@ax162>
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
WARNING: multiple messages have this Message-ID (diff)
From: Yury Norov <ynorov@nvidia.com>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Jinjie Ruan <ruanjinjie@huawei.com>,
yury.norov@gmail.com, 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 20:34:28 -0400 [thread overview]
Message-ID: <aeF5Q2XauRKBDssy@yury> (raw)
In-Reply-To: <20260416231441.GA12905@ax162>
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
next prev parent reply other threads:[~2026-04-17 0:34 UTC|newest]
Thread overview: 18+ 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 ` Jinjie Ruan
2026-04-15 9:38 ` [PATCH v2 1/2] bitops: Define generic __bitrev8/16/32 for reuse Jinjie Ruan
2026-04-15 9:38 ` Jinjie Ruan
2026-04-15 18:30 ` Yury Norov
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 9:38 ` Jinjie Ruan
2026-04-15 11:32 ` David Laight
2026-04-15 11:32 ` David Laight
2026-04-16 23:14 ` Nathan Chancellor
2026-04-16 23:14 ` Nathan Chancellor
2026-04-17 0:34 ` Yury Norov [this message]
2026-04-17 0:34 ` Yury Norov
2026-04-17 3:29 ` Nathan Chancellor
2026-04-17 3:29 ` Nathan Chancellor
2026-04-17 19:27 ` Yury Norov
2026-04-17 19:27 ` Yury Norov
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=aeF5Q2XauRKBDssy@yury \
--to=ynorov@nvidia.com \
--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=nathan@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.