Message-ID: <20251230-outing-discourse-723547cc14da@spud>
Date: Tue, 30 Dec 2025 17:22:33 +0000
From: Conor Dooley <conor@...nel.org>
To: 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>,
	Heinrich Schuchardt <xypron.glpk@....de>,
	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

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.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists