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@riscstar.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@riscstar.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";
+ riscv,cbom-block-size = <64>;
+ riscv,cbop-block-size = <64>;
+ riscv,cboz-block-size = <64>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <256>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2_cache0>;
+ mmu-type = "riscv,sv39";
+
+ cpu0_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+
+ cpu_1: cpu@1 {
+ compatible = "spacemit,x100", "riscv";
+ device_type = "cpu";
+ reg = <1>;
+ 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";
+ riscv,cbom-block-size = <64>;
+ riscv,cbop-block-size = <64>;
+ riscv,cboz-block-size = <64>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <256>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2_cache0>;
+ mmu-type = "riscv,sv39";
+
+ cpu1_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+
+ cpu_2: cpu@2 {
+ compatible = "spacemit,x100", "riscv";
+ device_type = "cpu";
+ reg = <2>;
+ 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";
+ riscv,cbom-block-size = <64>;
+ riscv,cbop-block-size = <64>;
+ riscv,cboz-block-size = <64>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <256>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2_cache0>;
+ mmu-type = "riscv,sv39";
+
+ cpu2_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+
+ cpu_3: cpu@3 {
+ compatible = "spacemit,x100", "riscv";
+ device_type = "cpu";
+ reg = <3>;
+ 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";
+ riscv,cbom-block-size = <64>;
+ riscv,cbop-block-size = <64>;
+ riscv,cboz-block-size = <64>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <256>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2_cache0>;
+ mmu-type = "riscv,sv39";
+
+ cpu3_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+
+ cpu_4: cpu@4 {
+ compatible = "spacemit,x100", "riscv";
+ device_type = "cpu";
+ reg = <4>;
+ 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";
+ riscv,cbom-block-size = <64>;
+ riscv,cbop-block-size = <64>;
+ riscv,cboz-block-size = <64>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <256>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2_cache1>;
+ mmu-type = "riscv,sv39";
+
+ cpu4_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+
+ cpu_5: cpu@5 {
+ compatible = "spacemit,x100", "riscv";
+ device_type = "cpu";
+ reg = <5>;
+ 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";
+ riscv,cbom-block-size = <64>;
+ riscv,cbop-block-size = <64>;
+ riscv,cboz-block-size = <64>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <256>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2_cache1>;
+ mmu-type = "riscv,sv39";
+
+ cpu5_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+
+ cpu_6: cpu@6 {
+ compatible = "spacemit,x100", "riscv";
+ device_type = "cpu";
+ reg = <6>;
+ 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";
+ riscv,cbom-block-size = <64>;
+ riscv,cbop-block-size = <64>;
+ riscv,cboz-block-size = <64>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <256>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2_cache1>;
+ mmu-type = "riscv,sv39";
+
+ cpu6_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+
+ cpu_7: cpu@7 {
+ compatible = "spacemit,x100", "riscv";
+ device_type = "cpu";
+ reg = <7>;
+ 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";
+ riscv,cbom-block-size = <64>;
+ riscv,cbop-block-size = <64>;
+ riscv,cboz-block-size = <64>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <256>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2_cache1>;
+ mmu-type = "riscv,sv39";
+
+ cpu7_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+
+ l2_cache0: cache-controller-0 {
+ compatible = "cache";
+ cache-block-size = <64>;
+ cache-level = <2>;
+ cache-size = <4194304>;
+ cache-sets = <4096>;
+ cache-unified;
+ };
+
+ l2_cache1: cache-controller-1 {
+ compatible = "cache";
+ cache-block-size = <64>;
+ cache-level = <2>;
+ cache-size = <4194304>;
+ cache-sets = <4096>;
+ cache-unified;
+ };
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu_0>;
+ };
+ core1 {
+ cpu = <&cpu_1>;
+ };
+ core2 {
+ cpu = <&cpu_2>;
+ };
+ core3 {
+ cpu = <&cpu_3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu_4>;
+ };
+ core1 {
+ cpu = <&cpu_5>;
+ };
+ core2 {
+ cpu = <&cpu_6>;
+ };
+ core3 {
+ cpu = <&cpu_7>;
+ };
+ };
+ };
+ };
+
+ soc: soc {
+ compatible = "simple-bus";
+ interrupt-parent = <&saplic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ dma-noncoherent;
+ ranges;
+
+ uart0: serial@d4017000 {
+ compatible = "spacemit,k3-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <14700000>;
+ interrupts = <42 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart2: serial@d4017100 {
+ compatible = "spacemit,k3-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017100 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <14700000>;
+ interrupts = <44 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart3: serial@d4017200 {
+ compatible = "spacemit,k3-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017200 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <14700000>;
+ interrupts = <45 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart4: serial@d4017300 {
+ compatible = "spacemit,k3-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017300 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <14700000>;
+ interrupts = <46 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart5: serial@d4017400 {
+ compatible = "spacemit,k3-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017400 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <14700000>;
+ interrupts = <47 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart6: serial@d4017500 {
+ compatible = "spacemit,k3-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017500 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <14700000>;
+ interrupts = <48 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart7: serial@d4017600 {
+ compatible = "spacemit,k3-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017600 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <14700000>;
+ interrupts = <49 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart8: serial@d4017700 {
+ compatible = "spacemit,k3-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017700 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <14700000>;
+ interrupts = <50 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart9: serial@d4017800 {
+ compatible = "spacemit,k3-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017800 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <14700000>;
+ interrupts = <51 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart10: serial@d401f000 {
+ compatible = "spacemit,k3-uart", "intel,xscale-uart";
+ reg = <0x0 0xd401f000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clock-frequency = <14700000>;
+ interrupts = <281 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ simsic: interrupt-controller@e0400000 {
+ compatible = "spacemit,k3-imsics","riscv,imsics";
+ reg = <0x0 0xe0400000 0x0 0x00200000>;
+ interrupt-controller;
+ #interrupt-cells = <0>;
+ msi-controller;
+ #msi-cells = <0>;
+ interrupts-extended = <&cpu0_intc 9>, <&cpu1_intc 9>,
+ <&cpu2_intc 9>, <&cpu3_intc 9>,
+ <&cpu4_intc 9>, <&cpu5_intc 9>,
+ <&cpu6_intc 9>, <&cpu7_intc 9>;
+ riscv,num-ids = <511>;
+ riscv,num-guest-ids = <511>;
+ riscv,hart-index-bits = <4>;
+ riscv,guest-index-bits = <6>;
+ };
+
+ saplic: interrupt-controller@e0804000 {
+ compatible = "spacemit,k3-aplic", "riscv,aplic";
+ reg = <0x0 0xe0804000 0x0 0x4000>;
+ msi-parent = <&simsic>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ riscv,num-sources = <512>;
+ };
+
+ clint: timer@e081c000 {
+ compatible = "spacemit,k3-clint", "sifive,clint0";
+ reg = <0x0 0xe081c000 0x0 0x0004000>;
+ interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>,
+ <&cpu1_intc 3>, <&cpu1_intc 7>,
+ <&cpu2_intc 3>, <&cpu2_intc 7>,
+ <&cpu3_intc 3>, <&cpu3_intc 7>,
+ <&cpu4_intc 3>, <&cpu4_intc 7>,
+ <&cpu5_intc 3>, <&cpu5_intc 7>,
+ <&cpu6_intc 3>, <&cpu6_intc 7>,
+ <&cpu7_intc 3>, <&cpu7_intc 7>;
+ };
+ };
+};
--
2.43.0On 16/12/2025 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@riscstar.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@riscstar.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;
These are not properties of the soc, but the board DTS.
Best regards,
Krzysztof
On Tue, Dec 16, 2025 at 11:35 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 16/12/2025 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@riscstar.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@riscstar.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;
>
> These are not properties of the soc, but the board DTS.
Thank you Krzysztof, I will fix that in the next version.
Best regards,
Guodong Xu
>
> Best regards,
> Krzysztof
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@riscstar.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@riscstar.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?
Best regards
Heinrich
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache0>;
> + mmu-type = "riscv,sv39";
> +
> + cpu0_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_1: cpu@1 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <1>;
> + 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";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache0>;
> + mmu-type = "riscv,sv39";
> +
> + cpu1_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_2: cpu@2 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <2>;
> + 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";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache0>;
> + mmu-type = "riscv,sv39";
> +
> + cpu2_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_3: cpu@3 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <3>;
> + 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";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache0>;
> + mmu-type = "riscv,sv39";
> +
> + cpu3_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_4: cpu@4 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <4>;
> + 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";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache1>;
> + mmu-type = "riscv,sv39";
> +
> + cpu4_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_5: cpu@5 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <5>;
> + 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";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache1>;
> + mmu-type = "riscv,sv39";
> +
> + cpu5_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_6: cpu@6 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <6>;
> + 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";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache1>;
> + mmu-type = "riscv,sv39";
> +
> + cpu6_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_7: cpu@7 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <7>;
> + 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";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache1>;
> + mmu-type = "riscv,sv39";
> +
> + cpu7_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + l2_cache0: cache-controller-0 {
> + compatible = "cache";
> + cache-block-size = <64>;
> + cache-level = <2>;
> + cache-size = <4194304>;
> + cache-sets = <4096>;
> + cache-unified;
> + };
> +
> + l2_cache1: cache-controller-1 {
> + compatible = "cache";
> + cache-block-size = <64>;
> + cache-level = <2>;
> + cache-size = <4194304>;
> + cache-sets = <4096>;
> + cache-unified;
> + };
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&cpu_0>;
> + };
> + core1 {
> + cpu = <&cpu_1>;
> + };
> + core2 {
> + cpu = <&cpu_2>;
> + };
> + core3 {
> + cpu = <&cpu_3>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <&cpu_4>;
> + };
> + core1 {
> + cpu = <&cpu_5>;
> + };
> + core2 {
> + cpu = <&cpu_6>;
> + };
> + core3 {
> + cpu = <&cpu_7>;
> + };
> + };
> + };
> + };
> +
> + soc: soc {
> + compatible = "simple-bus";
> + interrupt-parent = <&saplic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + dma-noncoherent;
> + ranges;
> +
> + uart0: serial@d4017000 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <42 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + uart2: serial@d4017100 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017100 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <44 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + uart3: serial@d4017200 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017200 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <45 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + uart4: serial@d4017300 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017300 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <46 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + uart5: serial@d4017400 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017400 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <47 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + uart6: serial@d4017500 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017500 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <48 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + uart7: serial@d4017600 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017600 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <49 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + uart8: serial@d4017700 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017700 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <50 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + uart9: serial@d4017800 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017800 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <51 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + uart10: serial@d401f000 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd401f000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <281 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + simsic: interrupt-controller@e0400000 {
> + compatible = "spacemit,k3-imsics","riscv,imsics";
> + reg = <0x0 0xe0400000 0x0 0x00200000>;
> + interrupt-controller;
> + #interrupt-cells = <0>;
> + msi-controller;
> + #msi-cells = <0>;
> + interrupts-extended = <&cpu0_intc 9>, <&cpu1_intc 9>,
> + <&cpu2_intc 9>, <&cpu3_intc 9>,
> + <&cpu4_intc 9>, <&cpu5_intc 9>,
> + <&cpu6_intc 9>, <&cpu7_intc 9>;
> + riscv,num-ids = <511>;
> + riscv,num-guest-ids = <511>;
> + riscv,hart-index-bits = <4>;
> + riscv,guest-index-bits = <6>;
> + };
> +
> + saplic: interrupt-controller@e0804000 {
> + compatible = "spacemit,k3-aplic", "riscv,aplic";
> + reg = <0x0 0xe0804000 0x0 0x4000>;
> + msi-parent = <&simsic>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + riscv,num-sources = <512>;
> + };
> +
> + clint: timer@e081c000 {
> + compatible = "spacemit,k3-clint", "sifive,clint0";
> + reg = <0x0 0xe081c000 0x0 0x0004000>;
> + interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>,
> + <&cpu1_intc 3>, <&cpu1_intc 7>,
> + <&cpu2_intc 3>, <&cpu2_intc 7>,
> + <&cpu3_intc 3>, <&cpu3_intc 7>,
> + <&cpu4_intc 3>, <&cpu4_intc 7>,
> + <&cpu5_intc 3>, <&cpu5_intc 7>,
> + <&cpu6_intc 3>, <&cpu6_intc 7>,
> + <&cpu7_intc 3>, <&cpu7_intc 7>;
> + };
> + };
> +};
>
On Tue, Dec 16, 2025 at 10:24 PM Heinrich Schuchardt
<heinrich.schuchardt@canonical.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@riscstar.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@riscstar.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
>
On 12/17/25 08:11, Guodong Xu wrote:
> On Tue, Dec 16, 2025 at 10:24 PM Heinrich Schuchardt
> <heinrich.schuchardt@canonical.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@riscstar.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@riscstar.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."
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@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
>>
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.
Hi, Conor and Heinrich
On Thu, Dec 18, 2025 at 8:56 AM Conor Dooley <conor@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.
Is this approach acceptable to you? If so, I will proceed with submitting them.
Thank you very much.
Best regards,
Guodong Xu
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@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. > ... > 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 Please note B is just the abbreviation of "zba", "zbb", and "zbs", all of them have been documented in extensions.yaml. > 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 > Regards, Yao Zi
On Sat, Dec 20, 2025 at 10:48 AM Yao Zi <me@ziyao.cc> 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@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. > > > > ... > > > 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 > > Please note B is just the abbreviation of "zba", "zbb", and "zbs", all > of them have been documented in extensions.yaml. > Yes, Yao Zi. I'll include 'B' in my next version, and add the schema check. Thanks. BR, Guodong Xu > > 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 > > > > Regards, > Yao Zi
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@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.
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@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
Hi, Conor, Heinrich On Sun, Dec 21, 2025 at 8:10 AM Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 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@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? I see your point. While the Pointer Masking spec (v1.0) does distinguishes Supm (and Sspm) as extensions describing an execution environment, it also states these are intended to be used in profile specs. With RVA23 ratification, Supm is formally included as a mandatory extension in the RVA23S64 profile. If riscv,isa-extensions property is the standard way (and I believe it is) to describe a RISC-V CPU about its compliance with ratified profile, then I believe Supm should be included in the YAML binding, alongside other extensions. > > 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. Yes. Thanks for clarifying this. Even Zic64b can be add, then some kind of schema check should be implemented to avoid the potential and possible mismatch, and ensure riscv,cob*-block-size in cpus.yaml are 64 bytes. Duplication is not good. > > > > 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. I will Cc them. Thanks for your advice. > > 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. Thanks. Heinrich. Let me add Supm in my next version. BR, Guodong > > 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
Heinrich, Samuel, 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@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. 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.
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@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
On Tue, Dec 23, 2025 at 4:36 AM Conor Dooley <conor@kernel.org> wrote:
>
> Heinrich, Samuel,
>
> 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@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.
>
> 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.
Hi, Conor
As we wait for Samuel to share his opinion, maybe I can submit a patch in
(I already have it)
my next version or as in a different patchset to implement what you suggested.
- Assign RISCV_ISA_EXT_SUPM a standalone ext number in hwcap.h
- Implement a riscv_ext_supm_validate() and put it in the callback of both
ssnpm and smnpm.
- Kconfig will be kept as a top level gatekeeper, no change.
- dt-binding entry for supm will not be added.
The only reason support me to add sump into to the dt binding
(extensions.yaml) is it's now a mandatory extension required by RVA23U64.
However, as you explained, that logic seems not strong enough.
Thank you.
Best regards,
Guodong Xu
> 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.
>
On Fri, Dec 26, 2025 at 02:53:10PM +0800, Guodong Xu wrote: > As we wait for Samuel to share his opinion, maybe I can submit a patch in > (I already have it) > my next version or as in a different patchset to implement what you suggested. > - Assign RISCV_ISA_EXT_SUPM a standalone ext number in hwcap.h > - Implement a riscv_ext_supm_validate() and put it in the callback of both > ssnpm and smnpm. > - Kconfig will be kept as a top level gatekeeper, no change. > - dt-binding entry for supm will not be added. > > The only reason support me to add sump into to the dt binding > (extensions.yaml) is it's now a mandatory extension required by RVA23U64. > However, as you explained, that logic seems not strong enough. Regardless of what we end up doing in dt, I think you should write the kernel code as if we are adding it to the binding. That way you can "imply" supm from both ssnpm and smnpm (see riscv_zvkng_bundled_exts for an example) and add the validate callback that checks against the privilege level to supm itself. I don't think sxnpm should be disabled if the privilege level of the kernel is different to that of the extension (e.g. s mode kernel and smnpm) or if the kconfig option is disabled (because I think ssnpm could be providing kvm with pointer masking even when it is disabled for userspace). I think doing it the way I suggest works better for those kinds of cases but also will just happen to work for ACPI systems that have supm without the relevant sxmpm listed.
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@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. 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
© 2016 - 2026 Red Hat, Inc.