Re: [PATCH 7/8] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC

From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
To: Conor Dooley <conor@kernel.org>, Guodong Xu <guodong@riscstar.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	Kevin Meng Zhang <zhangmeng.kevin@linux.spacemit.com>,
	devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-kernel@vger.kernel.org, spacemit@lists.linux.dev,
	linux-serial@vger.kernel.org, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>, Yixun Lan <dlan@gentoo.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Samuel Holland <samuel.holland@sifive.com>,
	Anup Patel <anup@brainfault.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	Lubomir Rintel <lkundrak@v3.sk>, Yangyu Chen <cyy@cyyself.name>
Subject: Re: [PATCH 7/8] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC
Date: Sun, 21 Dec 2025 01:10:15 +0100	[thread overview]
Message-ID: <4e4c9e7b-d95c-4157-94c3-b06002f94a48@canonical.com> (raw)
In-Reply-To: <20251220-repacking-football-c79e660e788a@spud>

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@kernel.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?
> 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.
> 
> 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.

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.

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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv