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

[Heinrich Schuchardt]

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 at 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