[PATCH v3] riscv: hwprobe: fix has_fpu() to require D extension only

[PATCH v3] riscv: hwprobe: fix has_fpu() to require D extension only

[Ivy Lopez]

The kernel never supports F without D, since D depends on F. As such,
has_fpu() checking either extension with '||' is incorrect: it
reports FPU support when only F is present, which is not sufficient
for D-dependent state save/restore, and weakens
RISCV_HWPROBE_IMA_FD semantics to "F or D" instead of "F and D".

Fix has_fpu() to check D only, which is equivalent to requiring both
extensions given the dependency. sys_hwprobe.c already calls
has_fpu() and needs no changes.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221874
Suggested-by: Conor Dooley <conor.dooley@microchip.com>
Suggested-by: Andreas Schwab <schwab@suse.de>
Signed-off-by: Ivy Lopez <skunkolee@gmail.com>
---
Changes in v3:
- Drop the sys_hwprobe.c hunk entirely: it already calls has_fpu(),
  no change needed there since v1 was never merged.
- This is a new thread per maintainer request, not a reply to v1/v2.

 arch/riscv/include/asm/switch_to.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/include/asm/switch_to.h b/arch/riscv/include/asm/switch_to.h
index 0e71eb82f920..8186cda88e17 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -60,8 +60,8 @@ static inline void __switch_to_fpu(struct task_struct *prev,
 
 static __always_inline bool has_fpu(void)
 {
-	return riscv_has_extension_likely(RISCV_ISA_EXT_f) ||
-		riscv_has_extension_likely(RISCV_ISA_EXT_d);
+	/* D extension depends on F, so checking D alone is sufficient. */
+	return riscv_has_extension_likely(RISCV_ISA_EXT_d);
 }
 #else
 static __always_inline bool has_fpu(void) { return false; }
-- 
2.55.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3] riscv: hwprobe: fix has_fpu() to require D extension only

[Andreas Schwab]

On Aug 25 2026, Ivy Lopez wrote:

> The kernel never supports F without D, since D depends on F. As such,
                            D without F

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3] riscv: hwprobe: fix has_fpu() to require D extension only

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 1514 bytes --]

On Wed, Aug 26, 2026 at 07:53:05AM +0200, Andreas Schwab wrote:
> On Aug 25 2026, Ivy Lopez wrote:
> 
> > The kernel never supports F without D, since D depends on F. As such,
>                             D without F

|The kernel never supports F without D, since D depends on F. As such,
|has_fpu() checking either extension with '||' is incorrect: it
|reports FPU support when only F is present, which is not sufficient
|for D-dependent state save/restore, and weakens
|RISCV_HWPROBE_IMA_FD semantics to "F or D" instead of "F and D".

Thinking about it, this whole thing really is not right.

> The kernel never supports F without D

This is actually correct, the kernel itself doesn't support doing this.

> since D depends on F

But this is not the rationale, the rationale is simplicity of
implementation etc.

> As such,
> has_fpu() checking either extension with '||' is incorrect: it
> reports FPU support when only F is present, which is not sufficient

And this cannot happen, because the kernel will not enable F support if D
is not present, it clears the relevant flag during devicetree/acpi
parsing.

> for D-dependent state save/restore, and weakens
> RISCV_HWPROBE_IMA_FD semantics to "F or D" instead of "F and D".

The reason I would cite for changing the is matching the expectations
set elsewhere in the kernel, rather than impact on userspace or
behaviour, since F without D is not possible so there's no potential
impact here at all.

Cheers,
Conor.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv