On Thu, Nov 24, 2022 at 09:58:53AM +0000, Conor Dooley wrote:

On Thu, Nov 24, 2022 at 10:30:21AM +0100, Samuel Ortiz wrote:

quoted

On Mon, Jun 13, 2022 at 02:46:35AM +0800, Hongren (Zenithal) Zheng wrote:

quoted

diff --git a/arch/riscv/include/uapi/asm/hwcap.h b/arch/riscv/include/uapi/asm/hwcap.h
index 46dc3f5ee99f..bfed3e5c338c 100644
--- a/arch/riscv/include/uapi/asm/hwcap.h
+++ b/arch/riscv/include/uapi/asm/hwcap.h

@@ -22,4 +22,26 @@
 #define COMPAT_HWCAP_ISA_D	(1 << ('D' - 'A'))
 #define COMPAT_HWCAP_ISA_C	(1 << ('C' - 'A'))
 
+/*
+ * HWCAP2 flags - for elf_hwcap2 (in kernel) and AT_HWCAP2
+ *
+ * As only 32 bits of elf_hwcap (in kernel) could be used
+ * and RISC-V has reserved 26 bits of it, other caps like
+ * bitmanip and crypto can not be placed in AT_HWCAP
+ */

Have we agreed that multi-letter ISA extensions would use hwcap to be
exposed to userspace? With so many potential extensions, we could
quickly run out of space on AT_HWCAP2 as well.

Palmer whipped up a PoC hwprobe interface (during Plumbers I think) that
Heiko is currently looking into - I think his motivation is misaligned
access performance. There's a branch but I have no idea if it even
compiles... I'm mostly waiting for whatever Heiko comes up with ;)

https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/log/?h=riscv-hwprobe-v1

This patchset seems to need a rebase anyway per your other reply, but I
guess that the new proposed interface would be preferable?

I think so, yes.
Patch #1 is definitely needed regardless of which interface we pick for
exposing the ISA strings to userspace.

Cheers,
Samuel.