Message-ID: <212e6371-245e-4f44-98a0-5e1db47222a1@canonical.com>
Date: Fri, 19 Dec 2025 09:08:07 +0100
From: Heinrich Schuchardt <heinrich.schuchardt@...onical.com>
To: Guodong Xu <guodong@...cstar.com>, Conor Dooley <conor@...nel.org>
Cc: 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

On 12/19/25 03:03, 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.

Adding the missing extensions to
Documentation/devicetree/bindings/riscv/extensions.yaml
is what it takes to describe the K100 cores in the device-tree.

Discovering the new extensions as CPU features and exposing them via 
hwprobe is probably best handled in a separate patch series.

Best regards

Heinrich

> 
> 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.
> 
> Is this approach acceptable to you? If so, I will proceed with submitting them.
> 
> Thank you very much.
> 
> Best regards,
> Guodong Xu

Powered by blists - more mailing lists