Hi Conor,
On 21/06/2024 10:01, Conor Dooley wrote:
On Fri, Jun 21, 2024 at 09:52:01AM +0200, Alexandre Ghiti wrote:
On 05/06/2024 14:15, Yong-Xuan Wang wrote:
Svade and Svadu extensions represent two schemes for managing the PTE A/D
+/*
+ * Both Svade and Svadu control the hardware behavior when the PTE A/D bits need to be set. By
+ * default the M-mode firmware enables the hardware updating scheme when only Svadu is present in
+ * DT.
+ */
+#define arch_has_hw_pte_young arch_has_hw_pte_young
+static inline bool arch_has_hw_pte_young(void)
+{
+ return riscv_has_extension_unlikely(RISCV_ISA_EXT_SVADU) &&
+ !riscv_has_extension_likely(RISCV_ISA_EXT_SVADE);
+}
AFAIK, the riscv_has_extension_*() macros will use the content of the
riscv,isa string. So this works fine for now with the description you
provided in the cover letter, as long as we don't have the FWFT SBI
extension. I'm wondering if we should not make sure it works when FWFT lands
because I'm pretty sure we will forget about this.
So I think we should check the availability of SBI FWFT and use some global
variable that tells if svadu is enabled or not instead of this check.
No. If FWFT stuff arrives, it should be plumbed into exactly the same
interface. "Users" should not have to think about where the extension is
probed from and be able to use the same interface regardless.
The interfaces we have have already caused some confusion, we should not
make them worse.
Understood, we need to keep that in mind then.
_______________________________________________
linux-riscv mailing list
linux-riscv@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-riscv
