[PATCH v8 11/11] riscv: hwprobe: Introduce rva23u64 base behavior

[Radim Krcmar]

2026-09-20T03:18:31-04:00, Guodong Xu <guodong.xu at oss.qualcomm.com>:
> Provide a hwprobe base-behavior bit so userspace can check RVA23U64
> support in one call.  Without it, a consumer needs five hwprobe
> calls and four prctl calls, which is error-prone to require of every
> caller.  Most software treats RVA23U64 as a new base anyway, so
> expose it directly.
>
> The IMA bit is now derived from the same cached bases instead of being
> hardcoded, so it agrees with AT_HWCAP and the "isa bases" cpuinfo lines;
> on any system this kernel can run on it stays set.
>
> Co-developed-by: Andrew Jones <andrew.jones at oss.qualcomm.com>
> Signed-off-by: Andrew Jones <andrew.jones at oss.qualcomm.com>
> Signed-off-by: Guodong Xu <guodong.xu at oss.qualcomm.com>
> ---
> index 8a38a4d37806f..2290126792797 100644
> +static bool hwprobe_has_isa_base(const struct cpumask *cpus, unsigned int base)
> +{
> +	int cpu;
> +
> +	for_each_cpu(cpu, cpus) {
> +		if (!riscv_isa_base_available(hart_isa[cpu].isa_bases, base))
> +			return false;

I think that extensions like F or V might be present in the ISA, yet
actually disabled in user-mode and this loop would misreport that
RVA23U64 is present.

Is there a reason to diverge from how hwprobe_isa_ext0() does the
extension detection?  (has_fpu() and other global checks)

Thanks.