Message-ID: <CAH1PCMZ=-ONwVuOFLPLOXvW7GfiUsFDxXX8P+mSSvhgDrWTHUA@mail.gmail.com>
Date: Mon, 22 Dec 2025 18:32:51 +0800
From: Guodong Xu <guodong@...cstar.com>
To: Heinrich Schuchardt <heinrich.schuchardt@...onical.com>
Cc: Conor Dooley <conor@...nel.org>, Paul Walmsley <paul.walmsley@...ive.com>, 
	Palmer Dabbelt <palmer@...ive.com>, Kevin Meng Zhang <zhangmeng.kevin@...ux.spacemit.com>, 
	devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, spacemit@...ts.linux.dev, 
	linux-serial@...r.kernel.org, Rob Herring <robh@...nel.org>, 
	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>
Subject: Re: [PATCH 7/8] riscv: dts: spacemit: add initial device tree of
 SpacemiT K3 SoC

Hi, Conor, Heinrich

On Sun, Dec 21, 2025 at 8:10 AM Heinrich Schuchardt
<heinrich.schuchardt@...onical.com> wrote:
>
> On 12/21/25 00:23, Conor Dooley wrote:
> > On Fri, Dec 19, 2025 at 10:03:24AM +0800, Guodong Xu wrote:
> >> Hi, Conor and Heinrich
> >>
> >> On Thu, Dec 18, 2025 at 8:56 AM Conor Dooley <conor@...nel.org> wrote:
> >>>
> >>> On Wed, Dec 17, 2025 at 09:07:14AM +0100, Heinrich Schuchardt wrote:
> >>>> On 12/17/25 08:11, Guodong Xu wrote:
> >>>
> >>>>> Specifically, I must adhere to
> >>>>> Documentation/devicetree/bindings/riscv/extensions.yaml (and cpus.yaml for
> >>>>> properties like 'riscv,sv39' which stands for the extension Sv39). If I
> >>>>> add extension strings that are not yet defined in these schemas, such as
> >>>>> supm, running 'make dtbs_check W=3' fails with: 'supm' is not one of
> >>>>> ['i', 'm', 'a', ...], followed by "Unevaluated properties are not allowed."
> >>>>
> >>>> If Documentation/devicetree/bindings/riscv/extensions.yaml is incomplete
> >>>> with respect to ratified extensions, I guess the right approach is to amend
> >>>> it and not to curtail the CPU description.
> >>>
> >>> Absolutely. If the cpu supports something that is not documented, then
> >>> please document it rather than omit from the devicetree.
> >>
> >> Thanks for the review. May I clarify one thing? Both of you mentioned
> >> document them, given the amount of missing extensions, is it acceptable if
> >> I submit a prerequisite patch that only documents these strings in
> >> riscv/extensions.yaml plus the necessary hwprobe export? Leaving the actual
> >> usage of these extensions (named features) to the future patches.
> >>
> >> To provide some context on why I ask: I've investigated the commits & lkml
> >> history of RISC-V extensions since v6.5, and I summarized the current status
> >> regarding the RVA23 profile here:
> >> [1] status in v6.18 (inc. v6.19-rc1):
> >> https://docularxu.github.io/rva23/linux-kernel-coverage.html
> >> [2] support evolution since v6.5:
> >> https://docularxu.github.io/rva23/rva23-kernel-support-evolution.html
> >>
> >> Strictly describing the SpacemiT X100/K3 (or any core) as RVA23-compliant
> >> requires adding these extensions that are currently missing from
> >> the kernel bindings:
> >> RVA23U64: Ziccif, Ziccamoa, Zicclsm, Za64rs
> >> RVA23S64: Ss1p13, Ssccptr, Sstvecd, Sstvala, Sscounterenw, Ssu64xl,
> >>            Sha, Shcounterenw, Shvstvala, Shtvala, Shvstvecd, Shvsatpa, Shgatpa
> >
> >
> >> Plus 'Supm', 'Zic64b', 'Ssstateen', 'B' where the kernel supports them but
> >> they are not literally documented in yaml.
> >
> > I don't think Supm is suitable for devicetree, doesn't it describe
> > what the kernel/userspace are capable of rather than hardware?

I see your point. While the Pointer Masking spec (v1.0) does distinguishes
Supm (and Sspm) as extensions describing an execution environment, it also
states these are intended to be used in profile specs.

With RVA23 ratification, Supm is formally included as a mandatory extension
in the RVA23S64 profile.

If riscv,isa-extensions property is the standard way (and I believe it is)
to describe a RISC-V CPU about its compliance with ratified profile, then I
believe Supm should be included in the YAML binding, alongside other
extensions.

> > Zic64b doesn't sound like hardware description (so not really suitable
> > for devicetree either) but block size information is already represented
> > by some existing properties (see riscv,cbo*-block-size in riscv/cpus.yaml)
> > and duplicating that information is not really a great idea.

Yes. Thanks for clarifying this.

Even Zic64b can be add, then some kind of schema check should be implemented
to avoid the potential and possible mismatch, and ensure
riscv,cob*-block-size in cpus.yaml are 64 bytes. Duplication is not good.

> >
> > I'll admit that I do not really understand Sxstateen and how they work,
> > but my understanding was that knowing about Smstateen is sufficient and
> > implied Sstateen, but having Ssstateen defined seems harmless and
> > possible. I think kvm is the only user of this at the moment, so
> > probably worth CCing Anup and maybe Drew Jones on the patch adding
> > Ssstateen to make sure it makes sense.

I will Cc them. Thanks for your advice.

>
> Supm is described in
>
> RISC-V Pointer Masking
> Version 1.0, 10/2024: Ratified
> https://raw.githubusercontent.com/riscv/riscv-j-extension/master/zjpm-spec.pdf
>
> The interpretation taken by QEMU has been:
>
> * Supm implies Ssnpm and Smnpm
> * RVA23 capable machine models display it in the device-tree
>
> If Supm is not shown in the device-tree, software might assume that the
> system does not support pointer masking in user mode and is not RVA23
> compliant.
>
> Hence I would suggest:
>
> If the X100 cores have Ssnpm and Smnpm, add Supm to the device-tree.

Thanks. Heinrich.
Let me add Supm in my next version.

BR,
Guodong

>
> If the kernel does not support user space pointer masking, the kernel
> should filter out Supm and not announce it, neither in /proc/cpuinfo nor
> via hwprobe.
>
> Best regards
>
> Heinrich

Powered by blists - more mailing lists