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

[Samuel Holland]

Hi all,

Sorry, I wasn't following this thread.

On 2025-12-22 2:36 PM, Conor Dooley wrote:
> On Sun, Dec 21, 2025 at 01:10:15AM +0100, Heinrich Schuchardt 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 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

This is not correct for system emulation. Supm (pointer masking visible in the
U-mode execution environment) requires exactly (S ? Ssnpm : Smnpm), not both of
them.

>> * RVA23 capable machine models display it in the device-tree

This is also not correct for system emulation. It is impossible for QEMU to know
if pointer masking is visible to the U-mode execution environment, because QEMU
does not provide the U-mode execution environment. Software inside the VM does.

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

Software shouldn't be looking for Supm in the devicetree, because the devicetree
does not describe the properties of the U-mode execution environment.

>> 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.
> 
> Samuel seems to have some specific thoughts on how this works, given he
> didn't blindly implement ssnpm and smnpm, but has made supm be mode
> dependent and not permitted in dt, hopefully he sees this.
> 
> Personally I'm not convinced that putting supm in dt makes sense, but
> instead the kernel should imply it if the sxnpm extension matching the
> mode the kernel is operating in is present and RISCV_ISA_SUPM is set in
> Kconfig. That's effectively how it works at present, except it'd involve
> promoting RISCV_ISA_SUPM to a "real" extension instead of being a macro.
> A validate callback should easily be able to handle checking the
> mode and whether the Kconfig option is set.
> That way it would get exposed to userspace using the actual mechanisms,
> reading the devicetree itself from userspace is not a valid way of
> checking what extensions are usable after all.

We already do this for hwprobe(), so the only difference is that Supm would be
added to /proc/cpuinfo. I don't think I have a problem with this.

Regards,
Samuel