[External] Re: [PATCH v3 1/3] dt-bindings: riscv: clarify Svadu boot-time behavior

[Conor Dooley]

On Wed, Jun 10, 2026 at 10:03:01AM +0800, yunhui cui wrote:
> Hi Conor,
> 
> On Wed, Jun 10, 2026 at 12:09 AM Conor Dooley <conor at kernel.org> wrote:
> >
> > On Tue, Jun 09, 2026 at 09:00:18PM +0800, Yunhui Cui wrote:
> > > Clarify that systems which advertise only Svadu have hardware PTE A/D
> > > updating enabled at boot, while systems advertising both Svade and Svadu
> > > must enable Svadu explicitly with SBI FWFT.
> > >
> > > Signed-off-by: Yunhui Cui <cuiyunhui at bytedance.com>
> > > Reviewed-by: Qingwei Hu <qingwei.hu at bytedance.com>
> > > ---
> > >  Documentation/devicetree/bindings/riscv/extensions.yaml | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > > index 2b0a8a93bb214..b09888e9988de 100644
> > > --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> > > +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > > @@ -294,10 +294,10 @@ properties:
> > >                 of the PTE A/D bits or page faults when they need updated.
> > >              2) Only Svade present in DT => Supervisor must assume Svade to be
> > >                 always enabled.
> > > -            3) Only Svadu present in DT => Supervisor must assume Svadu to be
> > > -               always enabled.
> > > +            3) Only Svadu present in DT => Supervisor must assume Svadu is
> > > +               enabled at boot.
> >
> > Commit message is missing an explanation of why this behaviour change is
> > not problematic. Although, to be honest, I am not sure what the changed text
> > actually means. If only Svadu is present, then the hardware doesn't support
> > Svade, and therefore Svadu would never be anything other than enabled so
> > changing the wording to specify "at boot" seems less clear?
> 
> The "enabled at boot" wording came from Andrew's feedback on the previous
> version: "always" is a sensitive term here because ADUE is writable when
> Svadu is implemented, and ADUE=0 behaves as though Svade were implemented.

Whether or not it is writeable, the current wording means that it is not
allowed to be changed. I think that's reasonable because there's nothing
else supported by the hardware so changing it makes no sense.

> Would this wording work?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20260610/6fee8c93/attachment.sig>