[PATCH v2 00/13] riscv: spacemit: Add SpacemiT K3 SoC and K3 Pico-ITX board

[PATCH v2 00/13] riscv: spacemit: Add SpacemiT K3 SoC and K3 Pico-ITX board

[Guodong Xu]

This series introduces basic support for the SpacemiT K3 SoC and the
K3 Pico-ITX evaluation board.

This series (starting from v2) also adds descriptions about ISA extensions
mandated by the RVA23 Profile Version 1.0 into riscv/extensions.yaml. These
additions are implemented in Patches 7 through 11.

The SpacemiT K3 is an SoC featuring 8 SpacemiT X100 RISC-V cores.
The X100 is a 4-issue, out-of-order core compliant with the RVA23
profile, targeting high-performance scenarios. [1]

The K3 Pico-ITX is an evaluation board built around the K3 SoC.

From an RVA23 profile compliance perspective, the X100 supports all
mandatory extensions required by RVA23U64 and RVA23S64.

This v2 series includes:
 - DT bindings for SpacemiT X100 core, K3 SoC, and Pico-ITX board.
 - DT bindings for K3 integrated peripherals: CLINT, APLIC, IMSIC, and UART.
 - Initial Device Tree for K3 SoC and Pico-ITX board.
 - Add DT bindings for mandatory extensions of RVA23.

This series has been rebased to v6.19-rc2.

Link: https://www.spacemit.com/en/spacemit-x100-core/ [1]

Patches 7 and 8 from the v1 series have been renumbered to Patches 12 and 13.

Changes in v2:
- Patch 1:
   Fixed alphanumeric sorting order of compatible strings (swapped x100 and
     x60) as per Krzysztof's feedback.
   Update commit message with more information about X100 featurs per
     Yixun's feedback.
- Patch 4:
   Fixed the order to keep things alphabetically.
- Patch 6:
   Use "one blank space" between name and email address.
- Patch 7 ~ 11:
   New patches. Add description of RVA23 mandatory extensions into riscv
    binding YAML file.
- Patch 12 (Patch 7 in v1):
   Removed aliases node.
   Updated 'riscv,isa-extensions' with new extension strings available
- Patch 13 (Patch 8 in v1):
   Updated the memory address to the hardware truth.
   Added aliases node in board dts.
- Patch 1,2,3,5: Add Reviewed-by and Acked-by collected.

Link to v1: https://lore.kernel.org/r/20251216-k3-basic-dt-v1-0-a0d256c9dc92@riscstar.com

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
Guodong Xu (13):
      dt-bindings: riscv: add SpacemiT X100 CPU compatible
      dt-bindings: timer: add SpacemiT K3 CLINT
      dt-bindings: interrupt-controller: add SpacemiT K3 APLIC
      dt-bindings: interrupt-controller: add SpacemiT K3 IMSIC
      dt-bindings: serial: 8250: add SpacemiT K3 UART compatible
      dt-bindings: riscv: spacemit: add K3 and Pico-ITX board bindings
      dt-bindings: riscv: Add B ISA extension description
      dt-bindings: riscv: Add descriptions for Za64rs, Ziccamoa, Ziccif, and Zicclsm
      dt-bindings: riscv: Add Ssccptr, Sscounterenw, Sstvala, Sstvecd, Ssu64xl
      dt-bindings: riscv: Add Sha and its comprised extensions
      dt-bindings: riscv: Add Supm extension description
      riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC
      riscv: dts: spacemit: add SpacemiT K3 Pico-ITX board device tree

 .../bindings/interrupt-controller/riscv,aplic.yaml |   1 +
 .../interrupt-controller/riscv,imsics.yaml         |   1 +
 Documentation/devicetree/bindings/riscv/cpus.yaml  |   1 +
 .../devicetree/bindings/riscv/extensions.yaml      | 180 +++++++
 .../devicetree/bindings/riscv/spacemit.yaml        |   4 +
 Documentation/devicetree/bindings/serial/8250.yaml |   1 +
 .../devicetree/bindings/timer/sifive,clint.yaml    |   1 +
 arch/riscv/boot/dts/spacemit/Makefile              |   1 +
 arch/riscv/boot/dts/spacemit/k3-pico-itx.dts       |  38 ++
 arch/riscv/boot/dts/spacemit/k3.dtsi               | 548 +++++++++++++++++++++
 10 files changed, 776 insertions(+)
---
base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
change-id: 20251216-k3-basic-dt-cd9540061989

Best regards,
-- 
Guodong Xu <guodong@riscstar.com>

[PATCH v2 01/13] dt-bindings: riscv: add SpacemiT X100 CPU compatible

[Guodong Xu]

Add compatible string for the SpacemiT X100 core. [1]

The X100 is a 64-bit RVA23-compliant RISC-V core from SpacemiT. X100
supports the RISC-V vector and hypervisor extensions and all mandatory
extersions as required by the RVA23U64 and RVA23S64 profiles, per the
definition in 'RVA23 Profile, Version 1.0'. [2]

From a microarchieture viewpoint, the X100 features a 4-issue
out-of-order pipeline.

X100 is used in SpacemiT K3 SoC.

Link: https://www.spacemit.com/en/spacemit-x100-core/ [1]
Link: https://docs.riscv.org/reference/profiles/rva23/_attachments/rva23-profile.pdf [2]
Reviewed-by: Yixun Lan <dlan@gentoo.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: Fixed alphanumeric sorting of compatible strings, put x100 before x60,
     as per Krzysztof's feedback.
    Added reviewed-by from Yixun and Heinrich.
    Updated the commit message to provide more information about X100.
---
 Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index d733c0bd534fb63ed7c0eada97c42832431f1fc1..5feeb2203050ae1f1404100ab7ba93e224f72d97 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -61,6 +61,7 @@ properties:
               - sifive,u7
               - sifive,u74
               - sifive,u74-mc
+              - spacemit,x100
               - spacemit,x60
               - thead,c906
               - thead,c908

-- 
2.43.0

[PATCH v2 02/13] dt-bindings: timer: add SpacemiT K3 CLINT

[Guodong Xu]

Add compatible string for SpacemiT K3 CLINT.

Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: Add Conor's Acked-by.
---
 Documentation/devicetree/bindings/timer/sifive,clint.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index 0d3b8dc362ba7e8d0ca6d0cea692ceddc5e1f89e..3bab40500df9bc2ba4f7d6f1bf340c8cbc06f9de 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -33,6 +33,7 @@ properties:
               - eswin,eic7700-clint     # ESWIN EIC7700
               - sifive,fu540-c000-clint # SiFive FU540
               - spacemit,k1-clint       # SpacemiT K1
+              - spacemit,k3-clint       # SpacemiT K3
               - starfive,jh7100-clint   # StarFive JH7100
               - starfive,jh7110-clint   # StarFive JH7110
               - starfive,jh8100-clint   # StarFive JH8100

-- 
2.43.0

[PATCH v2 03/13] dt-bindings: interrupt-controller: add SpacemiT K3 APLIC

[Guodong Xu]

Add compatible string for SpacemiT K3 APLIC.

Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: Add Conor's Acked-by.
---
 Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
index bef00521d5dacc002d24c50843ebe6380a7d5524..0718071444d29fbfa36283fc9666e8cecd6f77e7 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
@@ -28,6 +28,7 @@ properties:
     items:
       - enum:
           - qemu,aplic
+          - spacemit,k3-aplic
       - const: riscv,aplic
 
   reg:

-- 
2.43.0

[PATCH v2 04/13] dt-bindings: interrupt-controller: add SpacemiT K3 IMSIC

[Guodong Xu]

Add compatible string for SpacemiT K3 IMSIC.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: Fix the order to keep things alphabetically.
---
 Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
index c23b5c09fdb90baccece03708f4a381084b22049..feec122bddde1f82cbd29b8f3597d6af1a16cb23 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
@@ -48,6 +48,7 @@ properties:
     items:
       - enum:
           - qemu,imsics
+          - spacemit,k3-imsics
       - const: riscv,imsics
 
   reg:

-- 
2.43.0

[PATCH v2 05/13] dt-bindings: serial: 8250: add SpacemiT K3 UART compatible

[Guodong Xu]

The SpacemiT K3 UART controller is compatible with the Intel XScale UART.
Add K3 UART binding and allow describing it with a fixed clock-frequency
for now.

The clocks and clock-names properties will be made mandatory in a future
patch, once the K3 clock driver and device tree are merged.

Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: Add Conor's Acked-by.
---
 Documentation/devicetree/bindings/serial/8250.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index 167ddcbd880058b6dcea9ce33bd814ff8ba6b0f6..73851f19330d7f9fc254efcd32b5977feada0b07 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -160,6 +160,7 @@ properties:
           - enum:
               - mrvl,mmp-uart
               - spacemit,k1-uart
+              - spacemit,k3-uart
           - const: intel,xscale-uart
       - items:
           - enum:

-- 
2.43.0

[PATCH v2 06/13] dt-bindings: riscv: spacemit: add K3 and Pico-ITX board bindings

[Guodong Xu]

Add DT binding documentation for the SpacemiT K3 SoC and the board Pico-ITX
which is a 2.5-inch single-board computer.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: Use one-blank-space between name and email address.
---
 Documentation/devicetree/bindings/riscv/spacemit.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/riscv/spacemit.yaml b/Documentation/devicetree/bindings/riscv/spacemit.yaml
index 9c49482002f768cd0cc59be6db02659a43fa31ce..fe62971c9d1f4a7470eabc0e84e8a747f84baf0d 100644
--- a/Documentation/devicetree/bindings/riscv/spacemit.yaml
+++ b/Documentation/devicetree/bindings/riscv/spacemit.yaml
@@ -9,6 +9,7 @@ title: SpacemiT SoC-based boards
 maintainers:
   - Yangyu Chen <cyy@cyyself.name>
   - Yixun Lan <dlan@gentoo.org>
+  - Guodong Xu <guodong@riscstar.com>
 
 description:
   SpacemiT SoC-based boards
@@ -26,6 +27,9 @@ properties:
               - xunlong,orangepi-r2s
               - xunlong,orangepi-rv2
           - const: spacemit,k1
+      - items:
+          - const: spacemit,k3-pico-itx
+          - const: spacemit,k3
 
 additionalProperties: true
 

-- 
2.43.0

[PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Guodong Xu]

Add description of the single-letter "B" extennsion for Bit Manipulation.
B is mandatory for RVA23U64.

The B extension is ratified in the 20240411 version of the unprivileged
ISA specification. According to the ratified spec, "the B standard
extension comprises instructions provided by the Zba, Zbb, and Zbs
extensions.

Hence add a schema check rule to enforce that B implies Zba, Zbb and Zbs.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: New patch.
---
 .../devicetree/bindings/riscv/extensions.yaml         | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 565cb2cbb49b552959392810a9b731b43346a594..385e1deb23996d294e7662693f1257f910a6e129 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -109,6 +109,13 @@ properties:
             The standard C extension for compressed instructions, as ratified in
             the 20191213 version of the unprivileged ISA specification.
 
+        - const: b
+          description:
+            The standard B extension for bit manipulation instructions, as
+            ratified in the 20240411 version of the unprivileged ISA
+            specification. The B standard extension comprises instructions
+            provided by the Zba, Zbb, and Zbs extensions.
+
         - const: v
           description:
             The standard V extension for vector operations, as ratified
@@ -735,6 +742,18 @@ properties:
         then:
           contains:
             const: f
+      # b comprises the following extensions
+      - if:
+          contains:
+            const: b
+        then:
+          allOf:
+            - contains:
+                const: zba
+            - contains:
+                const: zbb
+            - contains:
+                const: zbs
       # Zcb depends on Zca
       - if:
           contains:

-- 
2.43.0

[PATCH v2 08/13] dt-bindings: riscv: Add descriptions for Za64rs, Ziccamoa, Ziccif, and Zicclsm

[Guodong Xu]

Add descriptions for four extensions: Za64rs, Ziccamoa, Ziccif, and
Zicclsm. These extensions are ratified in RISC-V Profiles Version 1.0
(commit b1d806605f87 "Updated to ratified state.").

They are introduced as new extension names for existing features and
regulate implementation details for RISC-V Profile compliance. According
to RISC-V Profiles Version 1.0 and RVA23 Profiles Version 1.0, they are
mandatory for the following profiles:

 - za64rs: Mandatory in RVA22U64, RVA23U64
 - ziccamoa: Mandatory in RVA20U64, RVA22U64, RVA23U64
 - ziccif: Mandatory in RVA20U64, RVA22U64, RVA23U64
 - zicclsm: Mandatory in RVA20U64, RVA22U64, RVA23U64

Since Ziccamoa depends on the 'A' extension, add a schema check to
enforce this dependency.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: New patch.
---
 .../devicetree/bindings/riscv/extensions.yaml      | 34 ++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 385e1deb23996d294e7662693f1257f910a6e129..a6b9d7e3edf86ecfb117ba72e295ef097bdc9831 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -237,6 +237,12 @@ properties:
             as ratified at commit 4a69197e5617 ("Update to ratified state") of
             riscv-svvptc.
 
+        - const: za64rs
+          description:
+            The standard Za64rs extension for reservation set size of at most
+            64 bytes, as ratified in RISC-V Profiles Version 1.0, with commit
+            b1d806605f87 ("Updated to ratified state.")
+
         - const: zaamo
           description: |
             The standard Zaamo extension for atomic memory operations as
@@ -378,6 +384,27 @@ properties:
             in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
             riscv-isa-manual.
 
+        - const: ziccamoa
+          description:
+            The standard Ziccamoa extension for main memory (cacheability and
+            coherence) must support all atomics in A, as ratified in RISC-V
+            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
+            ratified state.")
+
+        - const: ziccif
+          description:
+            The standard Ziccif extension for main memory (cacheability and
+            coherence) instruction fetch atomicity, as ratified in RISC-V
+            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
+            ratified state.")
+
+        - const: zicclsm
+          description:
+            The standard Zicclsm extension for main memory (cacheability and
+            coherence) must support misaligned loads and stores, as ratified
+            in RISC-V Profiles Version 1.0, with commit b1d806605f87 ("Updated
+            to ratified state.")
+
         - const: ziccrse
           description:
             The standard Ziccrse extension which provides forward progress
@@ -795,6 +822,13 @@ properties:
         then:
           contains:
             const: f
+      # Ziccamoa depends on A
+      - if:
+          contains:
+            const: ziccamoa
+        then:
+          contains:
+            const: a
       # Zvfbfmin depends on V or Zve32f
       - if:
           contains:

-- 
2.43.0

[PATCH v2 09/13] dt-bindings: riscv: Add Ssccptr, Sscounterenw, Sstvala, Sstvecd, Ssu64xl

[Guodong Xu]

Add descriptions for five new extensions: Ssccptr, Sscounterenw, Sstvala,
Sstvecd, and Ssu64xl. These extensions are ratified in RISC-V Profiles
Version 1.0 (commit b1d806605f87 "Updated to ratified state.").

They are introduced as new extension names for existing features and
regulate implementation details for RISC-V Profile compliance. According
to RISC-V Profiles Version 1.0 and RVA23 Profiles Version 1.0, their
requirement status are:

 - Ssccptr: Mandatory in RVA20S64, RVA22S64, RVA23S64
 - Sscounterenw: Mandatory in RVA22S64, RVA23S64
 - Sstvala: Mandatory in RVA20S64, RVA22S64, RVA23S64
 - Sstvecd: Mandatory in RVA20S64, RVA22S64, RVA23S64
 - Ssu64xl: Optional in RVA20S64, RVA22S64; Mandatory in RVA23S64

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: New patch.
---
 .../devicetree/bindings/riscv/extensions.yaml      | 32 ++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index a6b9d7e3edf86ecfb117ba72e295ef097bdc9831..ed7a88c0ab3b7dc7ad4a4d2fd300d6fb33ef050c 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -160,12 +160,26 @@ properties:
             behavioural changes to interrupts as frozen at commit ccbddab
             ("Merge pull request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
 
+        - const: ssccptr
+          description: |
+            The standard Ssccptr extension for main memory (cacheability and
+            coherence) hardware page-table reads, as ratified in RISC-V
+            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
+            ratified state.")
+
         - const: sscofpmf
           description: |
             The standard Sscofpmf supervisor-level extension for count overflow
             and mode-based filtering as ratified at commit 01d1df0 ("Add ability
             to manually trigger workflow. (#2)") of riscv-count-overflow.
 
+        - const: sscounterenw
+          description: |
+            The standard Sscounterenw extension for support writable enables
+            in scounteren for any supported counter, as ratified in RISC-V
+            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
+            ratified state.")
+
         - const: ssnpm
           description: |
             The standard Ssnpm extension for next-mode pointer masking as
@@ -178,6 +192,24 @@ properties:
             ratified at commit 3f9ed34 ("Add ability to manually trigger
             workflow. (#2)") of riscv-time-compare.
 
+        - const: sstvala
+          description: |
+            The standard Sstvala extension for stval provides all needed values
+            as ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
+            ("Updated to ratified state.")
+
+        - const: sstvecd
+          description: |
+            The standard Sstvecd extension for stvec supports Direct mode as
+            ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
+            ("Updated to ratified state.")
+
+        - const: ssu64xl
+          description: |
+            The standard Ssu64xl extension for UXLEN=64 must be supported, as
+            ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
+            ("Updated to ratified state.")
+
         - const: svade
           description: |
             The standard Svade supervisor-level extension for SW-managed PTE A/D

-- 
2.43.0

[PATCH v2 10/13] dt-bindings: riscv: Add Sha and its comprised extensions

[Guodong Xu]

Add descriptions for the Sha extension and the seven extensions it
comprises: Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala, Shvstvecd,
and Ssstateen.

Sha is ratified in the RVA23 Profiles Version 1.0 (commit 0273f3c921b6
"rva23/rvb23 ratified") as a new profile-defined extension that captures
the full set of features that are mandated to be supported along with
the H extension.

Extensions Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala, Shvstvecd,
and Ssstateen are ratified in the RISC-V Profiles Version 1.0 (commit
b1d806605f87 "Updated to ratified state").

The requirement status for Sha and its comprised extension in RISC-V
Profiles are:
 - Sha: Mandatory in RVA23S64
 - H: Optional in RVA22S64; Mandatory in RVA23S64
 - Shcounterenw: Optional in RVA22S64; Mandatory in RVA23S64
 - Shgatpa: Optional in RVA22S64; Mandatory in RVA23S64
 - Shtvala: Optional in RVA22S64; Mandatory in RVA23S64
 - Shvsatpa: Optional in RVA22S64; Mandatory in RVA23S64
 - Shvstvala: Optional in RVA22S64; Mandatory in RVA23S64
 - Shvstvecd: Optional in RVA22S64; Mandatory in RVA23S64
 - Ssstateen: Optional in RVA22S64; Mandatory in RVA23S64

Add schema checks to enforce that Sha implies the presence of all its
comprised extensions.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: New patch.
---
 .../devicetree/bindings/riscv/extensions.yaml      | 79 ++++++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index ed7a88c0ab3b7dc7ad4a4d2fd300d6fb33ef050c..1066b7e65dab89704dbac449db4aa5605c95b9d3 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -128,6 +128,57 @@ properties:
             version of the privileged ISA specification.
 
         # multi-letter extensions, sorted alphanumerically
+        - const: sha
+          description: |
+            The standard Sha extension for augmented hypervisor extension as
+            ratified in RVA23 Profiles Version 1.0, with commit 0273f3c921b6
+            ("rva23/rvb23 ratified").
+
+            Sha captures the full set of features that are mandated to be
+            supported along with the H extension. Sha comprises the following
+            extensions: H, Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala,
+            Shvstvecd, and Ssstateen.
+
+        - const: shcounterenw
+          description: |
+            The standard Shcounterenw extension for support writable enables
+            in hcounteren for any supported counter, as ratified in RISC-V
+            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
+            ratified state.")
+
+        - const: shgatpa
+          description: |
+            The standard Shgatpa extension indicates that for each supported
+            virtual memory scheme SvNN supported in satp, the corresponding
+            hgatp SvNNx4 mode must be supported. The hgatp mode Bare must
+            also be supported. It is ratified in RISC-V Profiles Version 1.0,
+            with commit b1d806605f87 ("Updated to ratified state.")
+
+        - const: shtvala
+          description: |
+            The standard Shtvala extension for htval be written with the
+            faulting guest physical address in all circumstances permitted by
+            the ISA. It is ratified in RISC-V Profiles Version 1.0, with
+            commit b1d806605f87 ("Updated to ratified state.")
+
+        - const: shvsatpa
+          description: |
+            The standard Shvsatpa extension for vsatp supporting all translation
+            modes supported in satp, as ratified in RISC-V Profiles Version 1.0,
+            with commit b1d806605f87 ("Updated to ratified state.")
+
+        - const: shvstvala
+          description: |
+            The standard Shvstvala extension for vstval provides all needed
+            values as ratified in RISC-V Profiles Version 1.0, with commit
+            b1d806605f87 ("Updated to ratified state.")
+
+        - const: shvstvecd
+          description: |
+            The standard Shvstvecd extension for vstvec supporting Direct mode,
+            as ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
+            ("Updated to ratified state.")
+
         - const: smaia
           description: |
             The standard Smaia supervisor-level extension for the advanced
@@ -186,6 +237,12 @@ properties:
             ratified at commit d70011dde6c2 ("Update to ratified state")
             of riscv-j-extension.
 
+        - const: ssstateen
+          description: |
+            The standard Ssstateen extension for supervisor-mode view of the
+            state-enable extension, as ratified in RISC-V Profiles Version 1.0,
+            with commit b1d806605f87 ("Updated to ratified state.")
+
         - const: sstc
           description: |
             The standard Sstc supervisor-level extension for time compare as
@@ -813,6 +870,28 @@ properties:
                 const: zbb
             - contains:
                 const: zbs
+      # sha comprises the following extensions
+      - if:
+          contains:
+            const: sha
+        then:
+          allOf:
+            - contains:
+                const: h
+            - contains:
+                const: shcounterenw
+            - contains:
+                const: shgatpa
+            - contains:
+                const: shtvala
+            - contains:
+                const: shvsatpa
+            - contains:
+                const: shvstvala
+            - contains:
+                const: shvstvecd
+            - contains:
+                const: ssstateen
       # Zcb depends on Zca
       - if:
           contains:

-- 
2.43.0

[PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Guodong Xu]

Add description for the Supm extension. Supm indicates support for pointer
masking in user mode. Supm is mandatory for RVA23S64.

The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
state") of riscv-j-extension.

Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
this dependency.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: New patch.
---
 Documentation/devicetree/bindings/riscv/extensions.yaml | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 1066b7e65dab89704dbac449db4aa5605c95b9d3..4997f533b2c0defad88fd59413a6885b5b9e109a 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -267,6 +267,12 @@ properties:
             ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
             ("Updated to ratified state.")
 
+        - const: supm
+          description: |
+            The standard Supm extension for pointer masking support in user
+            mode as ratified at commit d70011dde6c2 ("Update to ratified state")
+            of riscv-j-extension.
+
         - const: svade
           description: |
             The standard Svade supervisor-level extension for SW-managed PTE A/D
@@ -892,6 +898,16 @@ properties:
                 const: shvstvecd
             - contains:
                 const: ssstateen
+      # Supm depends on either Smnpm or Ssnpm
+      - if:
+          contains:
+            const: supm
+        then:
+          anyOf:
+            - contains:
+                const: smnpm
+            - contains:
+                const: ssnpm
       # Zcb depends on Zca
       - if:
           contains:

-- 
2.43.0

[PATCH v2 12/13] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC

[Guodong Xu]

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>
---
v2: Remove aliases from k3.dtsi, they should be in board DTS.
    Updated riscv,isa-extensions with new extensions from the extensions.yaml
---
 arch/riscv/boot/dts/spacemit/k3.dtsi | 548 +++++++++++++++++++++++++++++++++++
 1 file changed, 548 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..ff1371e05ad1809cd823477d9599184f7597ce3b
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
@@ -0,0 +1,548 @@
+// 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";
+
+	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", "b", "v", "h",
+					       "sha", "shcounterenw", "shgatpa", "shtvala",
+					       "shvsatpa", "shvstvala", "shvstvecd", "smaia",
+					       "smstateen", "ssaia", "ssccptr", "sscofpmf",
+					       "sscounterenw", "ssnpm", "ssstateen", "sstc",
+					       "sstvala", "sstvecd", "ssu64xl", "supm",
+					       "svade", "svinval", "svnapot", "svpbmt",
+					       "za64rs", "zawrs", "zba", "zbb", "zbc", "zbs",
+					       "zca", "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
+					       "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
+					       "ziccamoa", "ziccif", "zicclsm", "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", "b", "v", "h",
+					       "sha", "shcounterenw", "shgatpa", "shtvala",
+					       "shvsatpa", "shvstvala", "shvstvecd", "smaia",
+					       "smstateen", "ssaia", "ssccptr", "sscofpmf",
+					       "sscounterenw", "ssnpm", "ssstateen", "sstc",
+					       "sstvala", "sstvecd", "ssu64xl", "supm",
+					       "svade", "svinval", "svnapot", "svpbmt",
+					       "za64rs", "zawrs", "zba", "zbb", "zbc", "zbs",
+					       "zca", "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
+					       "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
+					       "ziccamoa", "ziccif", "zicclsm", "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", "b", "v", "h",
+					       "sha", "shcounterenw", "shgatpa", "shtvala",
+					       "shvsatpa", "shvstvala", "shvstvecd", "smaia",
+					       "smstateen", "ssaia", "ssccptr", "sscofpmf",
+					       "sscounterenw", "ssnpm", "ssstateen", "sstc",
+					       "sstvala", "sstvecd", "ssu64xl", "supm",
+					       "svade", "svinval", "svnapot", "svpbmt",
+					       "za64rs", "zawrs", "zba", "zbb", "zbc", "zbs",
+					       "zca", "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
+					       "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
+					       "ziccamoa", "ziccif", "zicclsm", "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", "b", "v", "h",
+					       "sha", "shcounterenw", "shgatpa", "shtvala",
+					       "shvsatpa", "shvstvala", "shvstvecd", "smaia",
+					       "smstateen", "ssaia", "ssccptr", "sscofpmf",
+					       "sscounterenw", "ssnpm", "ssstateen", "sstc",
+					       "sstvala", "sstvecd", "ssu64xl", "supm",
+					       "svade", "svinval", "svnapot", "svpbmt",
+					       "za64rs", "zawrs", "zba", "zbb", "zbc", "zbs",
+					       "zca", "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
+					       "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
+					       "ziccamoa", "ziccif", "zicclsm", "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", "b", "v", "h",
+					       "sha", "shcounterenw", "shgatpa", "shtvala",
+					       "shvsatpa", "shvstvala", "shvstvecd", "smaia",
+					       "smstateen", "ssaia", "ssccptr", "sscofpmf",
+					       "sscounterenw", "ssnpm", "ssstateen", "sstc",
+					       "sstvala", "sstvecd", "ssu64xl", "supm",
+					       "svade", "svinval", "svnapot", "svpbmt",
+					       "za64rs", "zawrs", "zba", "zbb", "zbc", "zbs",
+					       "zca", "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
+					       "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
+					       "ziccamoa", "ziccif", "zicclsm", "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", "b", "v", "h",
+					       "sha", "shcounterenw", "shgatpa", "shtvala",
+					       "shvsatpa", "shvstvala", "shvstvecd", "smaia",
+					       "smstateen", "ssaia", "ssccptr", "sscofpmf",
+					       "sscounterenw", "ssnpm", "ssstateen", "sstc",
+					       "sstvala", "sstvecd", "ssu64xl", "supm",
+					       "svade", "svinval", "svnapot", "svpbmt",
+					       "za64rs", "zawrs", "zba", "zbb", "zbc", "zbs",
+					       "zca", "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
+					       "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
+					       "ziccamoa", "ziccif", "zicclsm", "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", "b", "v", "h",
+					       "sha", "shcounterenw", "shgatpa", "shtvala",
+					       "shvsatpa", "shvstvala", "shvstvecd", "smaia",
+					       "smstateen", "ssaia", "ssccptr", "sscofpmf",
+					       "sscounterenw", "ssnpm", "ssstateen", "sstc",
+					       "sstvala", "sstvecd", "ssu64xl", "supm",
+					       "svade", "svinval", "svnapot", "svpbmt",
+					       "za64rs", "zawrs", "zba", "zbb", "zbc", "zbs",
+					       "zca", "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
+					       "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
+					       "ziccamoa", "ziccif", "zicclsm", "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", "b", "v", "h",
+					       "sha", "shcounterenw", "shgatpa", "shtvala",
+					       "shvsatpa", "shvstvala", "shvstvecd", "smaia",
+					       "smstateen", "ssaia", "ssccptr", "sscofpmf",
+					       "sscounterenw", "ssnpm", "ssstateen", "sstc",
+					       "sstvala", "sstvecd", "ssu64xl", "supm",
+					       "svade", "svinval", "svnapot", "svpbmt",
+					       "za64rs", "zawrs", "zba", "zbb", "zbc", "zbs",
+					       "zca", "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
+					       "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
+					       "ziccamoa", "ziccif", "zicclsm", "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.0

[PATCH v2 13/13] riscv: dts: spacemit: add SpacemiT K3 Pico-ITX board device tree

[Guodong Xu]

K3 Pico-ITX is a 2.5-inch single-board computer equipted with a SpacemiT
K3 SoC.

This minimal device tree enables booting into a serial console with UART
output.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: Add aliases node in this board DT.
    Update the memory node to reflect the hardware truth. Address
     starts at 0x100000000 (4G) boundary.
---
 arch/riscv/boot/dts/spacemit/Makefile        |  1 +
 arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 38 ++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+)

diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
index 95889e7269d1bae679b28cd053e1b0a23ae6de68..7e2b877025718113a0e31917eadf7562f488d825 100644
--- a/arch/riscv/boot/dts/spacemit/Makefile
+++ b/arch/riscv/boot/dts/spacemit/Makefile
@@ -4,3 +4,4 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
 dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
 dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
 dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
+dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
diff --git a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
new file mode 100644
index 0000000000000000000000000000000000000000..037ce757e5bcae0258a326ea6265185d761f2b52
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
@@ -0,0 +1,38 @@
+// 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 "k3.dtsi"
+
+/ {
+	model = "SpacemiT K3 Pico-ITX";
+	compatible = "spacemit,k3-pico-itx", "spacemit,k3";
+
+	aliases {
+		serial0 = &uart0;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+		serial5 = &uart5;
+		serial6 = &uart6;
+		serial7 = &uart7;
+		serial8 = &uart8;
+		serial9 = &uart9;
+		serial10 = &uart10;
+	};
+
+	chosen {
+		stdout-path = "serial0";
+	};
+
+	memory@100000000 {
+		device_type = "memory";
+		reg = <0x1 0x00000000 0x4 0x00000000>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};

-- 
2.43.0

Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]

On Mon, Dec 22, 2025 at 09:04:21PM +0800, Guodong Xu wrote:
> Add description for the Supm extension. Supm indicates support for pointer
> masking in user mode. Supm is mandatory for RVA23S64.
> 
> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> state") of riscv-j-extension.
> 
> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> this dependency.
> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2: New patch.
> ---
>  Documentation/devicetree/bindings/riscv/extensions.yaml | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index 1066b7e65dab89704dbac449db4aa5605c95b9d3..4997f533b2c0defad88fd59413a6885b5b9e109a 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -267,6 +267,12 @@ properties:
>              ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
>              ("Updated to ratified state.")
>  
> +        - const: supm
> +          description: |
> +            The standard Supm extension for pointer masking support in user
> +            mode as ratified at commit d70011dde6c2 ("Update to ratified state")
> +            of riscv-j-extension.

I'm not yet convinced that this makes sense as this describes how the
consumer of the devicetree behaves not the hardware. How the hardware
behaves is already described by smnpn and ssnpm. I'd really like to
see some commentary from Samuel Holland on either this or on
https://lore.kernel.org/all/20251222-dimmer-wooing-db29fe925498@spud/
before I'd be happy with this change.

> +
>          - const: svade
>            description: |
>              The standard Svade supervisor-level extension for SW-managed PTE A/D
> @@ -892,6 +898,16 @@ properties:
>                  const: shvstvecd
>              - contains:
>                  const: ssstateen
> +      # Supm depends on either Smnpm or Ssnpm
> +      - if:
> +          contains:
> +            const: supm
> +        then:
> +          anyOf:
> +            - contains:
> +                const: smnpm
> +            - contains:
> +                const: ssnpm
>        # Zcb depends on Zca
>        - if:
>            contains:
> 
> -- 
> 2.43.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2817 bytes --]

On Mon, Dec 22, 2025 at 09:04:17PM +0800, Guodong Xu wrote:
> Add description of the single-letter "B" extennsion for Bit Manipulation.
> B is mandatory for RVA23U64.
> 
> The B extension is ratified in the 20240411 version of the unprivileged
> ISA specification. According to the ratified spec, "the B standard
> extension comprises instructions provided by the Zba, Zbb, and Zbs
> extensions.
> 
> Hence add a schema check rule to enforce that B implies Zba, Zbb and Zbs.
> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2: New patch.
> ---
>  .../devicetree/bindings/riscv/extensions.yaml         | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index 565cb2cbb49b552959392810a9b731b43346a594..385e1deb23996d294e7662693f1257f910a6e129 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -109,6 +109,13 @@ properties:
>              The standard C extension for compressed instructions, as ratified in
>              the 20191213 version of the unprivileged ISA specification.
>  
> +        - const: b
> +          description:
> +            The standard B extension for bit manipulation instructions, as
> +            ratified in the 20240411 version of the unprivileged ISA
> +            specification. The B standard extension comprises instructions
> +            provided by the Zba, Zbb, and Zbs extensions.
> +
>          - const: v
>            description:
>              The standard V extension for vector operations, as ratified
> @@ -735,6 +742,18 @@ properties:
>          then:
>            contains:
>              const: f
> +      # b comprises the following extensions
> +      - if:
> +          contains:
> +            const: b

What's the value in adding b, if it depends on having all 3 of the
components defined individually too? Currently all "superset" types of
extensions are permitted without their component parts also being defined,
this doesn't follow convention and therefore needs to be explained.

You obviously need this construct because the kernel does not understand
"b", and even if you added support for interpreting "b" to the kernel
this is probably still needed to make sure the ABI is maintained for
anything importing a devicetree from the kernel.

> +        then:
> +          allOf:
> +            - contains:
> +                const: zba
> +            - contains:
> +                const: zbb
> +            - contains:
> +                const: zbs
>        # Zcb depends on Zca
>        - if:
>            contains:
> 
> -- 
> 2.43.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Guodong Xu]

Hi, Conor

On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.org> wrote:
>
> On Mon, Dec 22, 2025 at 09:04:17PM +0800, Guodong Xu wrote:
> > Add description of the single-letter "B" extennsion for Bit Manipulation.
> > B is mandatory for RVA23U64.
> >
> > The B extension is ratified in the 20240411 version of the unprivileged
> > ISA specification. According to the ratified spec, "the B standard
> > extension comprises instructions provided by the Zba, Zbb, and Zbs
> > extensions.
> >
> > Hence add a schema check rule to enforce that B implies Zba, Zbb and Zbs.
> >
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> > v2: New patch.
> > ---
> >  .../devicetree/bindings/riscv/extensions.yaml         | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > index 565cb2cbb49b552959392810a9b731b43346a594..385e1deb23996d294e7662693f1257f910a6e129 100644
> > --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> > +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > @@ -109,6 +109,13 @@ properties:
> >              The standard C extension for compressed instructions, as ratified in
> >              the 20191213 version of the unprivileged ISA specification.
> >
> > +        - const: b
> > +          description:
> > +            The standard B extension for bit manipulation instructions, as
> > +            ratified in the 20240411 version of the unprivileged ISA
> > +            specification. The B standard extension comprises instructions
> > +            provided by the Zba, Zbb, and Zbs extensions.
> > +
> >          - const: v
> >            description:
> >              The standard V extension for vector operations, as ratified
> > @@ -735,6 +742,18 @@ properties:
> >          then:
> >            contains:
> >              const: f
> > +      # b comprises the following extensions
> > +      - if:
> > +          contains:
> > +            const: b
>
> What's the value in adding b, if it depends on having all 3 of the
> components defined individually too? Currently all "superset" types of
> extensions are permitted without their component parts also being defined,
> this doesn't follow convention and therefore needs to be explained.
>
> You obviously need this construct because the kernel does not understand
> "b", and even if you added support for interpreting "b" to the kernel
> this is probably still needed to make sure the ABI is maintained for
> anything importing a devicetree from the kernel.

Yes, exactly. Unlike other single-letter extensions, "b" was ratified
(Apr/2024) much later than its components zba/zbb/zbs (Jun/2021).
Existing software and the kernel already expect these explicit component
strings, so enforcing this dependency ensures cores declaring "b" will
also be correctly understood by older software that only looks for
zba/zbb/zbs.

I will update the commit message in v3 to clearly explain this reasoning.
Does it sound good to you?

Thank you for the review.

BR,
Guodong Xu

>
> > +        then:
> > +          allOf:
> > +            - contains:
> > +                const: zba
> > +            - contains:
> > +                const: zbb
> > +            - contains:
> > +                const: zbs
> >        # Zcb depends on Zca
> >        - if:
> >            contains:
> >
> > --
> > 2.43.0
> >

Re: [PATCH v2 04/13] dt-bindings: interrupt-controller: add SpacemiT K3 IMSIC

[Krzysztof Kozlowski]

On Mon, Dec 22, 2025 at 09:04:14PM +0800, Guodong Xu wrote:
> Add compatible string for SpacemiT K3 IMSIC.
> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2: Fix the order to keep things alphabetically.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v2 01/13] dt-bindings: riscv: add SpacemiT X100 CPU compatible

[Krzysztof Kozlowski]

On Mon, Dec 22, 2025 at 09:04:11PM +0800, Guodong Xu wrote:
> Add compatible string for the SpacemiT X100 core. [1]
> 
> The X100 is a 64-bit RVA23-compliant RISC-V core from SpacemiT. X100
> supports the RISC-V vector and hypervisor extensions and all mandatory
> extersions as required by the RVA23U64 and RVA23S64 profiles, per the
> definition in 'RVA23 Profile, Version 1.0'. [2]
> 
> >From a microarchieture viewpoint, the X100 features a 4-issue
> out-of-order pipeline.
> 
> X100 is used in SpacemiT K3 SoC.
> 
> Link: https://www.spacemit.com/en/spacemit-x100-core/ [1]
> Link: https://docs.riscv.org/reference/profiles/rva23/_attachments/rva23-profile.pdf [2]
> Reviewed-by: Yixun Lan <dlan@gentoo.org>
> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2: Fixed alphanumeric sorting of compatible strings, put x100 before x60,
>      as per Krzysztof's feedback.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3385 bytes --]

On Tue, Dec 23, 2025 at 02:51:17PM +0800, Guodong Xu wrote:
> Hi, Conor
> 
> On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.org> wrote:
> >
> > On Mon, Dec 22, 2025 at 09:04:17PM +0800, Guodong Xu wrote:
> > > Add description of the single-letter "B" extennsion for Bit Manipulation.
> > > B is mandatory for RVA23U64.
> > >
> > > The B extension is ratified in the 20240411 version of the unprivileged
> > > ISA specification. According to the ratified spec, "the B standard
> > > extension comprises instructions provided by the Zba, Zbb, and Zbs
> > > extensions.
> > >
> > > Hence add a schema check rule to enforce that B implies Zba, Zbb and Zbs.
> > >
> > > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > > ---
> > > v2: New patch.
> > > ---
> > >  .../devicetree/bindings/riscv/extensions.yaml         | 19 +++++++++++++++++++
> > >  1 file changed, 19 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > > index 565cb2cbb49b552959392810a9b731b43346a594..385e1deb23996d294e7662693f1257f910a6e129 100644
> > > --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> > > +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > > @@ -109,6 +109,13 @@ properties:
> > >              The standard C extension for compressed instructions, as ratified in
> > >              the 20191213 version of the unprivileged ISA specification.
> > >
> > > +        - const: b
> > > +          description:
> > > +            The standard B extension for bit manipulation instructions, as
> > > +            ratified in the 20240411 version of the unprivileged ISA
> > > +            specification. The B standard extension comprises instructions
> > > +            provided by the Zba, Zbb, and Zbs extensions.
> > > +
> > >          - const: v
> > >            description:
> > >              The standard V extension for vector operations, as ratified
> > > @@ -735,6 +742,18 @@ properties:
> > >          then:
> > >            contains:
> > >              const: f
> > > +      # b comprises the following extensions
> > > +      - if:
> > > +          contains:
> > > +            const: b
> >
> > What's the value in adding b, if it depends on having all 3 of the
> > components defined individually too? Currently all "superset" types of
> > extensions are permitted without their component parts also being defined,
> > this doesn't follow convention and therefore needs to be explained.
> >
> > You obviously need this construct because the kernel does not understand
> > "b", and even if you added support for interpreting "b" to the kernel
> > this is probably still needed to make sure the ABI is maintained for
> > anything importing a devicetree from the kernel.
> 
> Yes, exactly. Unlike other single-letter extensions, "b" was ratified
> (Apr/2024) much later than its components zba/zbb/zbs (Jun/2021).
> Existing software and the kernel already expect these explicit component
> strings, so enforcing this dependency ensures cores declaring "b" will
> also be correctly understood by older software that only looks for
> zba/zbb/zbs.
> 
> I will update the commit message in v3 to clearly explain this reasoning.

> Does it sound good to you?

Ye, sounds good.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Alex Elder]

On 12/23/25 12:51 AM, Guodong Xu wrote:
> Hi, Conor
> 
> On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.org> wrote:
>>
>> On Mon, Dec 22, 2025 at 09:04:17PM +0800, Guodong Xu wrote:
>>> Add description of the single-letter "B" extennsion for Bit Manipulation.
>>> B is mandatory for RVA23U64.
>>>
>>> The B extension is ratified in the 20240411 version of the unprivileged
>>> ISA specification. According to the ratified spec, "the B standard
>>> extension comprises instructions provided by the Zba, Zbb, and Zbs
>>> extensions.
>>>
>>> Hence add a schema check rule to enforce that B implies Zba, Zbb and Zbs.
>>>
>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>> ---
>>> v2: New patch.
>>> ---
>>>   .../devicetree/bindings/riscv/extensions.yaml         | 19 +++++++++++++++++++
>>>   1 file changed, 19 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> index 565cb2cbb49b552959392810a9b731b43346a594..385e1deb23996d294e7662693f1257f910a6e129 100644
>>> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> @@ -109,6 +109,13 @@ properties:
>>>               The standard C extension for compressed instructions, as ratified in
>>>               the 20191213 version of the unprivileged ISA specification.
>>>
>>> +        - const: b
>>> +          description:
>>> +            The standard B extension for bit manipulation instructions, as
>>> +            ratified in the 20240411 version of the unprivileged ISA
>>> +            specification. The B standard extension comprises instructions
>>> +            provided by the Zba, Zbb, and Zbs extensions.
>>> +
>>>           - const: v
>>>             description:
>>>               The standard V extension for vector operations, as ratified
>>> @@ -735,6 +742,18 @@ properties:
>>>           then:
>>>             contains:
>>>               const: f
>>> +      # b comprises the following extensions
>>> +      - if:
>>> +          contains:
>>> +            const: b
>>
>> What's the value in adding b, if it depends on having all 3 of the
>> components defined individually too? Currently all "superset" types of
>> extensions are permitted without their component parts also being defined,
>> this doesn't follow convention and therefore needs to be explained.
>>
>> You obviously need this construct because the kernel does not understand
>> "b", and even if you added support for interpreting "b" to the kernel
>> this is probably still needed to make sure the ABI is maintained for
>> anything importing a devicetree from the kernel.
> 
> Yes, exactly. Unlike other single-letter extensions, "b" was ratified
> (Apr/2024) much later than its components zba/zbb/zbs (Jun/2021).
> Existing software and the kernel already expect these explicit component
> strings, so enforcing this dependency ensures cores declaring "b" will
> also be correctly understood by older software that only looks for
> zba/zbb/zbs.

I might be misunderstanding you, but I don't think extension "b"
should *require* the other three extensions.  Instead, the "b"
extension should be considered *equivalent* to the other three.
That's what I understand it to mean, anyway.
   https://github.com/riscv/riscv-b

There's no point in supporting "b" in devicetree to represent
the others if it also requires the others to be present.

I think that, instead, "b", "zba", "zbb", and "zbs" should all
be allowed.

I might even go further and harden the requirement, saying that
if you specify "b" you should *not* specify "zba", "zbb", or "zbs".
But that might not be normal practice, and it's not necessary
because they aren't in conflict.

					-Alex

> I will update the commit message in v3 to clearly explain this reasoning.
> Does it sound good to you?
> 
> Thank you for the review.
> 
> BR,
> Guodong Xu
> 
>>
>>> +        then:
>>> +          allOf:
>>> +            - contains:
>>> +                const: zba
>>> +            - contains:
>>> +                const: zbb
>>> +            - contains:
>>> +                const: zbs
>>>         # Zcb depends on Zca
>>>         - if:
>>>             contains:
>>>
>>> --
>>> 2.43.0
>>>
> 

Re: [PATCH v2 08/13] dt-bindings: riscv: Add descriptions for Za64rs, Ziccamoa, Ziccif, and Zicclsm

[Alex Elder]

On 12/22/25 7:04 AM, Guodong Xu wrote:
> Add descriptions for four extensions: Za64rs, Ziccamoa, Ziccif, and
> Zicclsm. These extensions are ratified in RISC-V Profiles Version 1.0
> (commit b1d806605f87 "Updated to ratified state.").

I think stating the RISC-V profiles commit ID here (in the commit 
header) is good.

I do *not* think it's necessary to include it in the descriptions
for the extensions, below, but I seem to be late to the party in
expressing this opinion...

That commit ID is related to this repository:
   https://github.com/riscv/riscv-profiles.git

I have a few other comments below but generally I think what you
did looks good.  I have one overall question though.

> They are introduced as new extension names for existing features and
> regulate implementation details for RISC-V Profile compliance. According
> to RISC-V Profiles Version 1.0 and RVA23 Profiles Version 1.0, they are
> mandatory for the following profiles:
> 
>   - za64rs: Mandatory in RVA22U64, RVA23U64
>   - ziccamoa: Mandatory in RVA20U64, RVA22U64, RVA23U64
>   - ziccif: Mandatory in RVA20U64, RVA22U64, RVA23U64
>   - zicclsm: Mandatory in RVA20U64, RVA22U64, RVA23U64

I did not verify your statements about where these are
optional and mandatory, but I assume they're correct.

> Since Ziccamoa depends on the 'A' extension, add a schema check to
> enforce this dependency.

All of these extensions are related to atomic operations, right?
Don't *all* of them (not just Ziccamoa) depend on the A extension?
Furthermore, the A extension is already mandated by RVA23U64, so
is it really necessary to add this logic?


> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2: New patch.
> ---
>   .../devicetree/bindings/riscv/extensions.yaml      | 34 ++++++++++++++++++++++
>   1 file changed, 34 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index 385e1deb23996d294e7662693f1257f910a6e129..a6b9d7e3edf86ecfb117ba72e295ef097bdc9831 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -237,6 +237,12 @@ properties:
>               as ratified at commit 4a69197e5617 ("Update to ratified state") of
>               riscv-svvptc.
>   
> +        - const: za64rs
> +          description:
> +            The standard Za64rs extension for reservation set size of at most
> +            64 bytes, as ratified in RISC-V Profiles Version 1.0, with commit
> +            b1d806605f87 ("Updated to ratified state.")

The more complete description says:

     Reservation sets are contiguous, naturally aligned, and a maximum
     of 64 bytes.

But as I read on (below) I suppose using the more succinct description
from the glossary might be best, forcing people who care to go look
at the reference documents.

> +
>           - const: zaamo
>             description: |
>               The standard Zaamo extension for atomic memory operations as
> @@ -378,6 +384,27 @@ properties:
>               in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
>               riscv-isa-manual.
>   
> +        - const: ziccamoa
> +          description:
> +            The standard Ziccamoa extension for main memory (cacheability and
> +            coherence) must support all atomics in A, as ratified in RISC-V
> +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
> +            ratified state.")

Similar comment here (but also with a similar caveat):

   Main memory regions with both the cacheability and coherence PMAs
   must support all atomics in A.

And I might say "the A extension", but maybe that's a bad idea.

> +
> +        - const: ziccif
> +          description:
> +            The standard Ziccif extension for main memory (cacheability and
> +            coherence) instruction fetch atomicity, as ratified in RISC-V
> +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
> +            ratified state.")
> +
> +        - const: zicclsm
> +          description:
> +            The standard Zicclsm extension for main memory (cacheability and
> +            coherence) must support misaligned loads and stores, as ratified
> +            in RISC-V Profiles Version 1.0, with commit b1d806605f87 ("Updated
> +            to ratified state.")
> +
>           - const: ziccrse
>             description:
>               The standard Ziccrse extension which provides forward progress
> @@ -795,6 +822,13 @@ properties:
>           then:
>             contains:
>               const: f
> +      # Ziccamoa depends on A

Maybe more than just depends on the A extension.

					-Alex

> +      - if:
> +          contains:
> +            const: ziccamoa
> +        then:
> +          contains:
> +            const: a
>         # Zvfbfmin depends on V or Zve32f
>         - if:
>             contains:
> 

Re: [PATCH v2 09/13] dt-bindings: riscv: Add Ssccptr, Sscounterenw, Sstvala, Sstvecd, Ssu64xl

[Alex Elder]

On 12/22/25 7:04 AM, Guodong Xu wrote:
> Add descriptions for five new extensions: Ssccptr, Sscounterenw, Sstvala,
> Sstvecd, and Ssu64xl. These extensions are ratified in RISC-V Profiles
> Version 1.0 (commit b1d806605f87 "Updated to ratified state.").
> 
> They are introduced as new extension names for existing features and
> regulate implementation details for RISC-V Profile compliance. According
> to RISC-V Profiles Version 1.0 and RVA23 Profiles Version 1.0, their
> requirement status are:
> 
>   - Ssccptr: Mandatory in RVA20S64, RVA22S64, RVA23S64
>   - Sscounterenw: Mandatory in RVA22S64, RVA23S64
>   - Sstvala: Mandatory in RVA20S64, RVA22S64, RVA23S64
>   - Sstvecd: Mandatory in RVA20S64, RVA22S64, RVA23S64
>   - Ssu64xl: Optional in RVA20S64, RVA22S64; Mandatory in RVA23S64

Again, I did not verify your statements about where these are
optional and mandatory, but I assume they're correct.

> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2: New patch.
> ---
>   .../devicetree/bindings/riscv/extensions.yaml      | 32 ++++++++++++++++++++++
>   1 file changed, 32 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index a6b9d7e3edf86ecfb117ba72e295ef097bdc9831..ed7a88c0ab3b7dc7ad4a4d2fd300d6fb33ef050c 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -160,12 +160,26 @@ properties:
>               behavioural changes to interrupts as frozen at commit ccbddab
>               ("Merge pull request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
>   
> +        - const: ssccptr
> +          description: |
> +            The standard Ssccptr extension for main memory (cacheability and
> +            coherence) hardware page-table reads, as ratified in RISC-V
> +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
> +            ratified state.")
> +
>           - const: sscofpmf
>             description: |
>               The standard Sscofpmf supervisor-level extension for count overflow
>               and mode-based filtering as ratified at commit 01d1df0 ("Add ability
>               to manually trigger workflow. (#2)") of riscv-count-overflow.
>   
> +        - const: sscounterenw
> +          description: |
> +            The standard Sscounterenw extension for support writable enables
> +            in scounteren for any supported counter, as ratified in RISC-V
> +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
> +            ratified state.")

Maybe you should just copy the text from the RVA23 specification
for all of these.  So something like:

   For any hpmcounter that is not read-only zero, the corresponding
   bit in scounteren must be writable.  This was ratified in the
   RISC-V Profiles specification version 1.0, with commit ...

> +
>           - const: ssnpm
>             description: |
>               The standard Ssnpm extension for next-mode pointer masking as
> @@ -178,6 +192,24 @@ properties:
>               ratified at commit 3f9ed34 ("Add ability to manually trigger
>               workflow. (#2)") of riscv-time-compare.
>   
> +        - const: sstvala
> +          description: |
> +            The standard Sstvala extension for stval provides all needed values
> +            as ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
> +            ("Updated to ratified state.")

Or alternative to the full text in the spec, you could copy over
the abbreviated description listed in the glossary at the end
instead.  Something like:

   stval provides all needed values.  This was ratified in...

					-Alex

> +
> +        - const: sstvecd
> +          description: |
> +            The standard Sstvecd extension for stvec supports Direct mode as
> +            ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
> +            ("Updated to ratified state.")
> +
> +        - const: ssu64xl
> +          description: |
> +            The standard Ssu64xl extension for UXLEN=64 must be supported, as
> +            ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
> +            ("Updated to ratified state.")
> +
>           - const: svade
>             description: |
>               The standard Svade supervisor-level extension for SW-managed PTE A/D
> 

Re: [PATCH v2 10/13] dt-bindings: riscv: Add Sha and its comprised extensions

[Alex Elder]

On 12/22/25 7:04 AM, Guodong Xu wrote:
> Add descriptions for the Sha extension and the seven extensions it
> comprises: Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala, Shvstvecd,
> and Ssstateen.
> 
> Sha is ratified in the RVA23 Profiles Version 1.0 (commit 0273f3c921b6
> "rva23/rvb23 ratified") as a new profile-defined extension that captures
> the full set of features that are mandated to be supported along with
> the H extension.
> 
> Extensions Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala, Shvstvecd,
> and Ssstateen are ratified in the RISC-V Profiles Version 1.0 (commit
> b1d806605f87 "Updated to ratified state").
> 
> The requirement status for Sha and its comprised extension in RISC-V
> Profiles are:
>   - Sha: Mandatory in RVA23S64
>   - H: Optional in RVA22S64; Mandatory in RVA23S64
>   - Shcounterenw: Optional in RVA22S64; Mandatory in RVA23S64
>   - Shgatpa: Optional in RVA22S64; Mandatory in RVA23S64
>   - Shtvala: Optional in RVA22S64; Mandatory in RVA23S64
>   - Shvsatpa: Optional in RVA22S64; Mandatory in RVA23S64
>   - Shvstvala: Optional in RVA22S64; Mandatory in RVA23S64
>   - Shvstvecd: Optional in RVA22S64; Mandatory in RVA23S64
>   - Ssstateen: Optional in RVA22S64; Mandatory in RVA23S64
> 
> Add schema checks to enforce that Sha implies the presence of all its
> comprised extensions.

Like patch 7 in your series, I *think* what you're doing
in trying to imply the presence of these other extensions
is actually requiring all those extensions to be present
*in addition* to just "Sha".  I don't think that's what
we want.

					-Alex

> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2: New patch.
> ---
>   .../devicetree/bindings/riscv/extensions.yaml      | 79 ++++++++++++++++++++++
>   1 file changed, 79 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index ed7a88c0ab3b7dc7ad4a4d2fd300d6fb33ef050c..1066b7e65dab89704dbac449db4aa5605c95b9d3 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -128,6 +128,57 @@ properties:
>               version of the privileged ISA specification.
>   
>           # multi-letter extensions, sorted alphanumerically
> +        - const: sha
> +          description: |
> +            The standard Sha extension for augmented hypervisor extension as
> +            ratified in RVA23 Profiles Version 1.0, with commit 0273f3c921b6
> +            ("rva23/rvb23 ratified").
> +
> +            Sha captures the full set of features that are mandated to be
> +            supported along with the H extension. Sha comprises the following
> +            extensions: H, Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala,
> +            Shvstvecd, and Ssstateen.
> +
> +        - const: shcounterenw
> +          description: |
> +            The standard Shcounterenw extension for support writable enables
> +            in hcounteren for any supported counter, as ratified in RISC-V
> +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
> +            ratified state.")
> +
> +        - const: shgatpa
> +          description: |
> +            The standard Shgatpa extension indicates that for each supported
> +            virtual memory scheme SvNN supported in satp, the corresponding
> +            hgatp SvNNx4 mode must be supported. The hgatp mode Bare must
> +            also be supported. It is ratified in RISC-V Profiles Version 1.0,
> +            with commit b1d806605f87 ("Updated to ratified state.")
> +
> +        - const: shtvala
> +          description: |
> +            The standard Shtvala extension for htval be written with the
> +            faulting guest physical address in all circumstances permitted by
> +            the ISA. It is ratified in RISC-V Profiles Version 1.0, with
> +            commit b1d806605f87 ("Updated to ratified state.")
> +
> +        - const: shvsatpa
> +          description: |
> +            The standard Shvsatpa extension for vsatp supporting all translation
> +            modes supported in satp, as ratified in RISC-V Profiles Version 1.0,
> +            with commit b1d806605f87 ("Updated to ratified state.")
> +
> +        - const: shvstvala
> +          description: |
> +            The standard Shvstvala extension for vstval provides all needed
> +            values as ratified in RISC-V Profiles Version 1.0, with commit
> +            b1d806605f87 ("Updated to ratified state.")
> +
> +        - const: shvstvecd
> +          description: |
> +            The standard Shvstvecd extension for vstvec supporting Direct mode,
> +            as ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
> +            ("Updated to ratified state.")
> +
>           - const: smaia
>             description: |
>               The standard Smaia supervisor-level extension for the advanced
> @@ -186,6 +237,12 @@ properties:
>               ratified at commit d70011dde6c2 ("Update to ratified state")
>               of riscv-j-extension.
>   
> +        - const: ssstateen
> +          description: |
> +            The standard Ssstateen extension for supervisor-mode view of the
> +            state-enable extension, as ratified in RISC-V Profiles Version 1.0,
> +            with commit b1d806605f87 ("Updated to ratified state.")
> +
>           - const: sstc
>             description: |
>               The standard Sstc supervisor-level extension for time compare as
> @@ -813,6 +870,28 @@ properties:
>                   const: zbb
>               - contains:
>                   const: zbs
> +      # sha comprises the following extensions
> +      - if:
> +          contains:
> +            const: sha
> +        then:
> +          allOf:
> +            - contains:
> +                const: h
> +            - contains:
> +                const: shcounterenw
> +            - contains:
> +                const: shgatpa
> +            - contains:
> +                const: shtvala
> +            - contains:
> +                const: shvsatpa
> +            - contains:
> +                const: shvstvala
> +            - contains:
> +                const: shvstvecd
> +            - contains:
> +                const: ssstateen
>         # Zcb depends on Zca
>         - if:
>             contains:
> 

Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Alex Elder]

On 12/22/25 7:04 AM, Guodong Xu wrote:
> Add description for the Supm extension. Supm indicates support for pointer
> masking in user mode. Supm is mandatory for RVA23S64.
> 
> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> state") of riscv-j-extension.
> 
> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> this dependency.

I have the same general question on this, about whether it's really
necessary for the DT binding to enforce these requirements.  The
RISC-V specifications are what truly defines their meaning, so I
don't really see why the DT framework should need to enforce them.
(That said, I'm sure there are other cases where DT enforces things
it shouldn't have to.)


And now, having looked at these added binding definitions (in patches
07 through 11 in this series), I wonder what exactly is required for
them to be accepted.  For the most part these seem to just be defining
how the extensions specified for RISC-V are to be expressed in
DT files.  It seems to be a fairly straightforward copy from the
ratified specification(s) to the YAML format.

Who need to sign off on it?  Conor?  Paul?  DT maintainers?

Thanks.

					-Alex

> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2: New patch.
> ---
>   Documentation/devicetree/bindings/riscv/extensions.yaml | 16 ++++++++++++++++
>   1 file changed, 16 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index 1066b7e65dab89704dbac449db4aa5605c95b9d3..4997f533b2c0defad88fd59413a6885b5b9e109a 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -267,6 +267,12 @@ properties:
>               ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
>               ("Updated to ratified state.")
>   
> +        - const: supm
> +          description: |
> +            The standard Supm extension for pointer masking support in user
> +            mode as ratified at commit d70011dde6c2 ("Update to ratified state")
> +            of riscv-j-extension.
> +
>           - const: svade
>             description: |
>               The standard Svade supervisor-level extension for SW-managed PTE A/D
> @@ -892,6 +898,16 @@ properties:
>                   const: shvstvecd
>               - contains:
>                   const: ssstateen
> +      # Supm depends on either Smnpm or Ssnpm
> +      - if:
> +          contains:
> +            const: supm
> +        then:
> +          anyOf:
> +            - contains:
> +                const: smnpm
> +            - contains:
> +                const: ssnpm
>         # Zcb depends on Zca
>         - if:
>             contains:
> 

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Guodong Xu]

Hi, Alex

On Sat, Dec 27, 2025 at 5:28 AM Alex Elder <elder@riscstar.com> wrote:
>
> On 12/23/25 12:51 AM, Guodong Xu wrote:
> > Hi, Conor
> >
> > On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.org> wrote:
> >>
> >> On Mon, Dec 22, 2025 at 09:04:17PM +0800, Guodong Xu wrote:
> >>> Add description of the single-letter "B" extennsion for Bit Manipulation.
> >>> B is mandatory for RVA23U64.
> >>>
> >>> The B extension is ratified in the 20240411 version of the unprivileged
> >>> ISA specification. According to the ratified spec, "the B standard
> >>> extension comprises instructions provided by the Zba, Zbb, and Zbs
> >>> extensions.
> >>>
> >>> Hence add a schema check rule to enforce that B implies Zba, Zbb and Zbs.
> >>>
> >>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> >>> ---
> >>> v2: New patch.
> >>> ---
> >>>   .../devicetree/bindings/riscv/extensions.yaml         | 19 +++++++++++++++++++
> >>>   1 file changed, 19 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> >>> index 565cb2cbb49b552959392810a9b731b43346a594..385e1deb23996d294e7662693f1257f910a6e129 100644
> >>> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> >>> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> >>> @@ -109,6 +109,13 @@ properties:
> >>>               The standard C extension for compressed instructions, as ratified in
> >>>               the 20191213 version of the unprivileged ISA specification.
> >>>
> >>> +        - const: b
> >>> +          description:
> >>> +            The standard B extension for bit manipulation instructions, as
> >>> +            ratified in the 20240411 version of the unprivileged ISA
> >>> +            specification. The B standard extension comprises instructions
> >>> +            provided by the Zba, Zbb, and Zbs extensions.
> >>> +
> >>>           - const: v
> >>>             description:
> >>>               The standard V extension for vector operations, as ratified
> >>> @@ -735,6 +742,18 @@ properties:
> >>>           then:
> >>>             contains:
> >>>               const: f
> >>> +      # b comprises the following extensions
> >>> +      - if:
> >>> +          contains:
> >>> +            const: b
> >>
> >> What's the value in adding b, if it depends on having all 3 of the
> >> components defined individually too? Currently all "superset" types of
> >> extensions are permitted without their component parts also being defined,
> >> this doesn't follow convention and therefore needs to be explained.
> >>
> >> You obviously need this construct because the kernel does not understand
> >> "b", and even if you added support for interpreting "b" to the kernel
> >> this is probably still needed to make sure the ABI is maintained for
> >> anything importing a devicetree from the kernel.
> >
> > Yes, exactly. Unlike other single-letter extensions, "b" was ratified
> > (Apr/2024) much later than its components zba/zbb/zbs (Jun/2021).
> > Existing software and the kernel already expect these explicit component
> > strings, so enforcing this dependency ensures cores declaring "b" will
> > also be correctly understood by older software that only looks for
> > zba/zbb/zbs.
>
> I might be misunderstanding you, but I don't think extension "b"
> should *require* the other three extensions.  Instead, the "b"
> extension should be considered *equivalent* to the other three.

You are correct in saying they are equivalent.

> That's what I understand it to mean, anyway.
>    https://github.com/riscv/riscv-b
>
> There's no point in supporting "b" in devicetree to represent
> the others if it also requires the others to be present.
>
> I think that, instead, "b", "zba", "zbb", and "zbs" should all
> be allowed.
>
> I might even go further and harden the requirement, saying that
> if you specify "b" you should *not* specify "zba", "zbb", or "zbs".

Historical reasons here. "b" came too late. The chip vendors have published
cores with "zba", "zbb", and "zbs"already.

That's a migration bridge to require "b" must be listed
together with the other three.

BR,
Guodong

> But that might not be normal practice, and it's not necessary
> because they aren't in conflict.
>
>                                         -Alex
>
> > I will update the commit message in v3 to clearly explain this reasoning.
> > Does it sound good to you?
> >
> > Thank you for the review.
> >
> > BR,
> > Guodong Xu
> >
> >>
> >>> +        then:
> >>> +          allOf:
> >>> +            - contains:
> >>> +                const: zba
> >>> +            - contains:
> >>> +                const: zbb
> >>> +            - contains:
> >>> +                const: zbs
> >>>         # Zcb depends on Zca
> >>>         - if:
> >>>             contains:
> >>>
> >>> --
> >>> 2.43.0
> >>>
> >
>

Re: [PATCH v2 08/13] dt-bindings: riscv: Add descriptions for Za64rs, Ziccamoa, Ziccif, and Zicclsm

[Guodong Xu]

Hi, Alex, Conor

On Sat, Dec 27, 2025 at 5:28 AM Alex Elder <elder@riscstar.com> wrote:
>
> On 12/22/25 7:04 AM, Guodong Xu wrote:
> > Add descriptions for four extensions: Za64rs, Ziccamoa, Ziccif, and
> > Zicclsm. These extensions are ratified in RISC-V Profiles Version 1.0
> > (commit b1d806605f87 "Updated to ratified state.").
>
> I think stating the RISC-V profiles commit ID here (in the commit
> header) is good.
>
> I do *not* think it's necessary to include it in the descriptions
> for the extensions, below, but I seem to be late to the party in
> expressing this opinion...
>
> That commit ID is related to this repository:
>    https://github.com/riscv/riscv-profiles.git
>
> I have a few other comments below but generally I think what you
> did looks good.  I have one overall question though.
>
> > They are introduced as new extension names for existing features and
> > regulate implementation details for RISC-V Profile compliance. According
> > to RISC-V Profiles Version 1.0 and RVA23 Profiles Version 1.0, they are

Thank you for the review.

Together with the filenames, I also listed the Version numbers.

These are officially released versions of profile documents. I mean they
won't be changed without modifying the version number.

> > mandatory for the following profiles:
> >
> >   - za64rs: Mandatory in RVA22U64, RVA23U64
> >   - ziccamoa: Mandatory in RVA20U64, RVA22U64, RVA23U64
> >   - ziccif: Mandatory in RVA20U64, RVA22U64, RVA23U64
> >   - zicclsm: Mandatory in RVA20U64, RVA22U64, RVA23U64
>
> I did not verify your statements about where these are
> optional and mandatory, but I assume they're correct.

Yes they are correct. As far as what stated in the two profile documents.

>
> > Since Ziccamoa depends on the 'A' extension, add a schema check to
> > enforce this dependency.
>
> All of these extensions are related to atomic operations, right?
> Don't *all* of them (not just Ziccamoa) depend on the A extension?


Za64rs and Zicclsm: no, they are not 'A'. They are cache related.

Ziccrse and Ziccamoa: yes, they are 'A' related.

Ziccrse specifies the main memory must support "RsrvEventual", which is one
(totally there are four) of the support level for Load-Reserved/
Store-Conditional (LR/SC) atomic instructions.

And in RVA profiles, two named features (exts) are added:
Ziccrse: which further define the level of LR/SC operations being supported.
Ziccamoa: which further define the level of AMOs instructions being supported.


We already know that "A" = Zaamo + Zalrsc;

In summary, the dependencies among these extensions are:
Ziccrse -> Zalrsc -> A;
Ziccamoa -> Zaamo -> A;

> Furthermore, the A extension is already mandated by RVA23U64, so
> is it really necessary to add this logic?

Hi, Conor

What do you think? I am kind of agree with Alex to remove the schema
checking logic.

Leaving the dependency check to riscv/cpufeature.c, let the .validate call
do the job. If you agree, I can remove the schema checking logic on Ziccamoa
and A in my next version.

Btw, cpufeature.c validate() deserves another patch/patchset.
I'll be happy to add that if we reach a consensus here.

>
>
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> > v2: New patch.
> > ---
> >   .../devicetree/bindings/riscv/extensions.yaml      | 34 ++++++++++++++++++++++
> >   1 file changed, 34 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > index 385e1deb23996d294e7662693f1257f910a6e129..a6b9d7e3edf86ecfb117ba72e295ef097bdc9831 100644
> > --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> > +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > @@ -237,6 +237,12 @@ properties:
> >               as ratified at commit 4a69197e5617 ("Update to ratified state") of
> >               riscv-svvptc.
> >
> > +        - const: za64rs
> > +          description:
> > +            The standard Za64rs extension for reservation set size of at most
> > +            64 bytes, as ratified in RISC-V Profiles Version 1.0, with commit
> > +            b1d806605f87 ("Updated to ratified state.")
>
> The more complete description says:
>
>      Reservation sets are contiguous, naturally aligned, and a maximum
>      of 64 bytes.
>
> But as I read on (below) I suppose using the more succinct description
> from the glossary might be best, forcing people who care to go look

That is exactly what I am doing.

> at the reference documents.
>
> > +
> >           - const: zaamo
> >             description: |
> >               The standard Zaamo extension for atomic memory operations as
> > @@ -378,6 +384,27 @@ properties:
> >               in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
> >               riscv-isa-manual.
> >
> > +        - const: ziccamoa
> > +          description:
> > +            The standard Ziccamoa extension for main memory (cacheability and
> > +            coherence) must support all atomics in A, as ratified in RISC-V
> > +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
> > +            ratified state.")
>
> Similar comment here (but also with a similar caveat):
>

I am using what the RVA23 Profile defines:
"Ziccamoa: Main memory supports all atomics in A"

I prefer to keep it as is.

BR,
Guodong

>    Main memory regions with both the cacheability and coherence PMAs
>    must support all atomics in A.
>
> And I might say "the A extension", but maybe that's a bad idea.
>
> > +
> > +        - const: ziccif
> > +          description:
> > +            The standard Ziccif extension for main memory (cacheability and
> > +            coherence) instruction fetch atomicity, as ratified in RISC-V
> > +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
> > +            ratified state.")
> > +
> > +        - const: zicclsm
> > +          description:
> > +            The standard Zicclsm extension for main memory (cacheability and
> > +            coherence) must support misaligned loads and stores, as ratified
> > +            in RISC-V Profiles Version 1.0, with commit b1d806605f87 ("Updated
> > +            to ratified state.")
> > +
> >           - const: ziccrse
> >             description:
> >               The standard Ziccrse extension which provides forward progress
> > @@ -795,6 +822,13 @@ properties:
> >           then:
> >             contains:
> >               const: f
> > +      # Ziccamoa depends on A
>
> Maybe more than just depends on the A extension.
>
>                                         -Alex
>
> > +      - if:
> > +          contains:
> > +            const: ziccamoa
> > +        then:
> > +          contains:
> > +            const: a
> >         # Zvfbfmin depends on V or Zve32f
> >         - if:
> >             contains:
> >
>

Re: [PATCH v2 09/13] dt-bindings: riscv: Add Ssccptr, Sscounterenw, Sstvala, Sstvecd, Ssu64xl

[Guodong Xu]

Hi, Alex

On Sat, Dec 27, 2025 at 5:28 AM Alex Elder <elder@riscstar.com> wrote:
>
> On 12/22/25 7:04 AM, Guodong Xu wrote:
> > Add descriptions for five new extensions: Ssccptr, Sscounterenw, Sstvala,
> > Sstvecd, and Ssu64xl. These extensions are ratified in RISC-V Profiles
> > Version 1.0 (commit b1d806605f87 "Updated to ratified state.").
> >
> > They are introduced as new extension names for existing features and
> > regulate implementation details for RISC-V Profile compliance. According
> > to RISC-V Profiles Version 1.0 and RVA23 Profiles Version 1.0, their
> > requirement status are:
> >
> >   - Ssccptr: Mandatory in RVA20S64, RVA22S64, RVA23S64
> >   - Sscounterenw: Mandatory in RVA22S64, RVA23S64
> >   - Sstvala: Mandatory in RVA20S64, RVA22S64, RVA23S64
> >   - Sstvecd: Mandatory in RVA20S64, RVA22S64, RVA23S64
> >   - Ssu64xl: Optional in RVA20S64, RVA22S64; Mandatory in RVA23S64
>
> Again, I did not verify your statements about where these are
> optional and mandatory, but I assume they're correct.

Thanks for the review.

As mentioned in my response to patch 8, the requirement status for these
extensions is clearly defined in the RISC-V Profiles specification(s) which
I mentioned above.

I have verified these details against the official document to ensure
accuracy.

The extension descriptions are included in the commit message to provide
necessary background information.

>
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> > v2: New patch.
> > ---
> >   .../devicetree/bindings/riscv/extensions.yaml      | 32 ++++++++++++++++++++++
> >   1 file changed, 32 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > index a6b9d7e3edf86ecfb117ba72e295ef097bdc9831..ed7a88c0ab3b7dc7ad4a4d2fd300d6fb33ef050c 100644
> > --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> > +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > @@ -160,12 +160,26 @@ properties:
> >               behavioural changes to interrupts as frozen at commit ccbddab
> >               ("Merge pull request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
> >
> > +        - const: ssccptr
> > +          description: |
> > +            The standard Ssccptr extension for main memory (cacheability and
> > +            coherence) hardware page-table reads, as ratified in RISC-V
> > +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
> > +            ratified state.")
> > +
> >           - const: sscofpmf
> >             description: |
> >               The standard Sscofpmf supervisor-level extension for count overflow
> >               and mode-based filtering as ratified at commit 01d1df0 ("Add ability
> >               to manually trigger workflow. (#2)") of riscv-count-overflow.
> >
> > +        - const: sscounterenw
> > +          description: |
> > +            The standard Sscounterenw extension for support writable enables
> > +            in scounteren for any supported counter, as ratified in RISC-V

Here, I used the abbreviated version. See below.

> > +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
> > +            ratified state.")
>
> Maybe you should just copy the text from the RVA23 specification
> for all of these.  So something like:
>
>    For any hpmcounter that is not read-only zero, the corresponding
>    bit in scounteren must be writable.  This was ratified in the
>    RISC-V Profiles specification version 1.0, with commit ...
>

As you noticed, the RVA23 Profile v1.0 provides two versions of explanation
for Sscounterenw:
"Sscounterenw: For any hpmcounter that is not read-only zero, the corresponding
bit in scounteren must be writable"
"Sscounterenw: Support writeable enables for any supported counter"

BR,
Guodong Xu

> > +
> >           - const: ssnpm
> >             description: |
> >               The standard Ssnpm extension for next-mode pointer masking as
> > @@ -178,6 +192,24 @@ properties:
> >               ratified at commit 3f9ed34 ("Add ability to manually trigger
> >               workflow. (#2)") of riscv-time-compare.
> >
> > +        - const: sstvala
> > +          description: |
> > +            The standard Sstvala extension for stval provides all needed values
> > +            as ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
> > +            ("Updated to ratified state.")
>
> Or alternative to the full text in the spec, you could copy over
> the abbreviated description listed in the glossary at the end
> instead.  Something like:
>
>    stval provides all needed values.  This was ratified in...
>
>                                         -Alex
>
> > +
> > +        - const: sstvecd
> > +          description: |
> > +            The standard Sstvecd extension for stvec supports Direct mode as
> > +            ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
> > +            ("Updated to ratified state.")
> > +
> > +        - const: ssu64xl
> > +          description: |
> > +            The standard Ssu64xl extension for UXLEN=64 must be supported, as
> > +            ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
> > +            ("Updated to ratified state.")
> > +
> >           - const: svade
> >             description: |
> >               The standard Svade supervisor-level extension for SW-managed PTE A/D
> >
>

Re: [PATCH v2 10/13] dt-bindings: riscv: Add Sha and its comprised extensions

[Guodong Xu]

Hi, Alex

On Sat, Dec 27, 2025 at 5:28 AM Alex Elder <elder@riscstar.com> wrote:
>
> On 12/22/25 7:04 AM, Guodong Xu wrote:
> > Add descriptions for the Sha extension and the seven extensions it
> > comprises: Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala, Shvstvecd,
> > and Ssstateen.
> >
> > Sha is ratified in the RVA23 Profiles Version 1.0 (commit 0273f3c921b6
> > "rva23/rvb23 ratified") as a new profile-defined extension that captures
> > the full set of features that are mandated to be supported along with
> > the H extension.
> >
> > Extensions Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala, Shvstvecd,
> > and Ssstateen are ratified in the RISC-V Profiles Version 1.0 (commit
> > b1d806605f87 "Updated to ratified state").
> >
> > The requirement status for Sha and its comprised extension in RISC-V
> > Profiles are:
> >   - Sha: Mandatory in RVA23S64
> >   - H: Optional in RVA22S64; Mandatory in RVA23S64
> >   - Shcounterenw: Optional in RVA22S64; Mandatory in RVA23S64
> >   - Shgatpa: Optional in RVA22S64; Mandatory in RVA23S64
> >   - Shtvala: Optional in RVA22S64; Mandatory in RVA23S64
> >   - Shvsatpa: Optional in RVA22S64; Mandatory in RVA23S64
> >   - Shvstvala: Optional in RVA22S64; Mandatory in RVA23S64
> >   - Shvstvecd: Optional in RVA22S64; Mandatory in RVA23S64
> >   - Ssstateen: Optional in RVA22S64; Mandatory in RVA23S64
> >
> > Add schema checks to enforce that Sha implies the presence of all its
> > comprised extensions.
>
> Like patch 7 in your series, I *think* what you're doing
> in trying to imply the presence of these other extensions
> is actually requiring all those extensions to be present
> *in addition* to just "Sha".  I don't think that's what
> we want.

I tend to think this schema check block should be removed. Conor expressed
similar design logic in his comments to my Patch 7/13 of v2 series.

If there is no objection, I will remove it.

BR,
Guodong


>
>                                         -Alex
>
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> > v2: New patch.
> > ---
> >   .../devicetree/bindings/riscv/extensions.yaml      | 79 ++++++++++++++++++++++
> >   1 file changed, 79 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > index ed7a88c0ab3b7dc7ad4a4d2fd300d6fb33ef050c..1066b7e65dab89704dbac449db4aa5605c95b9d3 100644
> > --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> > +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > @@ -128,6 +128,57 @@ properties:
> >               version of the privileged ISA specification.
> >
> >           # multi-letter extensions, sorted alphanumerically
> > +        - const: sha
> > +          description: |
> > +            The standard Sha extension for augmented hypervisor extension as
> > +            ratified in RVA23 Profiles Version 1.0, with commit 0273f3c921b6
> > +            ("rva23/rvb23 ratified").
> > +
> > +            Sha captures the full set of features that are mandated to be
> > +            supported along with the H extension. Sha comprises the following
> > +            extensions: H, Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala,
> > +            Shvstvecd, and Ssstateen.
> > +
> > +        - const: shcounterenw
> > +          description: |
> > +            The standard Shcounterenw extension for support writable enables
> > +            in hcounteren for any supported counter, as ratified in RISC-V
> > +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
> > +            ratified state.")
> > +
> > +        - const: shgatpa
> > +          description: |
> > +            The standard Shgatpa extension indicates that for each supported
> > +            virtual memory scheme SvNN supported in satp, the corresponding
> > +            hgatp SvNNx4 mode must be supported. The hgatp mode Bare must
> > +            also be supported. It is ratified in RISC-V Profiles Version 1.0,
> > +            with commit b1d806605f87 ("Updated to ratified state.")
> > +
> > +        - const: shtvala
> > +          description: |
> > +            The standard Shtvala extension for htval be written with the
> > +            faulting guest physical address in all circumstances permitted by
> > +            the ISA. It is ratified in RISC-V Profiles Version 1.0, with
> > +            commit b1d806605f87 ("Updated to ratified state.")
> > +
> > +        - const: shvsatpa
> > +          description: |
> > +            The standard Shvsatpa extension for vsatp supporting all translation
> > +            modes supported in satp, as ratified in RISC-V Profiles Version 1.0,
> > +            with commit b1d806605f87 ("Updated to ratified state.")
> > +
> > +        - const: shvstvala
> > +          description: |
> > +            The standard Shvstvala extension for vstval provides all needed
> > +            values as ratified in RISC-V Profiles Version 1.0, with commit
> > +            b1d806605f87 ("Updated to ratified state.")
> > +
> > +        - const: shvstvecd
> > +          description: |
> > +            The standard Shvstvecd extension for vstvec supporting Direct mode,
> > +            as ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
> > +            ("Updated to ratified state.")
> > +
> >           - const: smaia
> >             description: |
> >               The standard Smaia supervisor-level extension for the advanced
> > @@ -186,6 +237,12 @@ properties:
> >               ratified at commit d70011dde6c2 ("Update to ratified state")
> >               of riscv-j-extension.
> >
> > +        - const: ssstateen
> > +          description: |
> > +            The standard Ssstateen extension for supervisor-mode view of the
> > +            state-enable extension, as ratified in RISC-V Profiles Version 1.0,
> > +            with commit b1d806605f87 ("Updated to ratified state.")
> > +
> >           - const: sstc
> >             description: |
> >               The standard Sstc supervisor-level extension for time compare as
> > @@ -813,6 +870,28 @@ properties:
> >                   const: zbb
> >               - contains:
> >                   const: zbs
> > +      # sha comprises the following extensions
> > +      - if:
> > +          contains:
> > +            const: sha
> > +        then:
> > +          allOf:
> > +            - contains:
> > +                const: h
> > +            - contains:
> > +                const: shcounterenw
> > +            - contains:
> > +                const: shgatpa
> > +            - contains:
> > +                const: shtvala
> > +            - contains:
> > +                const: shvsatpa
> > +            - contains:
> > +                const: shvstvala
> > +            - contains:
> > +                const: shvstvecd
> > +            - contains:
> > +                const: ssstateen
> >         # Zcb depends on Zca
> >         - if:
> >             contains:
> >
>

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Alex Elder]

On 12/27/25 8:51 PM, Guodong Xu wrote:
>> That's what I understand it to mean, anyway.
>>     https://github.com/riscv/riscv-b
>>
>> There's no point in supporting "b" in devicetree to represent
>> the others if it also requires the others to be present.
>>
>> I think that, instead, "b", "zba", "zbb", and "zbs" should all
>> be allowed.
>>
>> I might even go further and harden the requirement, saying that
>> if you specify "b" you should*not* specify "zba", "zbb", or "zbs".
> Historical reasons here. "b" came too late. The chip vendors have published
> cores with "zba", "zbb", and "zbs"already.
> 
> That's a migration bridge to require "b" must be listed
> together with the other three.

Are you saying "b" has already been included with "zba", "zbb", and
"zbs" in an existing DTS file?

What I'm suggesting is that (unless someone has already done this in
a DTS file), there is no reason to require "b" *and* the other three.
You should allow either "b" *or* all of the other three, not both.
That would support older platforms as well as newer ones that use
the more concise "b" only.

					-Alex

Re: [PATCH v2 08/13] dt-bindings: riscv: Add descriptions for Za64rs, Ziccamoa, Ziccif, and Zicclsm

[Alex Elder]

On 12/27/25 10:10 PM, Guodong Xu wrote:
> Hi, Alex, Conor
> 
> On Sat, Dec 27, 2025 at 5:28 AM Alex Elder <elder@riscstar.com> wrote:
>>
>> On 12/22/25 7:04 AM, Guodong Xu wrote:
>>> Add descriptions for four extensions: Za64rs, Ziccamoa, Ziccif, and
>>> Zicclsm. These extensions are ratified in RISC-V Profiles Version 1.0
>>> (commit b1d806605f87 "Updated to ratified state.").
>>
>> I think stating the RISC-V profiles commit ID here (in the commit
>> header) is good.
>>
>> I do *not* think it's necessary to include it in the descriptions
>> for the extensions, below, but I seem to be late to the party in
>> expressing this opinion...
>>
>> That commit ID is related to this repository:
>>     https://github.com/riscv/riscv-profiles.git
>>
>> I have a few other comments below but generally I think what you
>> did looks good.  I have one overall question though.
>>
>>> They are introduced as new extension names for existing features and
>>> regulate implementation details for RISC-V Profile compliance. According
>>> to RISC-V Profiles Version 1.0 and RVA23 Profiles Version 1.0, they are
> 
> Thank you for the review.
> 
> Together with the filenames, I also listed the Version numbers.
> 
> These are officially released versions of profile documents. I mean they
> won't be changed without modifying the version number.
> 
>>> mandatory for the following profiles:
>>>
>>>    - za64rs: Mandatory in RVA22U64, RVA23U64
>>>    - ziccamoa: Mandatory in RVA20U64, RVA22U64, RVA23U64
>>>    - ziccif: Mandatory in RVA20U64, RVA22U64, RVA23U64
>>>    - zicclsm: Mandatory in RVA20U64, RVA22U64, RVA23U64
>>
>> I did not verify your statements about where these are
>> optional and mandatory, but I assume they're correct.
> 
> Yes they are correct. As far as what stated in the two profile documents.
> 
>>
>>> Since Ziccamoa depends on the 'A' extension, add a schema check to
>>> enforce this dependency.
>>
>> All of these extensions are related to atomic operations, right?
>> Don't *all* of them (not just Ziccamoa) depend on the A extension?
> 
> 
> Za64rs and Zicclsm: no, they are not 'A'. They are cache related.

Isn't a Za64rs reservation set related to atomic operations,
though?  They are related to load-reserved/store conditional
instructions, which are introduced in the atomic instructions
section.

I was mistaken about Zicclsm, that's related to unaligned
accesses, but does not apply to atomic operations.

> Ziccrse and Ziccamoa: yes, they are 'A' related.
> 
> Ziccrse specifies the main memory must support "RsrvEventual", which is one
> (totally there are four) of the support level for Load-Reserved/
> Store-Conditional (LR/SC) atomic instructions.
> 
> And in RVA profiles, two named features (exts) are added:
> Ziccrse: which further define the level of LR/SC operations being supported.
> Ziccamoa: which further define the level of AMOs instructions being supported.
> 
> 
> We already know that "A" = Zaamo + Zalrsc;
> 
> In summary, the dependencies among these extensions are:
> Ziccrse -> Zalrsc -> A;
> Ziccamoa -> Zaamo -> A;
> 
>> Furthermore, the A extension is already mandated by RVA23U64, so
>> is it really necessary to add this logic?
> 
> Hi, Conor
> 
> What do you think? I am kind of agree with Alex to remove the schema
> checking logic.
> 
> Leaving the dependency check to riscv/cpufeature.c, let the .validate call
> do the job. If you agree, I can remove the schema checking logic on Ziccamoa
> and A in my next version.

Yes I think this is a better way to handle it.  Conor?

> Btw, cpufeature.c validate() deserves another patch/patchset.
> I'll be happy to add that if we reach a consensus here.

Yes I think you should do this once there is concensus.



> 
>>
>>
>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>> ---
>>> v2: New patch.
>>> ---
>>>    .../devicetree/bindings/riscv/extensions.yaml      | 34 ++++++++++++++++++++++
>>>    1 file changed, 34 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> index 385e1deb23996d294e7662693f1257f910a6e129..a6b9d7e3edf86ecfb117ba72e295ef097bdc9831 100644
>>> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> @@ -237,6 +237,12 @@ properties:
>>>                as ratified at commit 4a69197e5617 ("Update to ratified state") of
>>>                riscv-svvptc.
>>>
>>> +        - const: za64rs
>>> +          description:
>>> +            The standard Za64rs extension for reservation set size of at most
>>> +            64 bytes, as ratified in RISC-V Profiles Version 1.0, with commit
>>> +            b1d806605f87 ("Updated to ratified state.")
>>
>> The more complete description says:
>>
>>       Reservation sets are contiguous, naturally aligned, and a maximum
>>       of 64 bytes.
>>
>> But as I read on (below) I suppose using the more succinct description
>> from the glossary might be best, forcing people who care to go look
> 
> That is exactly what I am doing.
> 
>> at the reference documents.
>>
>>> +
>>>            - const: zaamo
>>>              description: |
>>>                The standard Zaamo extension for atomic memory operations as
>>> @@ -378,6 +384,27 @@ properties:
>>>                in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
>>>                riscv-isa-manual.
>>>
>>> +        - const: ziccamoa
>>> +          description:
>>> +            The standard Ziccamoa extension for main memory (cacheability and
>>> +            coherence) must support all atomics in A, as ratified in RISC-V
>>> +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
>>> +            ratified state.")
>>
>> Similar comment here (but also with a similar caveat):
>>
> 
> I am using what the RVA23 Profile defines:
> "Ziccamoa: Main memory supports all atomics in A"
> 
> I prefer to keep it as is.

That's fine.  I don't think I felt strongly about any of the things
I said about the exact wording used here.

Thanks.

					-Alex

> BR,
> Guodong
> 
>>     Main memory regions with both the cacheability and coherence PMAs
>>     must support all atomics in A.
>>
>> And I might say "the A extension", but maybe that's a bad idea.
>>
>>> +
>>> +        - const: ziccif
>>> +          description:
>>> +            The standard Ziccif extension for main memory (cacheability and
>>> +            coherence) instruction fetch atomicity, as ratified in RISC-V
>>> +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
>>> +            ratified state.")
>>> +
>>> +        - const: zicclsm
>>> +          description:
>>> +            The standard Zicclsm extension for main memory (cacheability and
>>> +            coherence) must support misaligned loads and stores, as ratified
>>> +            in RISC-V Profiles Version 1.0, with commit b1d806605f87 ("Updated
>>> +            to ratified state.")
>>> +
>>>            - const: ziccrse
>>>              description:
>>>                The standard Ziccrse extension which provides forward progress
>>> @@ -795,6 +822,13 @@ properties:
>>>            then:
>>>              contains:
>>>                const: f
>>> +      # Ziccamoa depends on A
>>
>> Maybe more than just depends on the A extension.
>>
>>                                          -Alex
>>
>>> +      - if:
>>> +          contains:
>>> +            const: ziccamoa
>>> +        then:
>>> +          contains:
>>> +            const: a
>>>          # Zvfbfmin depends on V or Zve32f
>>>          - if:
>>>              contains:
>>>
>>

Re: [PATCH v2 09/13] dt-bindings: riscv: Add Ssccptr, Sscounterenw, Sstvala, Sstvecd, Ssu64xl

[Alex Elder]

On 12/28/25 6:31 AM, Guodong Xu wrote:
> Hi, Alex
> 
> On Sat, Dec 27, 2025 at 5:28 AM Alex Elder <elder@riscstar.com> wrote:
>>
>> On 12/22/25 7:04 AM, Guodong Xu wrote:
>>> Add descriptions for five new extensions: Ssccptr, Sscounterenw, Sstvala,
>>> Sstvecd, and Ssu64xl. These extensions are ratified in RISC-V Profiles
>>> Version 1.0 (commit b1d806605f87 "Updated to ratified state.").
>>>
>>> They are introduced as new extension names for existing features and
>>> regulate implementation details for RISC-V Profile compliance. According
>>> to RISC-V Profiles Version 1.0 and RVA23 Profiles Version 1.0, their
>>> requirement status are:
>>>
>>>    - Ssccptr: Mandatory in RVA20S64, RVA22S64, RVA23S64
>>>    - Sscounterenw: Mandatory in RVA22S64, RVA23S64
>>>    - Sstvala: Mandatory in RVA20S64, RVA22S64, RVA23S64
>>>    - Sstvecd: Mandatory in RVA20S64, RVA22S64, RVA23S64
>>>    - Ssu64xl: Optional in RVA20S64, RVA22S64; Mandatory in RVA23S64
>>
>> Again, I did not verify your statements about where these are
>> optional and mandatory, but I assume they're correct.
> 
> Thanks for the review.
> 
> As mentioned in my response to patch 8, the requirement status for these
> extensions is clearly defined in the RISC-V Profiles specification(s) which
> I mentioned above.
> 
> I have verified these details against the official document to ensure
> accuracy.

Right, my comment here was just to be transparent that *I* did
not check this, and am trusting that what you said is right.
Thanks for confirming.

					-Alex

> The extension descriptions are included in the commit message to provide
> necessary background information.
> 
>>
>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>> ---
>>> v2: New patch.
>>> ---
>>>    .../devicetree/bindings/riscv/extensions.yaml      | 32 ++++++++++++++++++++++
>>>    1 file changed, 32 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> index a6b9d7e3edf86ecfb117ba72e295ef097bdc9831..ed7a88c0ab3b7dc7ad4a4d2fd300d6fb33ef050c 100644
>>> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> @@ -160,12 +160,26 @@ properties:
>>>                behavioural changes to interrupts as frozen at commit ccbddab
>>>                ("Merge pull request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
>>>
>>> +        - const: ssccptr
>>> +          description: |
>>> +            The standard Ssccptr extension for main memory (cacheability and
>>> +            coherence) hardware page-table reads, as ratified in RISC-V
>>> +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
>>> +            ratified state.")
>>> +
>>>            - const: sscofpmf
>>>              description: |
>>>                The standard Sscofpmf supervisor-level extension for count overflow
>>>                and mode-based filtering as ratified at commit 01d1df0 ("Add ability
>>>                to manually trigger workflow. (#2)") of riscv-count-overflow.
>>>
>>> +        - const: sscounterenw
>>> +          description: |
>>> +            The standard Sscounterenw extension for support writable enables
>>> +            in scounteren for any supported counter, as ratified in RISC-V
> 
> Here, I used the abbreviated version. See below.
> 
>>> +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
>>> +            ratified state.")
>>
>> Maybe you should just copy the text from the RVA23 specification
>> for all of these.  So something like:
>>
>>     For any hpmcounter that is not read-only zero, the corresponding
>>     bit in scounteren must be writable.  This was ratified in the
>>     RISC-V Profiles specification version 1.0, with commit ...
>>
> 
> As you noticed, the RVA23 Profile v1.0 provides two versions of explanation
> for Sscounterenw:
> "Sscounterenw: For any hpmcounter that is not read-only zero, the corresponding
> bit in scounteren must be writable"
> "Sscounterenw: Support writeable enables for any supported counter"
> 
> BR,
> Guodong Xu
> 
>>> +
>>>            - const: ssnpm
>>>              description: |
>>>                The standard Ssnpm extension for next-mode pointer masking as
>>> @@ -178,6 +192,24 @@ properties:
>>>                ratified at commit 3f9ed34 ("Add ability to manually trigger
>>>                workflow. (#2)") of riscv-time-compare.
>>>
>>> +        - const: sstvala
>>> +          description: |
>>> +            The standard Sstvala extension for stval provides all needed values
>>> +            as ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
>>> +            ("Updated to ratified state.")
>>
>> Or alternative to the full text in the spec, you could copy over
>> the abbreviated description listed in the glossary at the end
>> instead.  Something like:
>>
>>     stval provides all needed values.  This was ratified in...
>>
>>                                          -Alex
>>
>>> +
>>> +        - const: sstvecd
>>> +          description: |
>>> +            The standard Sstvecd extension for stvec supports Direct mode as
>>> +            ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
>>> +            ("Updated to ratified state.")
>>> +
>>> +        - const: ssu64xl
>>> +          description: |
>>> +            The standard Ssu64xl extension for UXLEN=64 must be supported, as
>>> +            ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
>>> +            ("Updated to ratified state.")
>>> +
>>>            - const: svade
>>>              description: |
>>>                The standard Svade supervisor-level extension for SW-managed PTE A/D
>>>
>>

Re: [PATCH v2 10/13] dt-bindings: riscv: Add Sha and its comprised extensions

[Alex Elder]

On 12/28/25 6:43 AM, Guodong Xu wrote:
> Hi, Alex
> 
> On Sat, Dec 27, 2025 at 5:28 AM Alex Elder <elder@riscstar.com> wrote:
>>
>> On 12/22/25 7:04 AM, Guodong Xu wrote:
>>> Add descriptions for the Sha extension and the seven extensions it
>>> comprises: Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala, Shvstvecd,
>>> and Ssstateen.
>>>
>>> Sha is ratified in the RVA23 Profiles Version 1.0 (commit 0273f3c921b6
>>> "rva23/rvb23 ratified") as a new profile-defined extension that captures
>>> the full set of features that are mandated to be supported along with
>>> the H extension.
>>>
>>> Extensions Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala, Shvstvecd,
>>> and Ssstateen are ratified in the RISC-V Profiles Version 1.0 (commit
>>> b1d806605f87 "Updated to ratified state").
>>>
>>> The requirement status for Sha and its comprised extension in RISC-V
>>> Profiles are:
>>>    - Sha: Mandatory in RVA23S64
>>>    - H: Optional in RVA22S64; Mandatory in RVA23S64
>>>    - Shcounterenw: Optional in RVA22S64; Mandatory in RVA23S64
>>>    - Shgatpa: Optional in RVA22S64; Mandatory in RVA23S64
>>>    - Shtvala: Optional in RVA22S64; Mandatory in RVA23S64
>>>    - Shvsatpa: Optional in RVA22S64; Mandatory in RVA23S64
>>>    - Shvstvala: Optional in RVA22S64; Mandatory in RVA23S64
>>>    - Shvstvecd: Optional in RVA22S64; Mandatory in RVA23S64
>>>    - Ssstateen: Optional in RVA22S64; Mandatory in RVA23S64
>>>
>>> Add schema checks to enforce that Sha implies the presence of all its
>>> comprised extensions.
>>
>> Like patch 7 in your series, I *think* what you're doing
>> in trying to imply the presence of these other extensions
>> is actually requiring all those extensions to be present
>> *in addition* to just "Sha".  I don't think that's what
>> we want.
> 
> I tend to think this schema check block should be removed. Conor expressed
> similar design logic in his comments to my Patch 7/13 of v2 series.
> 
> If there is no objection, I will remove it.

Sounds good.	-Alex

> BR,
> Guodong
> 
> 
>>
>>                                          -Alex
>>
>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>> ---
>>> v2: New patch.
>>> ---
>>>    .../devicetree/bindings/riscv/extensions.yaml      | 79 ++++++++++++++++++++++
>>>    1 file changed, 79 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> index ed7a88c0ab3b7dc7ad4a4d2fd300d6fb33ef050c..1066b7e65dab89704dbac449db4aa5605c95b9d3 100644
>>> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> @@ -128,6 +128,57 @@ properties:
>>>                version of the privileged ISA specification.
>>>
>>>            # multi-letter extensions, sorted alphanumerically
>>> +        - const: sha
>>> +          description: |
>>> +            The standard Sha extension for augmented hypervisor extension as
>>> +            ratified in RVA23 Profiles Version 1.0, with commit 0273f3c921b6
>>> +            ("rva23/rvb23 ratified").
>>> +
>>> +            Sha captures the full set of features that are mandated to be
>>> +            supported along with the H extension. Sha comprises the following
>>> +            extensions: H, Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala,
>>> +            Shvstvecd, and Ssstateen.
>>> +
>>> +        - const: shcounterenw
>>> +          description: |
>>> +            The standard Shcounterenw extension for support writable enables
>>> +            in hcounteren for any supported counter, as ratified in RISC-V
>>> +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
>>> +            ratified state.")
>>> +
>>> +        - const: shgatpa
>>> +          description: |
>>> +            The standard Shgatpa extension indicates that for each supported
>>> +            virtual memory scheme SvNN supported in satp, the corresponding
>>> +            hgatp SvNNx4 mode must be supported. The hgatp mode Bare must
>>> +            also be supported. It is ratified in RISC-V Profiles Version 1.0,
>>> +            with commit b1d806605f87 ("Updated to ratified state.")
>>> +
>>> +        - const: shtvala
>>> +          description: |
>>> +            The standard Shtvala extension for htval be written with the
>>> +            faulting guest physical address in all circumstances permitted by
>>> +            the ISA. It is ratified in RISC-V Profiles Version 1.0, with
>>> +            commit b1d806605f87 ("Updated to ratified state.")
>>> +
>>> +        - const: shvsatpa
>>> +          description: |
>>> +            The standard Shvsatpa extension for vsatp supporting all translation
>>> +            modes supported in satp, as ratified in RISC-V Profiles Version 1.0,
>>> +            with commit b1d806605f87 ("Updated to ratified state.")
>>> +
>>> +        - const: shvstvala
>>> +          description: |
>>> +            The standard Shvstvala extension for vstval provides all needed
>>> +            values as ratified in RISC-V Profiles Version 1.0, with commit
>>> +            b1d806605f87 ("Updated to ratified state.")
>>> +
>>> +        - const: shvstvecd
>>> +          description: |
>>> +            The standard Shvstvecd extension for vstvec supporting Direct mode,
>>> +            as ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
>>> +            ("Updated to ratified state.")
>>> +
>>>            - const: smaia
>>>              description: |
>>>                The standard Smaia supervisor-level extension for the advanced
>>> @@ -186,6 +237,12 @@ properties:
>>>                ratified at commit d70011dde6c2 ("Update to ratified state")
>>>                of riscv-j-extension.
>>>
>>> +        - const: ssstateen
>>> +          description: |
>>> +            The standard Ssstateen extension for supervisor-mode view of the
>>> +            state-enable extension, as ratified in RISC-V Profiles Version 1.0,
>>> +            with commit b1d806605f87 ("Updated to ratified state.")
>>> +
>>>            - const: sstc
>>>              description: |
>>>                The standard Sstc supervisor-level extension for time compare as
>>> @@ -813,6 +870,28 @@ properties:
>>>                    const: zbb
>>>                - contains:
>>>                    const: zbs
>>> +      # sha comprises the following extensions
>>> +      - if:
>>> +          contains:
>>> +            const: sha
>>> +        then:
>>> +          allOf:
>>> +            - contains:
>>> +                const: h
>>> +            - contains:
>>> +                const: shcounterenw
>>> +            - contains:
>>> +                const: shgatpa
>>> +            - contains:
>>> +                const: shtvala
>>> +            - contains:
>>> +                const: shvsatpa
>>> +            - contains:
>>> +                const: shvstvala
>>> +            - contains:
>>> +                const: shvstvecd
>>> +            - contains:
>>> +                const: ssstateen
>>>          # Zcb depends on Zca
>>>          - if:
>>>              contains:
>>>
>>

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Guodong Xu]

On Mon, Dec 29, 2025 at 7:50 AM Alex Elder <elder@riscstar.com> wrote:
>
> On 12/27/25 8:51 PM, Guodong Xu wrote:
> >> That's what I understand it to mean, anyway.
> >>     https://github.com/riscv/riscv-b
> >>
> >> There's no point in supporting "b" in devicetree to represent
> >> the others if it also requires the others to be present.
> >>
> >> I think that, instead, "b", "zba", "zbb", and "zbs" should all
> >> be allowed.
> >>
> >> I might even go further and harden the requirement, saying that
> >> if you specify "b" you should*not* specify "zba", "zbb", or "zbs".
> > Historical reasons here. "b" came too late. The chip vendors have published
> > cores with "zba", "zbb", and "zbs"already.
> >
> > That's a migration bridge to require "b" must be listed
> > together with the other three.
>
> Are you saying "b" has already been included with "zba", "zbb", and
> "zbs" in an existing DTS file?


The risc-v ratification timeline is:
"b" was ratified in Apr/2024, which is about 2 years later than its
components zba/zbb/zbs (these were ratified in Jun/2021).

I can do this in linux kernel, writing a dts file which contains only "b",
but no zba/zbb/zbs. The linux kernel can correctly extend "b" to zba/zbb/zbs.
ps: after I or somebody adds the logic into cpufeature.c.

However, the problem is with the older software who reuse kernel's DTS files,
and recognizes only 'zba/zbb/zbs'. (If you search in the riscv/boot/dts,
you will notice a lot platforms supports zba/zbb/zbs.)

When there is only "b", these older software may just disable the features
related to 'zba/zbb/zbs', because when they developed their feature,
"b" doesn't exist yet.

Hopefully I explained the logic clear this time.

BR,
Guodong

>
> What I'm suggesting is that (unless someone has already done this in
> a DTS file), there is no reason to require "b" *and* the other three.
> You should allow either "b" *or* all of the other three, not both.
> That would support older platforms as well as newer ones that use
> the more concise "b" only.
>
>                                         -Alex

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Alex Elder]

On 12/28/25 7:08 PM, Guodong Xu wrote:
> On Mon, Dec 29, 2025 at 7:50 AM Alex Elder <elder@riscstar.com> wrote:
>>
>> On 12/27/25 8:51 PM, Guodong Xu wrote:
>>>> That's what I understand it to mean, anyway.
>>>>      https://github.com/riscv/riscv-b
>>>>
>>>> There's no point in supporting "b" in devicetree to represent
>>>> the others if it also requires the others to be present.
>>>>
>>>> I think that, instead, "b", "zba", "zbb", and "zbs" should all
>>>> be allowed.
>>>>
>>>> I might even go further and harden the requirement, saying that
>>>> if you specify "b" you should*not* specify "zba", "zbb", or "zbs".
>>> Historical reasons here. "b" came too late. The chip vendors have published
>>> cores with "zba", "zbb", and "zbs"already.
>>>
>>> That's a migration bridge to require "b" must be listed
>>> together with the other three.
>>
>> Are you saying "b" has already been included with "zba", "zbb", and
>> "zbs" in an existing DTS file?
> 
> 
> The risc-v ratification timeline is:
> "b" was ratified in Apr/2024, which is about 2 years later than its
> components zba/zbb/zbs (these were ratified in Jun/2021).
> 
> I can do this in linux kernel, writing a dts file which contains only "b",
> but no zba/zbb/zbs. The linux kernel can correctly extend "b" to zba/zbb/zbs.
> ps: after I or somebody adds the logic into cpufeature.c.

Yes, this part I understand.  (Yes, do that...)

> However, the problem is with the older software who reuse kernel's DTS files,
> and recognizes only 'zba/zbb/zbs'. (If you search in the riscv/boot/dts,
> you will notice a lot platforms supports zba/zbb/zbs.)
> 
> When there is only "b", these older software may just disable the features
> related to 'zba/zbb/zbs', because when they developed their feature,
> "b" doesn't exist yet.

Yes, old DTS files can and will continue to specify
"zba+zbb+zbs".  But those old DTS files are not expected
to be changed to replace "zba+zbb+zbs" with just "h".

Once "cpufeature.c" supports the "h" extension, the
software supports either one:  "h" or "zba+zbb+zbs".

The key point I'm trying to make is that the binding
should not require "zba+zbb+zbs" to supplied *on top of*
the "h" in the list of CPU extensions.  Only one or the
other should be sufficient.  And I think your binding
was saying "if "h" then required "zba+zbb+zbs".

> Hopefully I explained the logic clear this time.

I think you have done your best.  I hope I'm not just being
dense.

					-Alex

> BR,
> Guodong
> 
>>
>> What I'm suggesting is that (unless someone has already done this in
>> a DTS file), there is no reason to require "b" *and* the other three.
>> You should allow either "b" *or* all of the other three, not both.
>> That would support older platforms as well as newer ones that use
>> the more concise "b" only.
>>
>>                                          -Alex

Re: [PATCH v2 08/13] dt-bindings: riscv: Add descriptions for Za64rs, Ziccamoa, Ziccif, and Zicclsm

[Guodong Xu]

On Mon, Dec 29, 2025 at 7:50 AM Alex Elder <elder@riscstar.com> wrote:
>
> On 12/27/25 10:10 PM, Guodong Xu wrote:
> > Hi, Alex, Conor
> >
> > On Sat, Dec 27, 2025 at 5:28 AM Alex Elder <elder@riscstar.com> wrote:
> >>
> >> On 12/22/25 7:04 AM, Guodong Xu wrote:
> >>> Add descriptions for four extensions: Za64rs, Ziccamoa, Ziccif, and
> >>> Zicclsm. These extensions are ratified in RISC-V Profiles Version 1.0
> >>> (commit b1d806605f87 "Updated to ratified state.").
> >>
> >> I think stating the RISC-V profiles commit ID here (in the commit
> >> header) is good.
> >>
> >> I do *not* think it's necessary to include it in the descriptions
> >> for the extensions, below, but I seem to be late to the party in
> >> expressing this opinion...
> >>
> >> That commit ID is related to this repository:
> >>     https://github.com/riscv/riscv-profiles.git
> >>
> >> I have a few other comments below but generally I think what you
> >> did looks good.  I have one overall question though.
> >>
> >>> They are introduced as new extension names for existing features and
> >>> regulate implementation details for RISC-V Profile compliance. According
> >>> to RISC-V Profiles Version 1.0 and RVA23 Profiles Version 1.0, they are
> >
> > Thank you for the review.
> >
> > Together with the filenames, I also listed the Version numbers.
> >
> > These are officially released versions of profile documents. I mean they
> > won't be changed without modifying the version number.
> >
> >>> mandatory for the following profiles:
> >>>
> >>>    - za64rs: Mandatory in RVA22U64, RVA23U64
> >>>    - ziccamoa: Mandatory in RVA20U64, RVA22U64, RVA23U64
> >>>    - ziccif: Mandatory in RVA20U64, RVA22U64, RVA23U64
> >>>    - zicclsm: Mandatory in RVA20U64, RVA22U64, RVA23U64
> >>
> >> I did not verify your statements about where these are
> >> optional and mandatory, but I assume they're correct.
> >
> > Yes they are correct. As far as what stated in the two profile documents.
> >
> >>
> >>> Since Ziccamoa depends on the 'A' extension, add a schema check to
> >>> enforce this dependency.
> >>
> >> All of these extensions are related to atomic operations, right?
> >> Don't *all* of them (not just Ziccamoa) depend on the A extension?
> >
> >
> > Za64rs and Zicclsm: no, they are not 'A'. They are cache related.
>
> Isn't a Za64rs reservation set related to atomic operations,
> though?  They are related to load-reserved/store conditional
> instructions, which are introduced in the atomic instructions
> section.

Yes, you are right. Let me update the relationship:
Za64rs defines a hard's reservation set implementation detail.

It is consumed by two extensions: Zalrsc and Zawrs.

Za64rs -> Zalrsc -> A
Za64rs -> Zawrs -> Zalrsc -> A

I would say maybe all these relationships deserve to be validated in
cpufeature.c (so far, they are not.)

BR,
Guodong Xu

>
> I was mistaken about Zicclsm, that's related to unaligned
> accesses, but does not apply to atomic operations.
>
> > Ziccrse and Ziccamoa: yes, they are 'A' related.
> >
> > Ziccrse specifies the main memory must support "RsrvEventual", which is one
> > (totally there are four) of the support level for Load-Reserved/
> > Store-Conditional (LR/SC) atomic instructions.
> >
> > And in RVA profiles, two named features (exts) are added:
> > Ziccrse: which further define the level of LR/SC operations being supported.
> > Ziccamoa: which further define the level of AMOs instructions being supported.
> >
> >
> > We already know that "A" = Zaamo + Zalrsc;
> >
> > In summary, the dependencies among these extensions are:
> > Ziccrse -> Zalrsc -> A;
> > Ziccamoa -> Zaamo -> A;
> >
> >> Furthermore, the A extension is already mandated by RVA23U64, so
> >> is it really necessary to add this logic?
> >
> > Hi, Conor
> >
> > What do you think? I am kind of agree with Alex to remove the schema
> > checking logic.
> >
> > Leaving the dependency check to riscv/cpufeature.c, let the .validate call
> > do the job. If you agree, I can remove the schema checking logic on Ziccamoa
> > and A in my next version.
>
> Yes I think this is a better way to handle it.  Conor?
>
> > Btw, cpufeature.c validate() deserves another patch/patchset.
> > I'll be happy to add that if we reach a consensus here.
>
> Yes I think you should do this once there is concensus.
>
>
>
> >
> >>
> >>
> >>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> >>> ---
> >>> v2: New patch.
> >>> ---
> >>>    .../devicetree/bindings/riscv/extensions.yaml      | 34 ++++++++++++++++++++++
> >>>    1 file changed, 34 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> >>> index 385e1deb23996d294e7662693f1257f910a6e129..a6b9d7e3edf86ecfb117ba72e295ef097bdc9831 100644
> >>> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> >>> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> >>> @@ -237,6 +237,12 @@ properties:
> >>>                as ratified at commit 4a69197e5617 ("Update to ratified state") of
> >>>                riscv-svvptc.
> >>>
> >>> +        - const: za64rs
> >>> +          description:
> >>> +            The standard Za64rs extension for reservation set size of at most
> >>> +            64 bytes, as ratified in RISC-V Profiles Version 1.0, with commit
> >>> +            b1d806605f87 ("Updated to ratified state.")
> >>
> >> The more complete description says:
> >>
> >>       Reservation sets are contiguous, naturally aligned, and a maximum
> >>       of 64 bytes.
> >>
> >> But as I read on (below) I suppose using the more succinct description
> >> from the glossary might be best, forcing people who care to go look
> >
> > That is exactly what I am doing.
> >
> >> at the reference documents.
> >>
> >>> +
> >>>            - const: zaamo
> >>>              description: |
> >>>                The standard Zaamo extension for atomic memory operations as
> >>> @@ -378,6 +384,27 @@ properties:
> >>>                in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
> >>>                riscv-isa-manual.
> >>>
> >>> +        - const: ziccamoa
> >>> +          description:
> >>> +            The standard Ziccamoa extension for main memory (cacheability and
> >>> +            coherence) must support all atomics in A, as ratified in RISC-V
> >>> +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
> >>> +            ratified state.")
> >>
> >> Similar comment here (but also with a similar caveat):
> >>
> >
> > I am using what the RVA23 Profile defines:
> > "Ziccamoa: Main memory supports all atomics in A"
> >
> > I prefer to keep it as is.
>
> That's fine.  I don't think I felt strongly about any of the things
> I said about the exact wording used here.
>
> Thanks.
>
>                                         -Alex
>
> > BR,
> > Guodong
> >
> >>     Main memory regions with both the cacheability and coherence PMAs
> >>     must support all atomics in A.
> >>
> >> And I might say "the A extension", but maybe that's a bad idea.
> >>
> >>> +
> >>> +        - const: ziccif
> >>> +          description:
> >>> +            The standard Ziccif extension for main memory (cacheability and
> >>> +            coherence) instruction fetch atomicity, as ratified in RISC-V
> >>> +            Profiles Version 1.0, with commit b1d806605f87 ("Updated to
> >>> +            ratified state.")
> >>> +
> >>> +        - const: zicclsm
> >>> +          description:
> >>> +            The standard Zicclsm extension for main memory (cacheability and
> >>> +            coherence) must support misaligned loads and stores, as ratified
> >>> +            in RISC-V Profiles Version 1.0, with commit b1d806605f87 ("Updated
> >>> +            to ratified state.")
> >>> +
> >>>            - const: ziccrse
> >>>              description:
> >>>                The standard Ziccrse extension which provides forward progress
> >>> @@ -795,6 +822,13 @@ properties:
> >>>            then:
> >>>              contains:
> >>>                const: f
> >>> +      # Ziccamoa depends on A
> >>
> >> Maybe more than just depends on the A extension.
> >>
> >>                                          -Alex
> >>
> >>> +      - if:
> >>> +          contains:
> >>> +            const: ziccamoa
> >>> +        then:
> >>> +          contains:
> >>> +            const: a
> >>>          # Zvfbfmin depends on V or Zve32f
> >>>          - if:
> >>>              contains:
> >>>
> >>
>

Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Rob Herring]

On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
> On 12/22/25 7:04 AM, Guodong Xu wrote:
> > Add description for the Supm extension. Supm indicates support for pointer
> > masking in user mode. Supm is mandatory for RVA23S64.
> > 
> > The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> > state") of riscv-j-extension.
> > 
> > Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> > this dependency.
> 
> I have the same general question on this, about whether it's really
> necessary for the DT binding to enforce these requirements.  The
> RISC-V specifications are what truly defines their meaning, so I
> don't really see why the DT framework should need to enforce them.
> (That said, I'm sure there are other cases where DT enforces things
> it shouldn't have to.)

Does the specification have some way to check it? What happens if a DT 
is wrong? Are you going to require a DT update to make things right? Or 
the kernel has to work-around the error? Neither is great. So having 
this as a schema makes sense to prevent either scenario.

> 
> And now, having looked at these added binding definitions (in patches
> 07 through 11 in this series), I wonder what exactly is required for
> them to be accepted.  For the most part these seem to just be defining
> how the extensions specified for RISC-V are to be expressed in
> DT files.  It seems to be a fairly straightforward copy from the
> ratified specification(s) to the YAML format.
> 
> Who need to sign off on it?  Conor?  Paul?  DT maintainers?

I generally leave this extension mess to Conor.

Rob

Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Alex Elder]

On 12/29/25 8:13 PM, Rob Herring wrote:
> On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
>> On 12/22/25 7:04 AM, Guodong Xu wrote:
>>> Add description for the Supm extension. Supm indicates support for pointer
>>> masking in user mode. Supm is mandatory for RVA23S64.
>>>
>>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
>>> state") of riscv-j-extension.
>>>
>>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
>>> this dependency.
>>
>> I have the same general question on this, about whether it's really
>> necessary for the DT binding to enforce these requirements.  The
>> RISC-V specifications are what truly defines their meaning, so I
>> don't really see why the DT framework should need to enforce them.
>> (That said, I'm sure there are other cases where DT enforces things
>> it shouldn't have to.)
> 
> Does the specification have some way to check it? What happens if a DT
> is wrong? Are you going to require a DT update to make things right? Or
> the kernel has to work-around the error? Neither is great. So having
> this as a schema makes sense to prevent either scenario.

I'm really glad you weighed in.  I actually have several questions
related to RISC-V extensions and DT.  But for now I'll focus on
just this...

To answer your first question, I'm not sure how the specification
is "checked", or what "it" is that you're asking about for that
matter.  Also I think we have to be clear about what "wrong" means.

RISC-V is defined by a (large and growing) set of specifications
that are developed through a well-defined process.  When a spec
is *ratified* it is committed, and it won't be changed.  These
specifications are ultimately *the* definition of RISC-V
compliance.

I assumed the "wrong" you're talking about is a DTS/DTB that has
been committed but somehow does not match what a RISC-V spec
says, but I might be mistaken.

Anyway, we can flip that around and have a similar problem:  What
if we define the DT binding in such a way that it doesn't match
the RISC-V spec?  The (ratified) RISC-V spec is right.

My thought was that we should have software do the verification,
and recommend the software (e.g. arch/riscv/kernel/cpufeature.c
in Linux) be updated to verify things before committing to a
DT binding.

To me, C code is more general and more universally understandable
than YAML rules, but I'm biased by how well I work with C versus
YAML schemas.

In any case, a "wrong" binding is a problem no matter what the
reason.  One way or another there are things expressed via DT
that must match the RISC-V specifications.  And yes, we do have
tools and bindings that can verify things related to DT.

>> And now, having looked at these added binding definitions (in patches
>> 07 through 11 in this series), I wonder what exactly is required for
>> them to be accepted.  For the most part these seem to just be defining
>> how the extensions specified for RISC-V are to be expressed in
>> DT files.  It seems to be a fairly straightforward copy from the
>> ratified specification(s) to the YAML format.
>>
>> Who need to sign off on it?  Conor?  Paul?  DT maintainers?
> 
> I generally leave this extension mess to Conor.

Sounds wise.  Should I address my other few questions on this
topic to Conor?  I don't want this particular series to get
held up on unrelated discussions.

					-Alex

> Rob

Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Rob Herring]

On Mon, Dec 29, 2025 at 9:14 PM Alex Elder <elder@riscstar.com> wrote:
>
> On 12/29/25 8:13 PM, Rob Herring wrote:
> > On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
> >> On 12/22/25 7:04 AM, Guodong Xu wrote:
> >>> Add description for the Supm extension. Supm indicates support for pointer
> >>> masking in user mode. Supm is mandatory for RVA23S64.
> >>>
> >>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> >>> state") of riscv-j-extension.
> >>>
> >>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> >>> this dependency.
> >>
> >> I have the same general question on this, about whether it's really
> >> necessary for the DT binding to enforce these requirements.  The
> >> RISC-V specifications are what truly defines their meaning, so I
> >> don't really see why the DT framework should need to enforce them.
> >> (That said, I'm sure there are other cases where DT enforces things
> >> it shouldn't have to.)
> >
> > Does the specification have some way to check it? What happens if a DT
> > is wrong? Are you going to require a DT update to make things right? Or
> > the kernel has to work-around the error? Neither is great. So having
> > this as a schema makes sense to prevent either scenario.
>
> I'm really glad you weighed in.  I actually have several questions
> related to RISC-V extensions and DT.  But for now I'll focus on
> just this...
>
> To answer your first question, I'm not sure how the specification
> is "checked", or what "it" is that you're asking about for that
> matter.  Also I think we have to be clear about what "wrong" means.
>
> RISC-V is defined by a (large and growing) set of specifications
> that are developed through a well-defined process.  When a spec
> is *ratified* it is committed, and it won't be changed.  These
> specifications are ultimately *the* definition of RISC-V
> compliance.
>
> I assumed the "wrong" you're talking about is a DTS/DTB that has
> been committed but somehow does not match what a RISC-V spec
> says, but I might be mistaken.

That's correct.

> Anyway, we can flip that around and have a similar problem:  What
> if we define the DT binding in such a way that it doesn't match
> the RISC-V spec?  The (ratified) RISC-V spec is right.

Sure. Any time there is more than 1 source of truth, they could be
mismatched. But it is 1 spec and 1 schema to compare, not N DTS files.
Checking the schema matches the spec is much easier than reviewing
every new DTS file.

The only true fix is to make the spec machine readable.

> My thought was that we should have software do the verification,
> and recommend the software (e.g. arch/riscv/kernel/cpufeature.c
> in Linux) be updated to verify things before committing to a
> DT binding.

That moves validation from build time to run time. How is that better?
And what about other OSs?

I'm very much of the opinion that it is not the kernel's job to
validate the DT. It obviously has not done a very good job given
issues we find with schemas. It's fine to have some checks in this
case if the kernel can't function (or use/enable the extension)
without the dependent extensions, but there are lots of classes of
errors the kernel doesn't need to care about.

> To me, C code is more general and more universally understandable
> than YAML rules, but I'm biased by how well I work with C versus
> YAML schemas.

Personally, if I was going to do validation with code, I would pick
python or any language that can handle lists and dicts natively. I too
would prefer C for everything, but it's not the best tool for the job
here. Even if we decided to do validation in C (I'm pretty sure we had
a proposal to do just that at some point), we'd just end up defining
our own data structures of validation data. Because at the end of the
day, most of the validation information is all the same structure of
data (i.e. a list of properties with lists of allowed values). I'd
much rather follow some standard (json-schema) that's already
documented than try to come up with my own poorly documented
invention.

I do think there is some need for code based validation as there are
some things which can't be expressed with schemas. We have some of
that in dtc, but that only works for core bindings. Some sort of
python snippets of code in schemas is kind of what I'm thinking.

> In any case, a "wrong" binding is a problem no matter what the
> reason.  One way or another there are things expressed via DT
> that must match the RISC-V specifications.  And yes, we do have
> tools and bindings that can verify things related to DT.
>
> >> And now, having looked at these added binding definitions (in patches
> >> 07 through 11 in this series), I wonder what exactly is required for
> >> them to be accepted.  For the most part these seem to just be defining
> >> how the extensions specified for RISC-V are to be expressed in
> >> DT files.  It seems to be a fairly straightforward copy from the
> >> ratified specification(s) to the YAML format.
> >>
> >> Who need to sign off on it?  Conor?  Paul?  DT maintainers?
> >
> > I generally leave this extension mess to Conor.
>
> Sounds wise.  Should I address my other few questions on this
> topic to Conor?  I don't want this particular series to get
> held up on unrelated discussions.

Probably so.

Rob

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 4579 bytes --]

On Fri, Dec 26, 2025 at 03:28:25PM -0600, Alex Elder wrote:
> On 12/23/25 12:51 AM, Guodong Xu wrote:
> > Hi, Conor
> > 
> > On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.org> wrote:
> > > 
> > > On Mon, Dec 22, 2025 at 09:04:17PM +0800, Guodong Xu wrote:
> > > > Add description of the single-letter "B" extennsion for Bit Manipulation.
> > > > B is mandatory for RVA23U64.
> > > > 
> > > > The B extension is ratified in the 20240411 version of the unprivileged
> > > > ISA specification. According to the ratified spec, "the B standard
> > > > extension comprises instructions provided by the Zba, Zbb, and Zbs
> > > > extensions.
> > > > 
> > > > Hence add a schema check rule to enforce that B implies Zba, Zbb and Zbs.
> > > > 
> > > > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > > > ---
> > > > v2: New patch.
> > > > ---
> > > >   .../devicetree/bindings/riscv/extensions.yaml         | 19 +++++++++++++++++++
> > > >   1 file changed, 19 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > > > index 565cb2cbb49b552959392810a9b731b43346a594..385e1deb23996d294e7662693f1257f910a6e129 100644
> > > > --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> > > > +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > > > @@ -109,6 +109,13 @@ properties:
> > > >               The standard C extension for compressed instructions, as ratified in
> > > >               the 20191213 version of the unprivileged ISA specification.
> > > > 
> > > > +        - const: b
> > > > +          description:
> > > > +            The standard B extension for bit manipulation instructions, as
> > > > +            ratified in the 20240411 version of the unprivileged ISA
> > > > +            specification. The B standard extension comprises instructions
> > > > +            provided by the Zba, Zbb, and Zbs extensions.
> > > > +
> > > >           - const: v
> > > >             description:
> > > >               The standard V extension for vector operations, as ratified
> > > > @@ -735,6 +742,18 @@ properties:
> > > >           then:
> > > >             contains:
> > > >               const: f
> > > > +      # b comprises the following extensions
> > > > +      - if:
> > > > +          contains:
> > > > +            const: b
> > > 
> > > What's the value in adding b, if it depends on having all 3 of the
> > > components defined individually too? Currently all "superset" types of
> > > extensions are permitted without their component parts also being defined,
> > > this doesn't follow convention and therefore needs to be explained.
> > > 
> > > You obviously need this construct because the kernel does not understand
> > > "b", and even if you added support for interpreting "b" to the kernel
> > > this is probably still needed to make sure the ABI is maintained for
> > > anything importing a devicetree from the kernel.
> > 
> > Yes, exactly. Unlike other single-letter extensions, "b" was ratified
> > (Apr/2024) much later than its components zba/zbb/zbs (Jun/2021).
> > Existing software and the kernel already expect these explicit component
> > strings, so enforcing this dependency ensures cores declaring "b" will
> > also be correctly understood by older software that only looks for
> > zba/zbb/zbs.
> 
> I might be misunderstanding you, but I don't think extension "b"
> should *require* the other three extensions.  Instead, the "b"
> extension should be considered *equivalent* to the other three.
> That's what I understand it to mean, anyway.
>   https://github.com/riscv/riscv-b
> 
> There's no point in supporting "b" in devicetree to represent
> the others if it also requires the others to be present.

The dependency can be go both ways, to also make specifying "b" mandatory
when the three components are. That probably produces the most helpful
devicetree ultimately.

> I think that, instead, "b", "zba", "zbb", and "zbs" should all
> be allowed.

> I might even go further and harden the requirement, saying that
> if you specify "b" you should *not* specify "zba", "zbb", or "zbs".
> But that might not be normal practice, and it's not necessary
> because they aren't in conflict.

I disagree completely with this "even further", since that's potentially
actively harmful to importers of kernel devicetrees.
If "b" is to be allowed, I'm only in favour if having it requires the
component parts.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]

On Mon, Dec 29, 2025 at 08:13:06PM -0600, Rob Herring wrote:
> On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
> > On 12/22/25 7:04 AM, Guodong Xu wrote:
> > > Add description for the Supm extension. Supm indicates support for pointer
> > > masking in user mode. Supm is mandatory for RVA23S64.
> > > 
> > > The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> > > state") of riscv-j-extension.
> > > 
> > > Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> > > this dependency.
> > 
> > I have the same general question on this, about whether it's really
> > necessary for the DT binding to enforce these requirements.  The
> > RISC-V specifications are what truly defines their meaning, so I
> > don't really see why the DT framework should need to enforce them.
> > (That said, I'm sure there are other cases where DT enforces things
> > it shouldn't have to.)
> 
> Does the specification have some way to check it? What happens if a DT 
> is wrong? Are you going to require a DT update to make things right? Or 
> the kernel has to work-around the error? Neither is great. So having 
> this as a schema makes sense to prevent either scenario.

The reason this whole mess exists is because extensions got redefined
after the kernel port was merged and the bindings defined. This is
almost all a hedge against there being future redefinitions. For now,
and hopefully forever, this will just be a list of extensions with
citations to their relevant documentation so that we can say "this is
exactly what this means". The added bonus is avoiding messes like people
implementing development versions of specs and claiming support, because
that just becomes "your devicetree is wrong".

The dependency stuff exists because it is far too easy to miss something
in a list of 30+ extensions and dt validation can reduce some of the
complexity required when checking what extensions are supported.

> > And now, having looked at these added binding definitions (in patches
> > 07 through 11 in this series), I wonder what exactly is required for
> > them to be accepted.  For the most part these seem to just be defining
> > how the extensions specified for RISC-V are to be expressed in
> > DT files.  It seems to be a fairly straightforward copy from the
> > ratified specification(s) to the YAML format.
> > 
> > Who need to sign off on it?  Conor?  Paul?  DT maintainers?
> 
> I generally leave this extension mess to Conor.

And generally I do without that much back and forth, just so happens
that a couple of the ones in this series are the less simple cases to
deal with.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Alex Elder]

On 12/30/25 11:09 AM, Conor Dooley wrote:
> On Fri, Dec 26, 2025 at 03:28:25PM -0600, Alex Elder wrote:
>> On 12/23/25 12:51 AM, Guodong Xu wrote:
>>> Hi, Conor
>>>
>>> On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.org> wrote:
>>>>
>>>> On Mon, Dec 22, 2025 at 09:04:17PM +0800, Guodong Xu wrote:
>>>>> Add description of the single-letter "B" extennsion for Bit Manipulation.
>>>>> B is mandatory for RVA23U64.
>>>>>
>>>>> The B extension is ratified in the 20240411 version of the unprivileged
>>>>> ISA specification. According to the ratified spec, "the B standard
>>>>> extension comprises instructions provided by the Zba, Zbb, and Zbs
>>>>> extensions.
>>>>>
>>>>> Hence add a schema check rule to enforce that B implies Zba, Zbb and Zbs.
>>>>>
>>>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>>>> ---
>>>>> v2: New patch.
>>>>> ---
>>>>>    .../devicetree/bindings/riscv/extensions.yaml         | 19 +++++++++++++++++++
>>>>>    1 file changed, 19 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>>>> index 565cb2cbb49b552959392810a9b731b43346a594..385e1deb23996d294e7662693f1257f910a6e129 100644
>>>>> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
>>>>> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>>>> @@ -109,6 +109,13 @@ properties:
>>>>>                The standard C extension for compressed instructions, as ratified in
>>>>>                the 20191213 version of the unprivileged ISA specification.
>>>>>
>>>>> +        - const: b
>>>>> +          description:
>>>>> +            The standard B extension for bit manipulation instructions, as
>>>>> +            ratified in the 20240411 version of the unprivileged ISA
>>>>> +            specification. The B standard extension comprises instructions
>>>>> +            provided by the Zba, Zbb, and Zbs extensions.
>>>>> +
>>>>>            - const: v
>>>>>              description:
>>>>>                The standard V extension for vector operations, as ratified
>>>>> @@ -735,6 +742,18 @@ properties:
>>>>>            then:
>>>>>              contains:
>>>>>                const: f
>>>>> +      # b comprises the following extensions
>>>>> +      - if:
>>>>> +          contains:
>>>>> +            const: b
>>>>
>>>> What's the value in adding b, if it depends on having all 3 of the
>>>> components defined individually too? Currently all "superset" types of
>>>> extensions are permitted without their component parts also being defined,
>>>> this doesn't follow convention and therefore needs to be explained.
>>>>
>>>> You obviously need this construct because the kernel does not understand
>>>> "b", and even if you added support for interpreting "b" to the kernel
>>>> this is probably still needed to make sure the ABI is maintained for
>>>> anything importing a devicetree from the kernel.
>>>
>>> Yes, exactly. Unlike other single-letter extensions, "b" was ratified
>>> (Apr/2024) much later than its components zba/zbb/zbs (Jun/2021).
>>> Existing software and the kernel already expect these explicit component
>>> strings, so enforcing this dependency ensures cores declaring "b" will
>>> also be correctly understood by older software that only looks for
>>> zba/zbb/zbs.
>>
>> I might be misunderstanding you, but I don't think extension "b"
>> should *require* the other three extensions.  Instead, the "b"
>> extension should be considered *equivalent* to the other three.
>> That's what I understand it to mean, anyway.
>>    https://github.com/riscv/riscv-b
>>
>> There's no point in supporting "b" in devicetree to represent
>> the others if it also requires the others to be present.
> 
> The dependency can be go both ways, to also make specifying "b" mandatory
> when the three components are. That probably produces the most helpful
> devicetree ultimately.

What about DT files that specified zba+zbb+zbs before "b" was
ratified?

>> I think that, instead, "b", "zba", "zbb", and "zbs" should all
>> be allowed.
> 
>> I might even go further and harden the requirement, saying that
>> if you specify "b" you should *not* specify "zba", "zbb", or "zbs".
>> But that might not be normal practice, and it's not necessary
>> because they aren't in conflict.
> 
> I disagree completely with this "even further", since that's potentially
> actively harmful to importers of kernel devicetrees.

This is related to one of the things I mentioned to Rob that I
wanted to discuss.

This type of "equivalent" extension is problematic for DT, or I
guess, it doesn't really add any value.  I'm sure the people
ratifying "b" to be equivalent to "zba+zbb+zbs" intend for it
to simplify how the supported extensions are represented.

But it actually complicates things for DT.  If you're going
to support just "b" (which would be simpler and more concise)
then there needs to be logic that treats the two possibilities
as equivalent.  But old software won't recognize new DT files
that contain only the newer (e.g. "b") extension.

So I agree, there's active harm in doing what I suggested.

But why even bother supporting "b" if you have to *also*
support "zba+zbb+zbs" if you use it?  It adds the possibility
of new errors ("b" without "zbs", for example), while not
really enabling or representing anything new.

> If "b" is to be allowed, I'm only in favour if having it requires the
> component parts.

I'd opt for ignoring the "b" extension, and any other
"simplified" extensions that simply represent a specific
set of other extensions and nothing more.  At least for DT.

That said, this "rule" would have to be followed/agreed to
by all users of DT.

					-Alex

Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 4427 bytes --]

On Tue, Dec 30, 2025 at 09:21:56AM -0600, Rob Herring wrote:
> On Mon, Dec 29, 2025 at 9:14 PM Alex Elder <elder@riscstar.com> wrote:
> >
> > On 12/29/25 8:13 PM, Rob Herring wrote:
> > > On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
> > >> On 12/22/25 7:04 AM, Guodong Xu wrote:
> > >>> Add description for the Supm extension. Supm indicates support for pointer
> > >>> masking in user mode. Supm is mandatory for RVA23S64.
> > >>>
> > >>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> > >>> state") of riscv-j-extension.
> > >>>
> > >>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> > >>> this dependency.
> > >>
> > >> I have the same general question on this, about whether it's really
> > >> necessary for the DT binding to enforce these requirements.  The
> > >> RISC-V specifications are what truly defines their meaning, so I
> > >> don't really see why the DT framework should need to enforce them.
> > >> (That said, I'm sure there are other cases where DT enforces things
> > >> it shouldn't have to.)
> > >
> > > Does the specification have some way to check it? What happens if a DT
> > > is wrong? Are you going to require a DT update to make things right? Or
> > > the kernel has to work-around the error? Neither is great. So having
> > > this as a schema makes sense to prevent either scenario.
> >
> > I'm really glad you weighed in.  I actually have several questions
> > related to RISC-V extensions and DT.  But for now I'll focus on
> > just this...
> >
> > To answer your first question, I'm not sure how the specification
> > is "checked", or what "it" is that you're asking about for that
> > matter.  Also I think we have to be clear about what "wrong" means.
> >
> > RISC-V is defined by a (large and growing) set of specifications
> > that are developed through a well-defined process.  When a spec
> > is *ratified* it is committed, and it won't be changed.  These
> > specifications are ultimately *the* definition of RISC-V
> > compliance.
> >
> > I assumed the "wrong" you're talking about is a DTS/DTB that has
> > been committed but somehow does not match what a RISC-V spec
> > says, but I might be mistaken.
> 
> That's correct.
> 
> > Anyway, we can flip that around and have a similar problem:  What
> > if we define the DT binding in such a way that it doesn't match
> > the RISC-V spec?  The (ratified) RISC-V spec is right.
> 
> Sure. Any time there is more than 1 source of truth, they could be
> mismatched. But it is 1 spec and 1 schema to compare, not N DTS files.
> Checking the schema matches the spec is much easier than reviewing
> every new DTS file.

The objective is not to define things with divergent meanings anyway,
only to say "this string is exactly this version of this extension",
so that if some other version of an extension comes along we have a way
to differentiate. We didn't before and that became problematic for both
standard extensions and vendor specific stuff. You'll note we don't look
to define anything ourselves, just cite the spec that provides the
definitions.

> The only true fix is to make the spec machine readable.
> 
> > My thought was that we should have software do the verification,
> > and recommend the software (e.g. arch/riscv/kernel/cpufeature.c
> > in Linux) be updated to verify things before committing to a
> > DT binding.
> 
> That moves validation from build time to run time. How is that better?
> And what about other OSs?
> 
> I'm very much of the opinion that it is not the kernel's job to
> validate the DT. It obviously has not done a very good job given
> issues we find with schemas. It's fine to have some checks in this
> case if the kernel can't function (or use/enable the extension)
> without the dependent extensions, but there are lots of classes of
> errors the kernel doesn't need to care about.

By and large what's in cpufeature.c is there to turn extensions off
based on kconfig choices (vector support enabled etc) or kernel design
decisions (kernel requiring both d and f extensions for fpu support). I
don't think there's anything there that doesn't assume that the
devicetree is correct. For my money, it's much simpler to describe
dependencies in a binding than add more code to the kernel that tries to
figure out dependencies at runtime.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 6476 bytes --]

On Tue, Dec 30, 2025 at 11:29:14AM -0600, Alex Elder wrote:
> On 12/30/25 11:09 AM, Conor Dooley wrote:
> > On Fri, Dec 26, 2025 at 03:28:25PM -0600, Alex Elder wrote:
> > > On 12/23/25 12:51 AM, Guodong Xu wrote:
> > > > Hi, Conor
> > > > 
> > > > On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.org> wrote:
> > > > > 
> > > > > On Mon, Dec 22, 2025 at 09:04:17PM +0800, Guodong Xu wrote:
> > > > > > Add description of the single-letter "B" extennsion for Bit Manipulation.
> > > > > > B is mandatory for RVA23U64.
> > > > > > 
> > > > > > The B extension is ratified in the 20240411 version of the unprivileged
> > > > > > ISA specification. According to the ratified spec, "the B standard
> > > > > > extension comprises instructions provided by the Zba, Zbb, and Zbs
> > > > > > extensions.
> > > > > > 
> > > > > > Hence add a schema check rule to enforce that B implies Zba, Zbb and Zbs.
> > > > > > 
> > > > > > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > > > > > ---
> > > > > > v2: New patch.
> > > > > > ---
> > > > > >    .../devicetree/bindings/riscv/extensions.yaml         | 19 +++++++++++++++++++
> > > > > >    1 file changed, 19 insertions(+)
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > > > > > index 565cb2cbb49b552959392810a9b731b43346a594..385e1deb23996d294e7662693f1257f910a6e129 100644
> > > > > > --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> > > > > > @@ -109,6 +109,13 @@ properties:
> > > > > >                The standard C extension for compressed instructions, as ratified in
> > > > > >                the 20191213 version of the unprivileged ISA specification.
> > > > > > 
> > > > > > +        - const: b
> > > > > > +          description:
> > > > > > +            The standard B extension for bit manipulation instructions, as
> > > > > > +            ratified in the 20240411 version of the unprivileged ISA
> > > > > > +            specification. The B standard extension comprises instructions
> > > > > > +            provided by the Zba, Zbb, and Zbs extensions.
> > > > > > +
> > > > > >            - const: v
> > > > > >              description:
> > > > > >                The standard V extension for vector operations, as ratified
> > > > > > @@ -735,6 +742,18 @@ properties:
> > > > > >            then:
> > > > > >              contains:
> > > > > >                const: f
> > > > > > +      # b comprises the following extensions
> > > > > > +      - if:
> > > > > > +          contains:
> > > > > > +            const: b
> > > > > 
> > > > > What's the value in adding b, if it depends on having all 3 of the
> > > > > components defined individually too? Currently all "superset" types of
> > > > > extensions are permitted without their component parts also being defined,
> > > > > this doesn't follow convention and therefore needs to be explained.
> > > > > 
> > > > > You obviously need this construct because the kernel does not understand
> > > > > "b", and even if you added support for interpreting "b" to the kernel
> > > > > this is probably still needed to make sure the ABI is maintained for
> > > > > anything importing a devicetree from the kernel.
> > > > 
> > > > Yes, exactly. Unlike other single-letter extensions, "b" was ratified
> > > > (Apr/2024) much later than its components zba/zbb/zbs (Jun/2021).
> > > > Existing software and the kernel already expect these explicit component
> > > > strings, so enforcing this dependency ensures cores declaring "b" will
> > > > also be correctly understood by older software that only looks for
> > > > zba/zbb/zbs.
> > > 
> > > I might be misunderstanding you, but I don't think extension "b"
> > > should *require* the other three extensions.  Instead, the "b"
> > > extension should be considered *equivalent* to the other three.
> > > That's what I understand it to mean, anyway.
> > >    https://github.com/riscv/riscv-b
> > > 
> > > There's no point in supporting "b" in devicetree to represent
> > > the others if it also requires the others to be present.
> > 
> > The dependency can be go both ways, to also make specifying "b" mandatory
> > when the three components are. That probably produces the most helpful
> > devicetree ultimately.
> 
> What about DT files that specified zba+zbb+zbs before "b" was
> ratified?

They'd generate a warning, which can then be fixed. That's fine to do, a
warning in linux-next doesn't harm anyone. Updating devicetrees in ways
that don't change their meaning but provide extra value is not a problem
in my book.

> > > I think that, instead, "b", "zba", "zbb", and "zbs" should all
> > > be allowed.
> > 
> > > I might even go further and harden the requirement, saying that
> > > if you specify "b" you should *not* specify "zba", "zbb", or "zbs".
> > > But that might not be normal practice, and it's not necessary
> > > because they aren't in conflict.
> > 
> > I disagree completely with this "even further", since that's potentially
> > actively harmful to importers of kernel devicetrees.
> 
> This is related to one of the things I mentioned to Rob that I
> wanted to discuss.
> 
> This type of "equivalent" extension is problematic for DT, or I
> guess, it doesn't really add any value.  I'm sure the people
> ratifying "b" to be equivalent to "zba+zbb+zbs" intend for it
> to simplify how the supported extensions are represented.
> 
> But it actually complicates things for DT.  If you're going
> to support just "b" (which would be simpler and more concise)
> then there needs to be logic that treats the two possibilities
> as equivalent.  But old software won't recognize new DT files
> that contain only the newer (e.g. "b") extension.
> 
> So I agree, there's active harm in doing what I suggested.

> But why even bother supporting "b" if you have to *also*
> support "zba+zbb+zbs" if you use it?  It adds the possibility
> of new errors ("b" without "zbs", for example), while not
> really enabling or representing anything new.

That was my first question after all! Ultimately I'd really err on the
side of adding it because people will expect to be able to use it and
because, in terms of kernel support, it will be useful for ACPI systems.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Alex Elder]

On 12/30/25 9:21 AM, Rob Herring wrote:
> On Mon, Dec 29, 2025 at 9:14 PM Alex Elder <elder@riscstar.com> wrote:
>>
>> On 12/29/25 8:13 PM, Rob Herring wrote:
>>> On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
>>>> On 12/22/25 7:04 AM, Guodong Xu wrote:
>>>>> Add description for the Supm extension. Supm indicates support for pointer
>>>>> masking in user mode. Supm is mandatory for RVA23S64.
>>>>>
>>>>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
>>>>> state") of riscv-j-extension.
>>>>>
>>>>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
>>>>> this dependency.
>>>>
>>>> I have the same general question on this, about whether it's really
>>>> necessary for the DT binding to enforce these requirements.  The
>>>> RISC-V specifications are what truly defines their meaning, so I
>>>> don't really see why the DT framework should need to enforce them.
>>>> (That said, I'm sure there are other cases where DT enforces things
>>>> it shouldn't have to.)
>>>
>>> Does the specification have some way to check it? What happens if a DT
>>> is wrong? Are you going to require a DT update to make things right? Or
>>> the kernel has to work-around the error? Neither is great. So having
>>> this as a schema makes sense to prevent either scenario.
>>
>> I'm really glad you weighed in.  I actually have several questions
>> related to RISC-V extensions and DT.  But for now I'll focus on
>> just this...
>>
>> To answer your first question, I'm not sure how the specification
>> is "checked", or what "it" is that you're asking about for that
>> matter.  Also I think we have to be clear about what "wrong" means.
>>
>> RISC-V is defined by a (large and growing) set of specifications
>> that are developed through a well-defined process.  When a spec
>> is *ratified* it is committed, and it won't be changed.  These
>> specifications are ultimately *the* definition of RISC-V
>> compliance.
>>
>> I assumed the "wrong" you're talking about is a DTS/DTB that has
>> been committed but somehow does not match what a RISC-V spec
>> says, but I might be mistaken.
> 
> That's correct.
> 
>> Anyway, we can flip that around and have a similar problem:  What
>> if we define the DT binding in such a way that it doesn't match
>> the RISC-V spec?  The (ratified) RISC-V spec is right.
> 
> Sure. Any time there is more than 1 source of truth, they could be
> mismatched. But it is 1 spec and 1 schema to compare, not N DTS files.
> Checking the schema matches the spec is much easier than reviewing
> every new DTS file.

Yes, I understand that and I agree.  We *do* have tools to
verify DT files against bindings, and at least in this
domain we don't have tools to verify against the RISC-V
specs.

> The only true fix is to make the spec machine readable.

But barring that, we can define the DT binding and try to
ensure it exactly matches the RISC-V specs.

>> My thought was that we should have software do the verification,
>> and recommend the software (e.g. arch/riscv/kernel/cpufeature.c
>> in Linux) be updated to verify things before committing to a
>> DT binding.
> 
> That moves validation from build time to run time. How is that better?
> And what about other OSs?

OK I concede that encoding the logic in the DT binding is
a good practical solution and I take back my suggestion.

> I'm very much of the opinion that it is not the kernel's job to
> validate the DT. It obviously has not done a very good job given

This is exactly what I wanted your opinion on.  I mean, I
already agreed with this statement, but the existence of a
different (RISC-V) spec as a source of truth made me consider
that maybe it wasn't DT's job to validate some things.

> issues we find with schemas. It's fine to have some checks in this
> case if the kernel can't function (or use/enable the extension)
> without the dependent extensions, but there are lots of classes of
> errors the kernel doesn't need to care about.
> 
>> To me, C code is more general and more universally understandable
>> than YAML rules, but I'm biased by how well I work with C versus
>> YAML schemas.
> 
> Personally, if I was going to do validation with code, I would pick
> python or any language that can handle lists and dicts natively. I too
> would prefer C for everything, but it's not the best tool for the job

My point was about DT binding logic versus kernel code logic.  But
yes I agree with what you're saying here.

> here. Even if we decided to do validation in C (I'm pretty sure we had
> a proposal to do just that at some point), we'd just end up defining
> our own data structures of validation data. Because at the end of the
> day, most of the validation information is all the same structure of
> data (i.e. a list of properties with lists of allowed values). I'd
> much rather follow some standard (json-schema) that's already
> documented than try to come up with my own poorly documented
> invention.
> 
> I do think there is some need for code based validation as there are
> some things which can't be expressed with schemas. We have some of
> that in dtc, but that only works for core bindings. Some sort of
> python snippets of code in schemas is kind of what I'm thinking.

The main things I take away from this discussion:
- DT bindings *should* encode constraints for RISC-V extensions
   to enforce certain requirements from their underlying RISC-V
   specifications.
- The reason to do this is that the DT tools we have can help
   ensure correctness.  And doing it in the binding means it can
   get reviewed once, and the logic will apply to all DTS files
   that adhere to the binding.
- Doing some validation in the kernel is still useful, but anything
   done there needs to replicated in any other code bases that need
   to parse DT files.
- Conor owns this mess. :)

					-Alex

>> In any case, a "wrong" binding is a problem no matter what the
>> reason.  One way or another there are things expressed via DT
>> that must match the RISC-V specifications.  And yes, we do have
>> tools and bindings that can verify things related to DT.
>>
>>>> And now, having looked at these added binding definitions (in patches
>>>> 07 through 11 in this series), I wonder what exactly is required for
>>>> them to be accepted.  For the most part these seem to just be defining
>>>> how the extensions specified for RISC-V are to be expressed in
>>>> DT files.  It seems to be a fairly straightforward copy from the
>>>> ratified specification(s) to the YAML format.
>>>>
>>>> Who need to sign off on it?  Conor?  Paul?  DT maintainers?
>>>
>>> I generally leave this extension mess to Conor.
>>
>> Sounds wise.  Should I address my other few questions on this
>> topic to Conor?  I don't want this particular series to get
>> held up on unrelated discussions.
> 
> Probably so.
> 
> Rob

Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Alex Elder]

On 12/30/25 11:22 AM, Conor Dooley wrote:
> On Mon, Dec 29, 2025 at 08:13:06PM -0600, Rob Herring wrote:
>> On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
>>> On 12/22/25 7:04 AM, Guodong Xu wrote:
>>>> Add description for the Supm extension. Supm indicates support for pointer
>>>> masking in user mode. Supm is mandatory for RVA23S64.
>>>>
>>>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
>>>> state") of riscv-j-extension.
>>>>
>>>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
>>>> this dependency.
>>>
>>> I have the same general question on this, about whether it's really
>>> necessary for the DT binding to enforce these requirements.  The
>>> RISC-V specifications are what truly defines their meaning, so I
>>> don't really see why the DT framework should need to enforce them.
>>> (That said, I'm sure there are other cases where DT enforces things
>>> it shouldn't have to.)
>>
>> Does the specification have some way to check it? What happens if a DT
>> is wrong? Are you going to require a DT update to make things right? Or
>> the kernel has to work-around the error? Neither is great. So having
>> this as a schema makes sense to prevent either scenario.
> 
> The reason this whole mess exists is because extensions got redefined
> after the kernel port was merged and the bindings defined. This is

Redefined, or just new extensions defined?

Was support for any extensions added to the kernel before they were
ratified?  Even if so, did the meaning of the extension change
between when support was added to the kernel and ratification?

> almost all a hedge against there being future redefinitions. For now,
> and hopefully forever, this will just be a list of extensions with
> citations to their relevant documentation so that we can say "this is

Yes, this is good.  I think the bindings should, where possible,
just refer to the precise definitions in the (ratified) RISC-V
specifications.  But I now agree that they can also encode
logic to enforce things.

> exactly what this means". The added bonus is avoiding messes like people
> implementing development versions of specs and claiming support, because
> that just becomes "your devicetree is wrong".
> 
> The dependency stuff exists because it is far too easy to miss something
> in a list of 30+ extensions and dt validation can reduce some of the
> complexity required when checking what extensions are supported.

By "dependency stuff" do you just mean the DT binding logic?

Anyway I've come around to the idea that DT bindings actually
should do validation like this.

>>> And now, having looked at these added binding definitions (in patches
>>> 07 through 11 in this series), I wonder what exactly is required for
>>> them to be accepted.  For the most part these seem to just be defining
>>> how the extensions specified for RISC-V are to be expressed in
>>> DT files.  It seems to be a fairly straightforward copy from the
>>> ratified specification(s) to the YAML format.
>>>
>>> Who need to sign off on it?  Conor?  Paul?  DT maintainers?
>>
>> I generally leave this extension mess to Conor.
> 
> And generally I do without that much back and forth, just so happens
> that a couple of the ones in this series are the less simple cases to
> deal with.

Thanks.  I may have a remaining question or two for you but they aren't
that pressing.

					-Alex

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Alex Elder]

On 12/30/25 11:46 AM, Conor Dooley wrote:
> On Tue, Dec 30, 2025 at 11:29:14AM -0600, Alex Elder wrote:
>> On 12/30/25 11:09 AM, Conor Dooley wrote:
>>> On Fri, Dec 26, 2025 at 03:28:25PM -0600, Alex Elder wrote:
>>>> On 12/23/25 12:51 AM, Guodong Xu wrote:
>>>>> Hi, Conor
>>>>>
>>>>> On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.org> wrote:
>>>>>>
>>>>>> On Mon, Dec 22, 2025 at 09:04:17PM +0800, Guodong Xu wrote:
>>>>>>> Add description of the single-letter "B" extennsion for Bit Manipulation.
>>>>>>> B is mandatory for RVA23U64.
>>>>>>>
>>>>>>> The B extension is ratified in the 20240411 version of the unprivileged
>>>>>>> ISA specification. According to the ratified spec, "the B standard
>>>>>>> extension comprises instructions provided by the Zba, Zbb, and Zbs
>>>>>>> extensions.
>>>>>>>
>>>>>>> Hence add a schema check rule to enforce that B implies Zba, Zbb and Zbs.
>>>>>>>
>>>>>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>>>>>> ---

. . .

>>> The dependency can be go both ways, to also make specifying "b" mandatory
>>> when the three components are. That probably produces the most helpful
>>> devicetree ultimately.
>>
>> What about DT files that specified zba+zbb+zbs before "b" was
>> ratified?
> 
> They'd generate a warning, which can then be fixed. That's fine to do, a
> warning in linux-next doesn't harm anyone. Updating devicetrees in ways
> that don't change their meaning but provide extra value is not a problem
> in my book.

OK.

. . .

>> But why even bother supporting "b" if you have to *also*
>> support "zba+zbb+zbs" if you use it?  It adds the possibility
>> of new errors ("b" without "zbs", for example), while not
>> really enabling or representing anything new.
> 
> That was my first question after all! Ultimately I'd really err on the
> side of adding it because people will expect to be able to use it and
> because, in terms of kernel support, it will be useful for ACPI systems.

I think it's too bad these "equivalent" extensions can't be used
to simplify things.

I really dislike requiring the both a simpler extension *and*
the others that it represents/implies.

But practically speaking you're probably right.  People will
expect to be able to use them.  DT tools will then point out
what's missing, and the list of extensions supported by a
given CPU will just grow and grow and grow.

					-Alex

Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

On Tue, Dec 30, 2025 at 12:06:39PM -0600, Alex Elder wrote:


> I think it's too bad these "equivalent" extensions can't be used
> to simplify things.
> 
> I really dislike requiring the both a simpler extension *and*
> the others that it represents/implies.

They generally have been done they way you'd expect, this one just
differs because b is being added much later on rather than at the same
time.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Heinrich Schuchardt]

Am 30. Dezember 2025 18:37:25 MEZ schrieb Conor Dooley <conor@kernel.org>:
>On Tue, Dec 30, 2025 at 09:21:56AM -0600, Rob Herring wrote:
>> On Mon, Dec 29, 2025 at 9:14 PM Alex Elder <elder@riscstar.com> wrote:
>> >
>> > On 12/29/25 8:13 PM, Rob Herring wrote:
>> > > On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
>> > >> On 12/22/25 7:04 AM, Guodong Xu wrote:
>> > >>> Add description for the Supm extension. Supm indicates support for pointer
>> > >>> masking in user mode. Supm is mandatory for RVA23S64.
>> > >>>
>> > >>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
>> > >>> state") of riscv-j-extension.
>> > >>>
>> > >>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
>> > >>> this dependency.
>> > >>
>> > >> I have the same general question on this, about whether it's really
>> > >> necessary for the DT binding to enforce these requirements.  The
>> > >> RISC-V specifications are what truly defines their meaning, so I
>> > >> don't really see why the DT framework should need to enforce them.
>> > >> (That said, I'm sure there are other cases where DT enforces things
>> > >> it shouldn't have to.)
>> > >
>> > > Does the specification have some way to check it? What happens if a DT
>> > > is wrong? Are you going to require a DT update to make things right? Or
>> > > the kernel has to work-around the error? Neither is great. So having
>> > > this as a schema makes sense to prevent either scenario.
>> >
>> > I'm really glad you weighed in.  I actually have several questions
>> > related to RISC-V extensions and DT.  But for now I'll focus on
>> > just this...
>> >
>> > To answer your first question, I'm not sure how the specification
>> > is "checked", or what "it" is that you're asking about for that
>> > matter.  Also I think we have to be clear about what "wrong" means.
>> >
>> > RISC-V is defined by a (large and growing) set of specifications
>> > that are developed through a well-defined process.  When a spec
>> > is *ratified* it is committed, and it won't be changed.  These
>> > specifications are ultimately *the* definition of RISC-V
>> > compliance.
>> >
>> > I assumed the "wrong" you're talking about is a DTS/DTB that has
>> > been committed but somehow does not match what a RISC-V spec
>> > says, but I might be mistaken.
>> 
>> That's correct.
>> 
>> > Anyway, we can flip that around and have a similar problem:  What
>> > if we define the DT binding in such a way that it doesn't match
>> > the RISC-V spec?  The (ratified) RISC-V spec is right.
>> 
>> Sure. Any time there is more than 1 source of truth, they could be
>> mismatched. But it is 1 spec and 1 schema to compare, not N DTS files.
>> Checking the schema matches the spec is much easier than reviewing
>> every new DTS file.
>
>The objective is not to define things with divergent meanings anyway,
>only to say "this string is exactly this version of this extension",
>so that if some other version of an extension comes along we have a way
>to differentiate. We didn't before and that became problematic for both
>standard extensions and vendor specific stuff. You'll note we don't look
>to define anything ourselves, just cite the spec that provides the
>definitions.
>
>> The only true fix is to make the spec machine readable.
>> 
>> > My thought was that we should have software do the verification,
>> > and recommend the software (e.g. arch/riscv/kernel/cpufeature.c
>> > in Linux) be updated to verify things before committing to a
>> > DT binding.
>> 
>> That moves validation from build time to run time. How is that better?
>> And what about other OSs?
>> 
>> I'm very much of the opinion that it is not the kernel's job to
>> validate the DT. It obviously has not done a very good job given
>> issues we find with schemas. It's fine to have some checks in this
>> case if the kernel can't function (or use/enable the extension)
>> without the dependent extensions, but there are lots of classes of
>> errors the kernel doesn't need to care about.
>
>By and large what's in cpufeature.c is there to turn extensions off
>based on kconfig choices (vector support enabled etc) or kernel design
>decisions (kernel requiring both d and f extensions for fpu support). I

Should supm be handled in the same way? Add it to the device-tree of RVA23U64 devices. If a kernel does not support pointer masking in user space, hide the extension in cpufeature.c.

Best regards

Heinrich

>don't think there's anything there that doesn't assume that the
>devicetree is correct. For my money, it's much simpler to describe
>dependencies in a binding than add more code to the kernel that tries to
>figure out dependencies at runtime.
>

Re: [PATCH v2 11/13] dt-bindings: riscv: Add Supm extension description

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 6050 bytes --]

On Tue, Dec 30, 2025 at 09:41:56PM +0100, Heinrich Schuchardt wrote:
> Am 30. Dezember 2025 18:37:25 MEZ schrieb Conor Dooley <conor@kernel.org>:
> >On Tue, Dec 30, 2025 at 09:21:56AM -0600, Rob Herring wrote:
> >> On Mon, Dec 29, 2025 at 9:14 PM Alex Elder <elder@riscstar.com> wrote:
> >> >
> >> > On 12/29/25 8:13 PM, Rob Herring wrote:
> >> > > On Fri, Dec 26, 2025 at 03:28:47PM -0600, Alex Elder wrote:
> >> > >> On 12/22/25 7:04 AM, Guodong Xu wrote:
> >> > >>> Add description for the Supm extension. Supm indicates support for pointer
> >> > >>> masking in user mode. Supm is mandatory for RVA23S64.
> >> > >>>
> >> > >>> The Supm extension is ratified in commit d70011dde6c2 ("Update to ratified
> >> > >>> state") of riscv-j-extension.
> >> > >>>
> >> > >>> Supm depends on either Smnpm or Ssnpm, so add a schema check to enforce
> >> > >>> this dependency.
> >> > >>
> >> > >> I have the same general question on this, about whether it's really
> >> > >> necessary for the DT binding to enforce these requirements.  The
> >> > >> RISC-V specifications are what truly defines their meaning, so I
> >> > >> don't really see why the DT framework should need to enforce them.
> >> > >> (That said, I'm sure there are other cases where DT enforces things
> >> > >> it shouldn't have to.)
> >> > >
> >> > > Does the specification have some way to check it? What happens if a DT
> >> > > is wrong? Are you going to require a DT update to make things right? Or
> >> > > the kernel has to work-around the error? Neither is great. So having
> >> > > this as a schema makes sense to prevent either scenario.
> >> >
> >> > I'm really glad you weighed in.  I actually have several questions
> >> > related to RISC-V extensions and DT.  But for now I'll focus on
> >> > just this...
> >> >
> >> > To answer your first question, I'm not sure how the specification
> >> > is "checked", or what "it" is that you're asking about for that
> >> > matter.  Also I think we have to be clear about what "wrong" means.
> >> >
> >> > RISC-V is defined by a (large and growing) set of specifications
> >> > that are developed through a well-defined process.  When a spec
> >> > is *ratified* it is committed, and it won't be changed.  These
> >> > specifications are ultimately *the* definition of RISC-V
> >> > compliance.
> >> >
> >> > I assumed the "wrong" you're talking about is a DTS/DTB that has
> >> > been committed but somehow does not match what a RISC-V spec
> >> > says, but I might be mistaken.
> >> 
> >> That's correct.
> >> 
> >> > Anyway, we can flip that around and have a similar problem:  What
> >> > if we define the DT binding in such a way that it doesn't match
> >> > the RISC-V spec?  The (ratified) RISC-V spec is right.
> >> 
> >> Sure. Any time there is more than 1 source of truth, they could be
> >> mismatched. But it is 1 spec and 1 schema to compare, not N DTS files.
> >> Checking the schema matches the spec is much easier than reviewing
> >> every new DTS file.
> >
> >The objective is not to define things with divergent meanings anyway,
> >only to say "this string is exactly this version of this extension",
> >so that if some other version of an extension comes along we have a way
> >to differentiate. We didn't before and that became problematic for both
> >standard extensions and vendor specific stuff. You'll note we don't look
> >to define anything ourselves, just cite the spec that provides the
> >definitions.
> >
> >> The only true fix is to make the spec machine readable.
> >> 
> >> > My thought was that we should have software do the verification,
> >> > and recommend the software (e.g. arch/riscv/kernel/cpufeature.c
> >> > in Linux) be updated to verify things before committing to a
> >> > DT binding.
> >> 
> >> That moves validation from build time to run time. How is that better?
> >> And what about other OSs?
> >> 
> >> I'm very much of the opinion that it is not the kernel's job to
> >> validate the DT. It obviously has not done a very good job given
> >> issues we find with schemas. It's fine to have some checks in this
> >> case if the kernel can't function (or use/enable the extension)
> >> without the dependent extensions, but there are lots of classes of
> >> errors the kernel doesn't need to care about.
> >
> >By and large what's in cpufeature.c is there to turn extensions off
> >based on kconfig choices (vector support enabled etc) or kernel design
> >decisions (kernel requiring both d and f extensions for fpu support). I
> 
> Should supm be handled in the same way? Add it to the device-tree of
> RVA23U64 devices. If a kernel does not support pointer masking in user
> space, hide the extension in cpufeature.c.

Perhaps.
Samuel opted not to add supm to dt when he introduced the other relevant
extensions, so the rationale from him would be helpful but I'd like to
get more opinions on how to deal with supm specifically. supm doesn't
really describe hardware capability, since the privilege specific
instructions are what does that, which makes me question if it should be
in dt at all. On the other hand, it could be argued that supm describes
a combination of hardware capability at the dt consumer's privilege level
and is valid on that basis. Some wording like Zkr will probably be needed,
specifically mentioning that having supm in the dt means that corresponding
version sxnpm for the privilege level that the devicetree is provided to
is supported.

Either way, we are going to need something in cpufeature.c to imply
supm so that it appears to userspace if the privilege specific extension
is detected and supm is enabled in the kernel. The kernel already does
the implication internally it just isn't reported as an extension to
userspace IIRC.
If we permit supm in dt, we're also going to have to turn supm off if
the Kconfig option is disabled, but that's relatively little effort
since it mostly (or maybe entirely) reuses code from implying supm.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]