Add description for the Supm extension. Supm indicates support for pointer
masking in user mode. Supm is mandatory for RVA23S64.
The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
state") of riscv-j-extension.
Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
this dependency.
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: New patch.
---
Documentation/devicetree/bindings/riscv/extensions.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 1066b7e65dab89704dbac449db4aa5605c95b9d3..4997f533b2c0defad88fd59413a6885b5b9e109a 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -267,6 +267,12 @@ properties:
ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
("Updated to ratified state.")
+ - const: supm
+ description: |
+ The standard Supm extension for pointer masking support in user
+ mode as ratified at commit d70011dde6c2 ("Update to ratified state")
+ of riscv-j-extension.
+
- const: svade
description: |
The standard Svade supervisor-level extension for SW-managed PTE A/D
@@ -892,6 +898,16 @@ properties:
const: shvstvecd
- contains:
const: ssstateen
+ # Supm depends on either Smnpm or Ssnpm
+ - if:
+ contains:
+ const: supm
+ then:
+ anyOf:
+ - contains:
+ const: smnpm
+ - contains:
+ const: ssnpm
# Zcb depends on Zca
- if:
contains:
--
2.43.0On 12/22/25 7:04 AM, Guodong Xu wrote:
> Add description for the Supm extension. Supm indicates support for pointer
> masking in user mode. Supm is mandatory for RVA23S64.
>
> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> state") of riscv-j-extension.
>
> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> this dependency.
I have the same general question on this, about whether it's really
necessary for the DT binding to enforce these requirements. The
RISC-V specifications are what truly defines their meaning, so I
don't really see why the DT framework should need to enforce them.
(That said, I'm sure there are other cases where DT enforces things
it shouldn't have to.)
And now, having looked at these added binding definitions (in patches
07 through 11 in this series), I wonder what exactly is required for
them to be accepted. For the most part these seem to just be defining
how the extensions specified for RISC-V are to be expressed in
DT files. It seems to be a fairly straightforward copy from the
ratified specification(s) to the YAML format.
Who need to sign off on it? Conor? Paul? DT maintainers?
Thanks.
-Alex
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2: New patch.
> ---
> Documentation/devicetree/bindings/riscv/extensions.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index 1066b7e65dab89704dbac449db4aa5605c95b9d3..4997f533b2c0defad88fd59413a6885b5b9e109a 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -267,6 +267,12 @@ properties:
> ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
> ("Updated to ratified state.")
>
> + - const: supm
> + description: |
> + The standard Supm extension for pointer masking support in user
> + mode as ratified at commit d70011dde6c2 ("Update to ratified state")
> + of riscv-j-extension.
> +
> - const: svade
> description: |
> The standard Svade supervisor-level extension for SW-managed PTE A/D
> @@ -892,6 +898,16 @@ properties:
> const: shvstvecd
> - contains:
> const: ssstateen
> + # Supm depends on either Smnpm or Ssnpm
> + - if:
> + contains:
> + const: supm
> + then:
> + anyOf:
> + - contains:
> + const: smnpm
> + - contains:
> + const: ssnpm
> # Zcb depends on Zca
> - if:
> contains:
>
On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
> On 12/22/25 7:04 AM, Guodong Xu wrote:
> > Add description for the Supm extension. Supm indicates support for pointer
> > masking in user mode. Supm is mandatory for RVA23S64.
> >
> > The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> > state") of riscv-j-extension.
> >
> > Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> > this dependency.
>
> I have the same general question on this, about whether it's really
> necessary for the DT binding to enforce these requirements. The
> RISC-V specifications are what truly defines their meaning, so I
> don't really see why the DT framework should need to enforce them.
> (That said, I'm sure there are other cases where DT enforces things
> it shouldn't have to.)
Does the specification have some way to check it? What happens if a DT
is wrong? Are you going to require a DT update to make things right? Or
the kernel has to work-around the error? Neither is great. So having
this as a schema makes sense to prevent either scenario.
>
> And now, having looked at these added binding definitions (in patches
> 07 through 11 in this series), I wonder what exactly is required for
> them to be accepted. For the most part these seem to just be defining
> how the extensions specified for RISC-V are to be expressed in
> DT files. It seems to be a fairly straightforward copy from the
> ratified specification(s) to the YAML format.
>
> Who need to sign off on it? Conor? Paul? DT maintainers?
I generally leave this extension mess to Conor.
Rob
On Mon, Dec 29, 2025 at 08:13:06PM -0600, Rob Herring wrote:
> On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
> > On 12/22/25 7:04 AM, Guodong Xu wrote:
> > > Add description for the Supm extension. Supm indicates support for pointer
> > > masking in user mode. Supm is mandatory for RVA23S64.
> > >
> > > The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> > > state") of riscv-j-extension.
> > >
> > > Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> > > this dependency.
> >
> > I have the same general question on this, about whether it's really
> > necessary for the DT binding to enforce these requirements. The
> > RISC-V specifications are what truly defines their meaning, so I
> > don't really see why the DT framework should need to enforce them.
> > (That said, I'm sure there are other cases where DT enforces things
> > it shouldn't have to.)
>
> Does the specification have some way to check it? What happens if a DT
> is wrong? Are you going to require a DT update to make things right? Or
> the kernel has to work-around the error? Neither is great. So having
> this as a schema makes sense to prevent either scenario.
The reason this whole mess exists is because extensions got redefined
after the kernel port was merged and the bindings defined. This is
almost all a hedge against there being future redefinitions. For now,
and hopefully forever, this will just be a list of extensions with
citations to their relevant documentation so that we can say "this is
exactly what this means". The added bonus is avoiding messes like people
implementing development versions of specs and claiming support, because
that just becomes "your devicetree is wrong".
The dependency stuff exists because it is far too easy to miss something
in a list of 30+ extensions and dt validation can reduce some of the
complexity required when checking what extensions are supported.
> > And now, having looked at these added binding definitions (in patches
> > 07 through 11 in this series), I wonder what exactly is required for
> > them to be accepted. For the most part these seem to just be defining
> > how the extensions specified for RISC-V are to be expressed in
> > DT files. It seems to be a fairly straightforward copy from the
> > ratified specification(s) to the YAML format.
> >
> > Who need to sign off on it? Conor? Paul? DT maintainers?
>
> I generally leave this extension mess to Conor.
And generally I do without that much back and forth, just so happens
that a couple of the ones in this series are the less simple cases to
deal with.
On 12/30/25 11:22 AM, Conor Dooley wrote:
> On Mon, Dec 29, 2025 at 08:13:06PM -0600, Rob Herring wrote:
>> On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
>>> On 12/22/25 7:04 AM, Guodong Xu wrote:
>>>> Add description for the Supm extension. Supm indicates support for pointer
>>>> masking in user mode. Supm is mandatory for RVA23S64.
>>>>
>>>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
>>>> state") of riscv-j-extension.
>>>>
>>>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
>>>> this dependency.
>>>
>>> I have the same general question on this, about whether it's really
>>> necessary for the DT binding to enforce these requirements. The
>>> RISC-V specifications are what truly defines their meaning, so I
>>> don't really see why the DT framework should need to enforce them.
>>> (That said, I'm sure there are other cases where DT enforces things
>>> it shouldn't have to.)
>>
>> Does the specification have some way to check it? What happens if a DT
>> is wrong? Are you going to require a DT update to make things right? Or
>> the kernel has to work-around the error? Neither is great. So having
>> this as a schema makes sense to prevent either scenario.
>
> The reason this whole mess exists is because extensions got redefined
> after the kernel port was merged and the bindings defined. This is
Redefined, or just new extensions defined?
Was support for any extensions added to the kernel before they were
ratified? Even if so, did the meaning of the extension change
between when support was added to the kernel and ratification?
> almost all a hedge against there being future redefinitions. For now,
> and hopefully forever, this will just be a list of extensions with
> citations to their relevant documentation so that we can say "this is
Yes, this is good. I think the bindings should, where possible,
just refer to the precise definitions in the (ratified) RISC-V
specifications. But I now agree that they can also encode
logic to enforce things.
> exactly what this means". The added bonus is avoiding messes like people
> implementing development versions of specs and claiming support, because
> that just becomes "your devicetree is wrong".
>
> The dependency stuff exists because it is far too easy to miss something
> in a list of 30+ extensions and dt validation can reduce some of the
> complexity required when checking what extensions are supported.
By "dependency stuff" do you just mean the DT binding logic?
Anyway I've come around to the idea that DT bindings actually
should do validation like this.
>>> And now, having looked at these added binding definitions (in patches
>>> 07 through 11 in this series), I wonder what exactly is required for
>>> them to be accepted. For the most part these seem to just be defining
>>> how the extensions specified for RISC-V are to be expressed in
>>> DT files. It seems to be a fairly straightforward copy from the
>>> ratified specification(s) to the YAML format.
>>>
>>> Who need to sign off on it? Conor? Paul? DT maintainers?
>>
>> I generally leave this extension mess to Conor.
>
> And generally I do without that much back and forth, just so happens
> that a couple of the ones in this series are the less simple cases to
> deal with.
Thanks. I may have a remaining question or two for you but they aren't
that pressing.
-Alex
On 12/29/25 8:13 PM, Rob Herring wrote:
> On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
>> On 12/22/25 7:04 AM, Guodong Xu wrote:
>>> Add description for the Supm extension. Supm indicates support for pointer
>>> masking in user mode. Supm is mandatory for RVA23S64.
>>>
>>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
>>> state") of riscv-j-extension.
>>>
>>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
>>> this dependency.
>>
>> I have the same general question on this, about whether it's really
>> necessary for the DT binding to enforce these requirements. The
>> RISC-V specifications are what truly defines their meaning, so I
>> don't really see why the DT framework should need to enforce them.
>> (That said, I'm sure there are other cases where DT enforces things
>> it shouldn't have to.)
>
> Does the specification have some way to check it? What happens if a DT
> is wrong? Are you going to require a DT update to make things right? Or
> the kernel has to work-around the error? Neither is great. So having
> this as a schema makes sense to prevent either scenario.
I'm really glad you weighed in. I actually have several questions
related to RISC-V extensions and DT. But for now I'll focus on
just this...
To answer your first question, I'm not sure how the specification
is "checked", or what "it" is that you're asking about for that
matter. Also I think we have to be clear about what "wrong" means.
RISC-V is defined by a (large and growing) set of specifications
that are developed through a well-defined process. When a spec
is *ratified* it is committed, and it won't be changed. These
specifications are ultimately *the* definition of RISC-V
compliance.
I assumed the "wrong" you're talking about is a DTS/DTB that has
been committed but somehow does not match what a RISC-V spec
says, but I might be mistaken.
Anyway, we can flip that around and have a similar problem: What
if we define the DT binding in such a way that it doesn't match
the RISC-V spec? The (ratified) RISC-V spec is right.
My thought was that we should have software do the verification,
and recommend the software (e.g. arch/riscv/kernel/cpufeature.c
in Linux) be updated to verify things before committing to a
DT binding.
To me, C code is more general and more universally understandable
than YAML rules, but I'm biased by how well I work with C versus
YAML schemas.
In any case, a "wrong" binding is a problem no matter what the
reason. One way or another there are things expressed via DT
that must match the RISC-V specifications. And yes, we do have
tools and bindings that can verify things related to DT.
>> And now, having looked at these added binding definitions (in patches
>> 07 through 11 in this series), I wonder what exactly is required for
>> them to be accepted. For the most part these seem to just be defining
>> how the extensions specified for RISC-V are to be expressed in
>> DT files. It seems to be a fairly straightforward copy from the
>> ratified specification(s) to the YAML format.
>>
>> Who need to sign off on it? Conor? Paul? DT maintainers?
>
> I generally leave this extension mess to Conor.
Sounds wise. Should I address my other few questions on this
topic to Conor? I don't want this particular series to get
held up on unrelated discussions.
-Alex
> Rob
On Mon, Dec 29, 2025 at 9:14 PM Alex Elder <elder@riscstar.com> wrote:
>
> On 12/29/25 8:13 PM, Rob Herring wrote:
> > On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
> >> On 12/22/25 7:04 AM, Guodong Xu wrote:
> >>> Add description for the Supm extension. Supm indicates support for pointer
> >>> masking in user mode. Supm is mandatory for RVA23S64.
> >>>
> >>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> >>> state") of riscv-j-extension.
> >>>
> >>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> >>> this dependency.
> >>
> >> I have the same general question on this, about whether it's really
> >> necessary for the DT binding to enforce these requirements. The
> >> RISC-V specifications are what truly defines their meaning, so I
> >> don't really see why the DT framework should need to enforce them.
> >> (That said, I'm sure there are other cases where DT enforces things
> >> it shouldn't have to.)
> >
> > Does the specification have some way to check it? What happens if a DT
> > is wrong? Are you going to require a DT update to make things right? Or
> > the kernel has to work-around the error? Neither is great. So having
> > this as a schema makes sense to prevent either scenario.
>
> I'm really glad you weighed in. I actually have several questions
> related to RISC-V extensions and DT. But for now I'll focus on
> just this...
>
> To answer your first question, I'm not sure how the specification
> is "checked", or what "it" is that you're asking about for that
> matter. Also I think we have to be clear about what "wrong" means.
>
> RISC-V is defined by a (large and growing) set of specifications
> that are developed through a well-defined process. When a spec
> is *ratified* it is committed, and it won't be changed. These
> specifications are ultimately *the* definition of RISC-V
> compliance.
>
> I assumed the "wrong" you're talking about is a DTS/DTB that has
> been committed but somehow does not match what a RISC-V spec
> says, but I might be mistaken.
That's correct.
> Anyway, we can flip that around and have a similar problem: What
> if we define the DT binding in such a way that it doesn't match
> the RISC-V spec? The (ratified) RISC-V spec is right.
Sure. Any time there is more than 1 source of truth, they could be
mismatched. But it is 1 spec and 1 schema to compare, not N DTS files.
Checking the schema matches the spec is much easier than reviewing
every new DTS file.
The only true fix is to make the spec machine readable.
> My thought was that we should have software do the verification,
> and recommend the software (e.g. arch/riscv/kernel/cpufeature.c
> in Linux) be updated to verify things before committing to a
> DT binding.
That moves validation from build time to run time. How is that better?
And what about other OSs?
I'm very much of the opinion that it is not the kernel's job to
validate the DT. It obviously has not done a very good job given
issues we find with schemas. It's fine to have some checks in this
case if the kernel can't function (or use/enable the extension)
without the dependent extensions, but there are lots of classes of
errors the kernel doesn't need to care about.
> To me, C code is more general and more universally understandable
> than YAML rules, but I'm biased by how well I work with C versus
> YAML schemas.
Personally, if I was going to do validation with code, I would pick
python or any language that can handle lists and dicts natively. I too
would prefer C for everything, but it's not the best tool for the job
here. Even if we decided to do validation in C (I'm pretty sure we had
a proposal to do just that at some point), we'd just end up defining
our own data structures of validation data. Because at the end of the
day, most of the validation information is all the same structure of
data (i.e. a list of properties with lists of allowed values). I'd
much rather follow some standard (json-schema) that's already
documented than try to come up with my own poorly documented
invention.
I do think there is some need for code based validation as there are
some things which can't be expressed with schemas. We have some of
that in dtc, but that only works for core bindings. Some sort of
python snippets of code in schemas is kind of what I'm thinking.
> In any case, a "wrong" binding is a problem no matter what the
> reason. One way or another there are things expressed via DT
> that must match the RISC-V specifications. And yes, we do have
> tools and bindings that can verify things related to DT.
>
> >> And now, having looked at these added binding definitions (in patches
> >> 07 through 11 in this series), I wonder what exactly is required for
> >> them to be accepted. For the most part these seem to just be defining
> >> how the extensions specified for RISC-V are to be expressed in
> >> DT files. It seems to be a fairly straightforward copy from the
> >> ratified specification(s) to the YAML format.
> >>
> >> Who need to sign off on it? Conor? Paul? DT maintainers?
> >
> > I generally leave this extension mess to Conor.
>
> Sounds wise. Should I address my other few questions on this
> topic to Conor? I don't want this particular series to get
> held up on unrelated discussions.
Probably so.
Rob
On 12/30/25 9:21 AM, Rob Herring wrote:
> On Mon, Dec 29, 2025 at 9:14 PM Alex Elder <elder@riscstar.com> wrote:
>>
>> On 12/29/25 8:13 PM, Rob Herring wrote:
>>> On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
>>>> On 12/22/25 7:04 AM, Guodong Xu wrote:
>>>>> Add description for the Supm extension. Supm indicates support for pointer
>>>>> masking in user mode. Supm is mandatory for RVA23S64.
>>>>>
>>>>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
>>>>> state") of riscv-j-extension.
>>>>>
>>>>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
>>>>> this dependency.
>>>>
>>>> I have the same general question on this, about whether it's really
>>>> necessary for the DT binding to enforce these requirements. The
>>>> RISC-V specifications are what truly defines their meaning, so I
>>>> don't really see why the DT framework should need to enforce them.
>>>> (That said, I'm sure there are other cases where DT enforces things
>>>> it shouldn't have to.)
>>>
>>> Does the specification have some way to check it? What happens if a DT
>>> is wrong? Are you going to require a DT update to make things right? Or
>>> the kernel has to work-around the error? Neither is great. So having
>>> this as a schema makes sense to prevent either scenario.
>>
>> I'm really glad you weighed in. I actually have several questions
>> related to RISC-V extensions and DT. But for now I'll focus on
>> just this...
>>
>> To answer your first question, I'm not sure how the specification
>> is "checked", or what "it" is that you're asking about for that
>> matter. Also I think we have to be clear about what "wrong" means.
>>
>> RISC-V is defined by a (large and growing) set of specifications
>> that are developed through a well-defined process. When a spec
>> is *ratified* it is committed, and it won't be changed. These
>> specifications are ultimately *the* definition of RISC-V
>> compliance.
>>
>> I assumed the "wrong" you're talking about is a DTS/DTB that has
>> been committed but somehow does not match what a RISC-V spec
>> says, but I might be mistaken.
>
> That's correct.
>
>> Anyway, we can flip that around and have a similar problem: What
>> if we define the DT binding in such a way that it doesn't match
>> the RISC-V spec? The (ratified) RISC-V spec is right.
>
> Sure. Any time there is more than 1 source of truth, they could be
> mismatched. But it is 1 spec and 1 schema to compare, not N DTS files.
> Checking the schema matches the spec is much easier than reviewing
> every new DTS file.
Yes, I understand that and I agree. We *do* have tools to
verify DT files against bindings, and at least in this
domain we don't have tools to verify against the RISC-V
specs.
> The only true fix is to make the spec machine readable.
But barring that, we can define the DT binding and try to
ensure it exactly matches the RISC-V specs.
>> My thought was that we should have software do the verification,
>> and recommend the software (e.g. arch/riscv/kernel/cpufeature.c
>> in Linux) be updated to verify things before committing to a
>> DT binding.
>
> That moves validation from build time to run time. How is that better?
> And what about other OSs?
OK I concede that encoding the logic in the DT binding is
a good practical solution and I take back my suggestion.
> I'm very much of the opinion that it is not the kernel's job to
> validate the DT. It obviously has not done a very good job given
This is exactly what I wanted your opinion on. I mean, I
already agreed with this statement, but the existence of a
different (RISC-V) spec as a source of truth made me consider
that maybe it wasn't DT's job to validate some things.
> issues we find with schemas. It's fine to have some checks in this
> case if the kernel can't function (or use/enable the extension)
> without the dependent extensions, but there are lots of classes of
> errors the kernel doesn't need to care about.
>
>> To me, C code is more general and more universally understandable
>> than YAML rules, but I'm biased by how well I work with C versus
>> YAML schemas.
>
> Personally, if I was going to do validation with code, I would pick
> python or any language that can handle lists and dicts natively. I too
> would prefer C for everything, but it's not the best tool for the job
My point was about DT binding logic versus kernel code logic. But
yes I agree with what you're saying here.
> here. Even if we decided to do validation in C (I'm pretty sure we had
> a proposal to do just that at some point), we'd just end up defining
> our own data structures of validation data. Because at the end of the
> day, most of the validation information is all the same structure of
> data (i.e. a list of properties with lists of allowed values). I'd
> much rather follow some standard (json-schema) that's already
> documented than try to come up with my own poorly documented
> invention.
>
> I do think there is some need for code based validation as there are
> some things which can't be expressed with schemas. We have some of
> that in dtc, but that only works for core bindings. Some sort of
> python snippets of code in schemas is kind of what I'm thinking.
The main things I take away from this discussion:
- DT bindings *should* encode constraints for RISC-V extensions
to enforce certain requirements from their underlying RISC-V
specifications.
- The reason to do this is that the DT tools we have can help
ensure correctness. And doing it in the binding means it can
get reviewed once, and the logic will apply to all DTS files
that adhere to the binding.
- Doing some validation in the kernel is still useful, but anything
done there needs to replicated in any other code bases that need
to parse DT files.
- Conor owns this mess. :)
-Alex
>> In any case, a "wrong" binding is a problem no matter what the
>> reason. One way or another there are things expressed via DT
>> that must match the RISC-V specifications. And yes, we do have
>> tools and bindings that can verify things related to DT.
>>
>>>> And now, having looked at these added binding definitions (in patches
>>>> 07 through 11 in this series), I wonder what exactly is required for
>>>> them to be accepted. For the most part these seem to just be defining
>>>> how the extensions specified for RISC-V are to be expressed in
>>>> DT files. It seems to be a fairly straightforward copy from the
>>>> ratified specification(s) to the YAML format.
>>>>
>>>> Who need to sign off on it? Conor? Paul? DT maintainers?
>>>
>>> I generally leave this extension mess to Conor.
>>
>> Sounds wise. Should I address my other few questions on this
>> topic to Conor? I don't want this particular series to get
>> held up on unrelated discussions.
>
> Probably so.
>
> Rob
On Tue, Dec 30, 2025 at 09:21:56AM -0600, Rob Herring wrote:
> On Mon, Dec 29, 2025 at 9:14 PM Alex Elder <elder@riscstar.com> wrote:
> >
> > On 12/29/25 8:13 PM, Rob Herring wrote:
> > > On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
> > >> On 12/22/25 7:04 AM, Guodong Xu wrote:
> > >>> Add description for the Supm extension. Supm indicates support for pointer
> > >>> masking in user mode. Supm is mandatory for RVA23S64.
> > >>>
> > >>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> > >>> state") of riscv-j-extension.
> > >>>
> > >>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> > >>> this dependency.
> > >>
> > >> I have the same general question on this, about whether it's really
> > >> necessary for the DT binding to enforce these requirements. The
> > >> RISC-V specifications are what truly defines their meaning, so I
> > >> don't really see why the DT framework should need to enforce them.
> > >> (That said, I'm sure there are other cases where DT enforces things
> > >> it shouldn't have to.)
> > >
> > > Does the specification have some way to check it? What happens if a DT
> > > is wrong? Are you going to require a DT update to make things right? Or
> > > the kernel has to work-around the error? Neither is great. So having
> > > this as a schema makes sense to prevent either scenario.
> >
> > I'm really glad you weighed in. I actually have several questions
> > related to RISC-V extensions and DT. But for now I'll focus on
> > just this...
> >
> > To answer your first question, I'm not sure how the specification
> > is "checked", or what "it" is that you're asking about for that
> > matter. Also I think we have to be clear about what "wrong" means.
> >
> > RISC-V is defined by a (large and growing) set of specifications
> > that are developed through a well-defined process. When a spec
> > is *ratified* it is committed, and it won't be changed. These
> > specifications are ultimately *the* definition of RISC-V
> > compliance.
> >
> > I assumed the "wrong" you're talking about is a DTS/DTB that has
> > been committed but somehow does not match what a RISC-V spec
> > says, but I might be mistaken.
>
> That's correct.
>
> > Anyway, we can flip that around and have a similar problem: What
> > if we define the DT binding in such a way that it doesn't match
> > the RISC-V spec? The (ratified) RISC-V spec is right.
>
> Sure. Any time there is more than 1 source of truth, they could be
> mismatched. But it is 1 spec and 1 schema to compare, not N DTS files.
> Checking the schema matches the spec is much easier than reviewing
> every new DTS file.
The objective is not to define things with divergent meanings anyway,
only to say "this string is exactly this version of this extension",
so that if some other version of an extension comes along we have a way
to differentiate. We didn't before and that became problematic for both
standard extensions and vendor specific stuff. You'll note we don't look
to define anything ourselves, just cite the spec that provides the
definitions.
> The only true fix is to make the spec machine readable.
>
> > My thought was that we should have software do the verification,
> > and recommend the software (e.g. arch/riscv/kernel/cpufeature.c
> > in Linux) be updated to verify things before committing to a
> > DT binding.
>
> That moves validation from build time to run time. How is that better?
> And what about other OSs?
>
> I'm very much of the opinion that it is not the kernel's job to
> validate the DT. It obviously has not done a very good job given
> issues we find with schemas. It's fine to have some checks in this
> case if the kernel can't function (or use/enable the extension)
> without the dependent extensions, but there are lots of classes of
> errors the kernel doesn't need to care about.
By and large what's in cpufeature.c is there to turn extensions off
based on kconfig choices (vector support enabled etc) or kernel design
decisions (kernel requiring both d and f extensions for fpu support). I
don't think there's anything there that doesn't assume that the
devicetree is correct. For my money, it's much simpler to describe
dependencies in a binding than add more code to the kernel that tries to
figure out dependencies at runtime.
Am 30. Dezember 2025 18:37:25 MEZ schrieb Conor Dooley <conor@kernel.org>:
>On Tue, Dec 30, 2025 at 09:21:56AM -0600, Rob Herring wrote:
>> On Mon, Dec 29, 2025 at 9:14 PM Alex Elder <elder@riscstar.com> wrote:
>> >
>> > On 12/29/25 8:13 PM, Rob Herring wrote:
>> > > On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
>> > >> On 12/22/25 7:04 AM, Guodong Xu wrote:
>> > >>> Add description for the Supm extension. Supm indicates support for pointer
>> > >>> masking in user mode. Supm is mandatory for RVA23S64.
>> > >>>
>> > >>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
>> > >>> state") of riscv-j-extension.
>> > >>>
>> > >>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
>> > >>> this dependency.
>> > >>
>> > >> I have the same general question on this, about whether it's really
>> > >> necessary for the DT binding to enforce these requirements. The
>> > >> RISC-V specifications are what truly defines their meaning, so I
>> > >> don't really see why the DT framework should need to enforce them.
>> > >> (That said, I'm sure there are other cases where DT enforces things
>> > >> it shouldn't have to.)
>> > >
>> > > Does the specification have some way to check it? What happens if a DT
>> > > is wrong? Are you going to require a DT update to make things right? Or
>> > > the kernel has to work-around the error? Neither is great. So having
>> > > this as a schema makes sense to prevent either scenario.
>> >
>> > I'm really glad you weighed in. I actually have several questions
>> > related to RISC-V extensions and DT. But for now I'll focus on
>> > just this...
>> >
>> > To answer your first question, I'm not sure how the specification
>> > is "checked", or what "it" is that you're asking about for that
>> > matter. Also I think we have to be clear about what "wrong" means.
>> >
>> > RISC-V is defined by a (large and growing) set of specifications
>> > that are developed through a well-defined process. When a spec
>> > is *ratified* it is committed, and it won't be changed. These
>> > specifications are ultimately *the* definition of RISC-V
>> > compliance.
>> >
>> > I assumed the "wrong" you're talking about is a DTS/DTB that has
>> > been committed but somehow does not match what a RISC-V spec
>> > says, but I might be mistaken.
>>
>> That's correct.
>>
>> > Anyway, we can flip that around and have a similar problem: What
>> > if we define the DT binding in such a way that it doesn't match
>> > the RISC-V spec? The (ratified) RISC-V spec is right.
>>
>> Sure. Any time there is more than 1 source of truth, they could be
>> mismatched. But it is 1 spec and 1 schema to compare, not N DTS files.
>> Checking the schema matches the spec is much easier than reviewing
>> every new DTS file.
>
>The objective is not to define things with divergent meanings anyway,
>only to say "this string is exactly this version of this extension",
>so that if some other version of an extension comes along we have a way
>to differentiate. We didn't before and that became problematic for both
>standard extensions and vendor specific stuff. You'll note we don't look
>to define anything ourselves, just cite the spec that provides the
>definitions.
>
>> The only true fix is to make the spec machine readable.
>>
>> > My thought was that we should have software do the verification,
>> > and recommend the software (e.g. arch/riscv/kernel/cpufeature.c
>> > in Linux) be updated to verify things before committing to a
>> > DT binding.
>>
>> That moves validation from build time to run time. How is that better?
>> And what about other OSs?
>>
>> I'm very much of the opinion that it is not the kernel's job to
>> validate the DT. It obviously has not done a very good job given
>> issues we find with schemas. It's fine to have some checks in this
>> case if the kernel can't function (or use/enable the extension)
>> without the dependent extensions, but there are lots of classes of
>> errors the kernel doesn't need to care about.
>
>By and large what's in cpufeature.c is there to turn extensions off
>based on kconfig choices (vector support enabled etc) or kernel design
>decisions (kernel requiring both d and f extensions for fpu support). I
Should supm be handled in the same way? Add it to the device-tree of RVA23U64 devices. If a kernel does not support pointer masking in user space, hide the extension in cpufeature.c.
Best regards
Heinrich
>don't think there's anything there that doesn't assume that the
>devicetree is correct. For my money, it's much simpler to describe
>dependencies in a binding than add more code to the kernel that tries to
>figure out dependencies at runtime.
>
On Tue, Dec 30, 2025 at 09:41:56PM +0100, Heinrich Schuchardt wrote:
> Am 30. Dezember 2025 18:37:25 MEZ schrieb Conor Dooley <conor@kernel.org>:
> >On Tue, Dec 30, 2025 at 09:21:56AM -0600, Rob Herring wrote:
> >> On Mon, Dec 29, 2025 at 9:14 PM Alex Elder <elder@riscstar.com> wrote:
> >> >
> >> > On 12/29/25 8:13 PM, Rob Herring wrote:
> >> > > On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
> >> > >> On 12/22/25 7:04 AM, Guodong Xu wrote:
> >> > >>> Add description for the Supm extension. Supm indicates support for pointer
> >> > >>> masking in user mode. Supm is mandatory for RVA23S64.
> >> > >>>
> >> > >>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> >> > >>> state") of riscv-j-extension.
> >> > >>>
> >> > >>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> >> > >>> this dependency.
> >> > >>
> >> > >> I have the same general question on this, about whether it's really
> >> > >> necessary for the DT binding to enforce these requirements. The
> >> > >> RISC-V specifications are what truly defines their meaning, so I
> >> > >> don't really see why the DT framework should need to enforce them.
> >> > >> (That said, I'm sure there are other cases where DT enforces things
> >> > >> it shouldn't have to.)
> >> > >
> >> > > Does the specification have some way to check it? What happens if a DT
> >> > > is wrong? Are you going to require a DT update to make things right? Or
> >> > > the kernel has to work-around the error? Neither is great. So having
> >> > > this as a schema makes sense to prevent either scenario.
> >> >
> >> > I'm really glad you weighed in. I actually have several questions
> >> > related to RISC-V extensions and DT. But for now I'll focus on
> >> > just this...
> >> >
> >> > To answer your first question, I'm not sure how the specification
> >> > is "checked", or what "it" is that you're asking about for that
> >> > matter. Also I think we have to be clear about what "wrong" means.
> >> >
> >> > RISC-V is defined by a (large and growing) set of specifications
> >> > that are developed through a well-defined process. When a spec
> >> > is *ratified* it is committed, and it won't be changed. These
> >> > specifications are ultimately *the* definition of RISC-V
> >> > compliance.
> >> >
> >> > I assumed the "wrong" you're talking about is a DTS/DTB that has
> >> > been committed but somehow does not match what a RISC-V spec
> >> > says, but I might be mistaken.
> >>
> >> That's correct.
> >>
> >> > Anyway, we can flip that around and have a similar problem: What
> >> > if we define the DT binding in such a way that it doesn't match
> >> > the RISC-V spec? The (ratified) RISC-V spec is right.
> >>
> >> Sure. Any time there is more than 1 source of truth, they could be
> >> mismatched. But it is 1 spec and 1 schema to compare, not N DTS files.
> >> Checking the schema matches the spec is much easier than reviewing
> >> every new DTS file.
> >
> >The objective is not to define things with divergent meanings anyway,
> >only to say "this string is exactly this version of this extension",
> >so that if some other version of an extension comes along we have a way
> >to differentiate. We didn't before and that became problematic for both
> >standard extensions and vendor specific stuff. You'll note we don't look
> >to define anything ourselves, just cite the spec that provides the
> >definitions.
> >
> >> The only true fix is to make the spec machine readable.
> >>
> >> > My thought was that we should have software do the verification,
> >> > and recommend the software (e.g. arch/riscv/kernel/cpufeature.c
> >> > in Linux) be updated to verify things before committing to a
> >> > DT binding.
> >>
> >> That moves validation from build time to run time. How is that better?
> >> And what about other OSs?
> >>
> >> I'm very much of the opinion that it is not the kernel's job to
> >> validate the DT. It obviously has not done a very good job given
> >> issues we find with schemas. It's fine to have some checks in this
> >> case if the kernel can't function (or use/enable the extension)
> >> without the dependent extensions, but there are lots of classes of
> >> errors the kernel doesn't need to care about.
> >
> >By and large what's in cpufeature.c is there to turn extensions off
> >based on kconfig choices (vector support enabled etc) or kernel design
> >decisions (kernel requiring both d and f extensions for fpu support). I
>
> Should supm be handled in the same way? Add it to the device-tree of
> RVA23U64 devices. If a kernel does not support pointer masking in user
> space, hide the extension in cpufeature.c.
Perhaps.
Samuel opted not to add supm to dt when he introduced the other relevant
extensions, so the rationale from him would be helpful but I'd like to
get more opinions on how to deal with supm specifically. supm doesn't
really describe hardware capability, since the privilege specific
instructions are what does that, which makes me question if it should be
in dt at all. On the other hand, it could be argued that supm describes
a combination of hardware capability at the dt consumer's privilege level
and is valid on that basis. Some wording like Zkr will probably be needed,
specifically mentioning that having supm in the dt means that corresponding
version sxnpm for the privilege level that the devicetree is provided to
is supported.
Either way, we are going to need something in cpufeature.c to imply
supm so that it appears to userspace if the privilege specific extension
is detected and supm is enabled in the kernel. The kernel already does
the implication internally it just isn't reported as an extension to
userspace IIRC.
If we permit supm in dt, we're also going to have to turn supm off if
the Kconfig option is disabled, but that's relatively little effort
since it mostly (or maybe entirely) reuses code from implying supm.
Hi all, (Also replied to the v1 thread: https://lore.kernel.org/linux-riscv/9504b2f6-12f5-46c2-ac74-826dba3fb530@sifive.com/) On 2025-12-31 6:08 PM, Conor Dooley wrote: >> Should supm be handled in the same way? Add it to the device-tree of >> RVA23U64 devices. If a kernel does not support pointer masking in user >> space, hide the extension in cpufeature.c. > > Perhaps. > Samuel opted not to add supm to dt when he introduced the other relevant > extensions, so the rationale from him would be helpful but I'd like to > get more opinions on how to deal with supm specifically. supm doesn't > really describe hardware capability, since the privilege specific > instructions are what does that, which makes me question if it should be > in dt at all. On the other hand, it could be argued that supm describes > a combination of hardware capability at the dt consumer's privilege level > and is valid on that basis. Some wording like Zkr will probably be needed, > specifically mentioning that having supm in the dt means that corresponding > version sxnpm for the privilege level that the devicetree is provided to > is supported. Supm describes a combination of the hardware capability (Smnpm or Ssnpm), the consumer's privilege level (U), and the software at the next higher privilege level (M or S). If the DT is targeting U-mode, then I can see a case for adding Supm to the DT either at runtime or based on the known capabilities of the next-higher-privilege-mode software. So it could make sense to add a binding for Supm. But we still shouldn't add Supm to this particular DT, because 1) this DT is not targeting U-mode, and 2) this DT is not bound to a particular version of S-mode software. > Either way, we are going to need something in cpufeature.c to imply > supm so that it appears to userspace if the privilege specific extension > is detected and supm is enabled in the kernel. The kernel already does > the implication internally it just isn't reported as an extension to > userspace IIRC. > If we permit supm in dt, we're also going to have to turn supm off if > the Kconfig option is disabled, but that's relatively little effort > since it mostly (or maybe entirely) reuses code from implying supm. It's currently exposed to hwprobe() but not in /proc/cpuinfo. This was based on my understanding that hwprobe() was the right way to check for availability of extensions. I'm okay with adding it to /proc/cpuinfo if there's value in doing so, but I would recommend that the extension in cpufeature.c is _not_ parsed from the DT and only enabled synthetically. Regards, Samuel
On Mon, Dec 22, 2025 at 09:04:21PM +0800, Guodong Xu wrote:
> Add description for the Supm extension. Supm indicates support for pointer
> masking in user mode. Supm is mandatory for RVA23S64.
>
> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> state") of riscv-j-extension.
>
> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> this dependency.
>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2: New patch.
> ---
> Documentation/devicetree/bindings/riscv/extensions.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index 1066b7e65dab89704dbac449db4aa5605c95b9d3..4997f533b2c0defad88fd59413a6885b5b9e109a 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -267,6 +267,12 @@ properties:
> ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
> ("Updated to ratified state.")
>
> + - const: supm
> + description: |
> + The standard Supm extension for pointer masking support in user
> + mode as ratified at commit d70011dde6c2 ("Update to ratified state")
> + of riscv-j-extension.
I'm not yet convinced that this makes sense as this describes how the
consumer of the devicetree behaves not the hardware. How the hardware
behaves is already described by smnpn and ssnpm. I'd really like to
see some commentary from Samuel Holland on either this or on
https://lore.kernel.org/all/20251222-dimmer-wooing-db29fe925498@spud/
before I'd be happy with this change.
> +
> - const: svade
> description: |
> The standard Svade supervisor-level extension for SW-managed PTE A/D
> @@ -892,6 +898,16 @@ properties:
> const: shvstvecd
> - contains:
> const: ssstateen
> + # Supm depends on either Smnpm or Ssnpm
> + - if:
> + contains:
> + const: supm
> + then:
> + anyOf:
> + - contains:
> + const: smnpm
> + - contains:
> + const: ssnpm
> # Zcb depends on Zca
> - if:
> contains:
>
> --
> 2.43.0
>
© 2016 - 2026 Red Hat, Inc.