[PATCH] lib: sbi: Fix hw a/d updating defaults

[Radim Krčmář]

2026-04-02T11:24:20-05:00, Andrew Jones <andrew.jones at oss.qualcomm.com>:
> On Thu, Apr 02, 2026 at 04:56:43PM +0200, Radim Krčmář wrote:
>> 2026-04-01T17:08:45-05:00, Andrew Jones <andrew.jones at oss.qualcomm.com>:
>> > The Svade dt-binding description states that Svadu should only
>> > be enabled at boot time when only Svadu is present in the DT.
>> > Ensure that's the case. Also, when only Svadu is supported,
>> > disable FWFT.PTE_AD_HW_UPDATING, as we need both to support
>> > toggling.
>> 
>> Does Svadu without Svade mean that both menvcfg.ADUE or henvcfg.ADUE are
>> read-only 1 (the ISA is vague enough to permit this), or is it just an
>> awkward way to configure the default, so HS mode must assume that
>> henvcfg.ADUE=0 will be Svade?
>
> I couldn't find anything in the spec that explicitly states the ADUE bit
> will behave has read-only one when only Svadu is supported. If the spec
> at least claimed that the ADUE field was WARL then we might infer that,
> but it doesn't even say that.

Yeah, it was a long shot and Greg just clarified in an unrelated thread
that the values are read-write unless explicitly stated otherwise, so
Svadu implies Svade, and we're misusing the extension string to express
a default configuration parameter.

>> Svade is mandatory in RVA profiles, so the corner-case case it not
>> anything I expect to see...
>
> Yes, I expect if Svadu-only harts are built that they likely will make
> ADUE read-only 1, so I don't expect to see problems with just
> unconditionally setting the bit to 1, as we do here (and should set
> henvcfg.ADUE in KVM as well).

Right, we'd only have an issue if software assumed that Svadu without
Svade means that it doesn't have to set the bit to 1 to avoid Svade.