Hi Heinrich, On Mon, 21 Sep 2026 16:24:53 +0200, Heinrich Schuchardt wrote: > On 9/20/26 09:18, Guodong Xu wrote: >> [ ... ] >> __RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_Q), >> __RISCV_ISA_EXT_SUPERSET(c, RISCV_ISA_EXT_C, riscv_c_exts), >> + __RISCV_ISA_EXT_SUPERSET(b, RISCV_ISA_EXT_B, riscv_b_exts), > > Hello Guodong, > > The RISC-V Unpriviledged ISA specification has this description of > extension B: > > "The B standard extension comprises instructions provided by the Zba, > Zbb, and Zbs extensions." > > __RISCV_ISA_EXT_SUPERSET would imply that something else but > riscv_b_exts is in B. But such an extra seems not to exist. > > So shouldn't __RISCV_ISA_EXT_BUNDLE be used here? Some code further > change may be needed to set extension B if riscv_b_exts is fulfilled.
Thanks for the review. Intentional, and the difference between the two macros is whether the extension gets a bit of its own. __RISCV_ISA_EXT_BUNDLE carries RISCV_ISA_EXT_INVALID as its id: parsing the name only sets the bits of its parts. That fits zk, zkn names, which are shorthands with no identity of their own beyond the ISA string. B is different: it is a single-letter standard extension with its own misa bit (in the same way as A), and AT_HWCAP on RISC-V is the bitmask of exactly those single letters, so the kernel needs a bit for B itself. A is declared the same way; with the spec defines A in the same words as B. If I can take that as a precedence. IMHO, "superset" in this table means "also sets these subset bits", not "contains something extra". Guodong
