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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH1PCMb=+TvB1w+G6a2ANDp05HUwC4r6CFBDHXFwSmoP3Mm8xw@mail.gmail.com>
Date: Wed, 17 Dec 2025 15:11:55 +0800
From: Guodong Xu <guodong@...cstar.com>
To: Heinrich Schuchardt <heinrich.schuchardt@...onical.com>
Cc: Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...ive.com>, 
	Conor Dooley <conor@...nel.org>, 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 Tue, Dec 16, 2025 at 10:24 PM Heinrich Schuchardt
<heinrich.schuchardt@...onical.com> wrote:
>
> On 12/16/25 14:32, Guodong Xu wrote:
> > SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
> > Add nodes of uarts, timer and interrupt-controllers.
> >
> > Signed-off-by: Guodong Xu <guodong@...cstar.com>
> > ---
> >   arch/riscv/boot/dts/spacemit/k3.dtsi | 529 +++++++++++++++++++++++++++++++++++
> >   1 file changed, 529 insertions(+)
> >
> > diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..cb27b790716fdd6dc2bc89c28dd2588a596a5af9
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > @@ -0,0 +1,529 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (c) 2025 SpacemiT (Hangzhou) Technology Co. Ltd
> > + * Copyright (c) 2025 Guodong Xu <guodong@...cstar.com>
> > + */
> > +
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +
> > +/dts-v1/;
> > +
> > +/ {
> > +     #address-cells = <2>;
> > +     #size-cells = <2>;
> > +     model = "SpacemiT K3";
> > +     compatible = "spacemit,k3";
> > +
> > +     aliases {
> > +             serial0 = &uart0;
> > +             serial2 = &uart2;
> > +             serial3 = &uart3;
> > +             serial4 = &uart4;
> > +             serial5 = &uart5;
> > +             serial6 = &uart6;
> > +             serial7 = &uart7;
> > +             serial8 = &uart8;
> > +             serial9 = &uart9;
> > +             serial10 = &uart10;
> > +     };
> > +
> > +     cpus: cpus {
> > +             #address-cells = <1>;
> > +             #size-cells = <0>;
> > +             timebase-frequency = <24000000>;
> > +
> > +             cpu_0: cpu@0 {
> > +                     compatible = "spacemit,x100", "riscv";
> > +                     device_type = "cpu";
> > +                     reg = <0>;
> > +                     riscv,isa-base = "rv64i";
> > +                     riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "h",
> > +                                            "smaia", "smstateen", "ssaia", "sscofpmf",
> > +                                            "ssnpm", "sstc", "svade", "svinval", "svnapot",
> > +                                            "svpbmt", "zawrs", "zba", "zbb", "zbc", "zbs",
> > +                                            "zca", "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > +                                            "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > +                                            "zicntr", "zicond", "zicsr", "zifencei",
> > +                                            "zihintntl", "zihintpause", "zihpm", "zimop",
> > +                                            "zkt", "zvbb", "zvbc", "zvfbfmin", "zvfbfwma",
> > +                                            "zvfh", "zvfhmin", "zvkb", "zvkg", "zvkn",
> > +                                            "zvknc", "zvkned", "zvkng", "zvknha",
> > +                                            "zvknhb", "zvks", "zvksc", "zvksed",
> > +                                            "zvksg", "zvksh", "zvkt";
>
> This not the description of an RVA23S64 cpu. It is not even RVA23U64,
> e.g. `supm` is missing.
>
> Is the description incomplete or is the CPU not compliant?

Hi Heinrich,

The SpacemiT K3 supports the mandatory extensions defined in the RVA23
Profile (ratified Oct 2024). The list appears incomplete here only because
I am restricting the entries to those currently supported by the Linux
kernel Device Tree bindings.

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

Another angle, I found there are other reasons why Linux kernel chose to
'omit' some specific extension strings. For example, here are what I noticed
so far, including the 'supm' you mentioned:

supm: There is no binding string for this yet. However, in the kernel config
(refer to arch/riscv/Kconfig), RISCV_ISA_SUPM depends on the detection of the
underlying 'smnpm' or 'ssnpm' hardware extensions. Since 'ssnpm' is
present in my list, it can be considered as supported and the kernel
will enable pointer masking support automatically.

Other examples:
ssstateen: The kernel schema currently uses the smstateen string to
cover CSR access control in all modes (H/S/VS/U/VU). I have included
'smstateen' to satisfy this, as there is no separate 'ssstateen' binding
in the extensions.yaml.

ziccif: This extension is also absent from the bindings, despite being
implied by ftrace dynamic code work. Reference:
https://lore.kernel.org/all/20250407180838.42877-12-andybnac@gmail.com/
I intend to submit a separate patch series to formally add ziccif to
extensions.yaml.

Anyway, I have limited the x100 riscv,isa-extensions list to strictly
validate against the current kernel schema while exposing all features
the kernel is currently capable of parsing.

I hope this explanation clarifies the situation. Please let me know if you
agree with this approach.

Best Regards,
Guodong Xu

>
> Best regards
>
> Heinrich
>