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

[Heinrich Schuchardt]

On 12/17/25 08:11, Guodong Xu wrote:
> On Tue, Dec 16, 2025 at 10:24 PM Heinrich Schuchardt
> <heinrich.schuchardt@xxxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> > > ---
> > >    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@xxxxxxxxxxxx>
> > > + */
> > > +
> > > +#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."

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.

Best regards

Heinrich

> 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@xxxxxxxxx/
> 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