Message-ID: <05B0AE03-E7B1-4DCD-88D0-DCB9053F30BA@gmx.de>
Date: Tue, 30 Dec 2025 21:41:56 +0100
From: Heinrich Schuchardt <xypron.glpk@....de>
To: Conor Dooley <conor@...nel.org>, Rob Herring <robh@...nel.org>
CC: Alex Elder <elder@...cstar.com>, Guodong Xu <guodong@...cstar.com>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 Paul Walmsley <pjw@...nel.org>, Palmer Dabbelt <palmer@...belt.com>,
 Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
 Yixun Lan <dlan@...too.org>, Daniel Lezcano <daniel.lezcano@...aro.org>,
 Thomas Gleixner <tglx@...utronix.de>,
 Samuel Holland <samuel.holland@...ive.com>, Anup Patel <anup@...infault.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Jiri Slaby <jirislaby@...nel.org>, Lubomir Rintel <lkundrak@...sk>,
 Yangyu Chen <cyy@...self.name>, Paul Walmsley <paul.walmsley@...ive.com>,
 Kevin Meng Zhang <zhangmeng.kevin@...ux.spacemit.com>,
 Andrew Jones <ajones@...tanamicro.com>, devicetree@...r.kernel.org,
 linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
 spacemit@...ts.linux.dev, linux-serial@...r.kernel.org
Subject: Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

Am 30. Dezember 2025 18:37:25 MEZ schrieb Conor Dooley <conor@...nel.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@...cstar.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.
>

Powered by blists - more mailing lists