This patchset proposes a currently viable and forward compatible way to expose the bitmanip/scalar crypto capability of the platform to the userspace. Currently viable refers to the property that hardware platforms can easily modify the riscv,isa field in DT to tell the kernel it has the capability. Note that QEMU has already done so in its device tree. Forward compatible refers to the property that userspace can still detect the capability of the environment by using HWCAP regardless of how the mechanism changes below kernel in the future. I do know that it has not been settled how to discover a capability, but I think kernel has to offer some API after all, and HWCAP is the preferred way among other mechanisms for now. A note here is that the draft riscv-platform spec considers DT as mandatory discovery mechanism for embedded platform For other discovery mechanism like ACPI/SMBIOS, similar code path can be added but the HWCAP interface could remain unchanged More discussion on userspace discovering can be found on my PR to openssl https://github.com/openssl/openssl/pull/18197 --- v2: * Fixed checkpatch problem found by Heiko Stuebner * rebased on riscv/for-next as that branch has merged the support of Svpbmt extension * Changed the order of logical ids in riscv_isa_ext_id to the order specified in riscv-isa-manual * added note on riscv-platform-spec v3: * rebased on master as riscv/for-next has been merged * fix commit message as suggested by Conor Dooley Hongren (Zenithal) Zheng (3): RISC-V: add Bitmanip/Scalar Crypto parsing from DT RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto RISC-V: HWCAP: parse Bitmanip/Scalar Crypto HWCAP from DT arch/riscv/include/asm/elf.h | 2 + arch/riscv/include/asm/hwcap.h | 22 +++++++- arch/riscv/include/uapi/asm/hwcap.h | 22 ++++++++ arch/riscv/kernel/cpu.c | 14 +++++ arch/riscv/kernel/cpufeature.c | 81 +++++++++++++++++++++++++---- 5 files changed, 129 insertions(+), 12 deletions(-) -- 2.35.1
