Re: [PATCH 1/6] riscv: hwprobe: Report FP extensions only when available

[Radim Krčmář]

2026-11-07T23:16:20-05:00, <guodong.xu@xxxxxxxxxxxxxxxx>:
> Hi Radim,
>
> On 2026-10-07 09:46, Radim Krčmář wrote:
>>2026-10-06T16:54:53-07:00, Charlie Jenkins <thecharlesjenkins@xxxxxxxxx>:
>>>
>>> The vector Kconfig is gated on FPU=y so the vector instructions can't
>>> ever be enabled when FPU=n.
>>
>>Right, I'll make the commit message clearer in v2.
>>(Zve32x and hence has_vector() can technically exist without CONFIG_FPU,
>> so future implementations might require use to remove the dependency.)
>>
>
> Do you mean dropping "depends on FPU" from RISCV_ISA_V? Today it reads
> arch/riscv/Kconfig:
>
>    config RISCV_ISA_V
>            bool "Vector extension support"
>            depends on TOOLCHAIN_HAS_V
>            depends on FPU
>
> Today that dependency also gates Zve32x, Zve64x, Zvbb, Zvbc and the Zvk*,
> none of these touches floating-point state, but they are all being gated
> by CONFIG_FPU, that seems not correct.
>
> I noticed that the _validate() callbacks in today's cpufeature.c for these
> non-F (non-D) related extensions are checked against V only, but that
> doesn't change the fact that CONFIG_RISCV_ISA_V depends on CONFIG_FPU
> (from a commit 3 years ago) in Kconfig.

V extension does require F (V is Zve64d and at least 128 bit vlen), but
Zve32x that we use for _validate() and has_vector() is a subset of V, so
we could have a config for RISCV_ISA_ZVE32X that RISCV_ISA_V depends on.

I think it would be cleaner to have the ifdefery use RISCV_ISA_ZVE32X,
instead of reinterpreting RISCV_ISA_V to mean the base vector extension.

At the moment, I don't know of a requirement to have Linux builds with
Vector yet without FPU, so we can postpone the code churn...
We do support those F-less vector machines even now, just with a minor
overhead of dead FPU code.
My patch is only for machines where not all harts have F.

Thanks.