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.
There are extensive discussions about how to handle these new extensions
in v2. In v3 (now v4), here is my best understading of what I think we have
reached consensus on.

At v3, Samuel Holland shared his opinion regarding how "supm" should be
handled [3]. He suggests removing "supm" from devicetrees not targeting
U-mode. I did that in Patch 10/11 of v3 with k3.dtsi. Samuel also notes
that "supm" could make sense as a binding for devicetrees targeting U-mode.
Considering there are other changes suggested in [2] and [3], I would
prefer to start a separate patchset dedicated to "supm".

Among others, major change in v4 is adding m-mode imsic and aplic nodes
into k3.dtsi (Patch 10/11) to better represent the hardware.

Hi, Conor

For the binding riscv/extensions.ymal, here's what changed in v3 (no
change in v4):

 1. Dropped the patch of adding "supm" into extensions.yaml. At the same
    time, I will start another patchset which implements the strategy
    outlined by Conor in Link [2] and by Samuel in Link [3].

 2. Dropped the dependency checks for "sha" on "h", "shcounterenw", and
    6 others. "sha" implies these extensions, and it should be allowed
    to be declared independently. Like "a" implies "zaamo" and "zalrsc".

 3. Enchanced the dependency check of "ziccamoa" on "a". Specifically,
     - added the dependency check of "ziccamoa" on "zaamo" or on "a".
     - added the dependency check of "za64rs" on "zalrsc" or on "a".
     - added the dependency check of "ziccrse" on "zalrsc" or "a".
    The commit message of this patch is updated too, to better explain the
    relationship  between "ziccamoa", "za64rs", "ziccrse" and "a".

 4. Enhanced checking dependency of "b" and "zba", "zbb", "zbs", making the
    dependency check in both directions, as discussed in [4]. Since "b"
    was ratified much later than its component extensions (zba/zbb/zbs),
    existing software and kernels expect these explicit strings. This
    bidirectional check ensures cores declaring "b" remain compatible
    with older software that only recognizes zba/zbb/zbs.

Thank you for your review.

Because the K3 uart compatible string patch (Patch 5 in v2) has been
applied in tty.git, the entire series now rebased on top of linux-next,
tag: next-20260109.

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.

Link: https://www.spacemit.com/en/spacemit-x100-core/ [1]
Link: https://lore.kernel.org/lkml/20260101-legume-engraved-0fae8282cfbe@spud/ [2]
Link: https://lore.kernel.org/all/4ebbe14b-2579-4ba6-808d-d50c24641d04@sifive.com/ [3]
Link: https://lore.kernel.org/all/20251230-imprison-sleet-6b5a1e26d34b@spud/#r [4]

Changes in v4:
- Patch 5:
   Adjust maintainers list in alphabetic order.
   Declare spacemit,k3-pico-itx as an enum, which could save future
    code change when adding new boards.
- Patch 10:
   Fix missing blank space after comma in simsic compatible.
   Add m-mode imsic and aplic nodes, per suggestion received from Samuel
    Holland.
   Adjust node properties order in nodes simsic, saplic, mimsic, maplic to
    follow the DTS coding style.

- Link to v3: https://lore.kernel.org/r/20260108-k3-basic-dt-v3-0-ed99eb4c3ad3@riscstar.com

Other Changes in v3 include:
- Patch 1:
   Acked-by: Krzysztof Kozlowski
- Patch 4:
   Acked-by: Krzysztof Kozlowski
- Dropped Patch 5 "dt-bindings: serial: 8250: add SpacemiT K3 UART compatible"
   as it has been applied to tty-next.

- Link to v2: https://lore.kernel.org/r/20251222-k3-basic-dt-v2-0-3af3f3cd0f8a@riscstar.com

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 (11):
      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: 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
      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      | 169 ++++++
 .../devicetree/bindings/riscv/spacemit.yaml        |   5 +
 .../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               | 590 +++++++++++++++++++++
 9 files changed, 807 insertions(+)
---
base-commit: 31d167f54de93f14fa8e4bc6cbc4adaf7019fd94
change-id: 20251216-k3-basic-dt-cd9540061989

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

On Sat, Jan 10, 2026 at 01:18:12PM +0800, Guodong Xu wrote:

> Hi, Conor
> 
> For the binding riscv/extensions.ymal, here's what changed in v3 (no
> change in v4):
> 
>  1. Dropped the patch of adding "supm" into extensions.yaml. At the same
>     time, I will start another patchset which implements the strategy
>     outlined by Conor in Link [2] and by Samuel in Link [3].

Okay, that seems reasonable to separate out.

> 
>  2. Dropped the dependency checks for "sha" on "h", "shcounterenw", and
>     6 others. "sha" implies these extensions, and it should be allowed
>     to be declared independently. Like "a" implies "zaamo" and "zalrsc".
> 
>  3. Enchanced the dependency check of "ziccamoa" on "a". Specifically,
>      - added the dependency check of "ziccamoa" on "zaamo" or on "a".
>      - added the dependency check of "za64rs" on "zalrsc" or on "a".
>      - added the dependency check of "ziccrse" on "zalrsc" or "a".
>     The commit message of this patch is updated too, to better explain the
>     relationship  between "ziccamoa", "za64rs", "ziccrse" and "a".
> 
>  4. Enhanced checking dependency of "b" and "zba", "zbb", "zbs", making the
>     dependency check in both directions, as discussed in [4]. Since "b"
>     was ratified much later than its component extensions (zba/zbb/zbs),
>     existing software and kernels expect these explicit strings. This
>     bidirectional check ensures cores declaring "b" remain compatible
>     with older software that only recognizes zba/zbb/zbs.

This I asked about in the relevant patch, I would like to know what your
plan for adding the "b"s is.

Spacemit folks, I assume you weren't planning on taking the
extensions.yaml stuff via your tree? If you weren't, I'll grab it once
the question about b is answered.

On Tue, Jan 13, 2026 at 5:46 AM Conor Dooley <conor@kernel.org> wrote:
>
> On Sat, Jan 10, 2026 at 01:18:12PM +0800, Guodong Xu wrote:
>
> > Hi, Conor
> >
> > For the binding riscv/extensions.ymal, here's what changed in v3 (no
> > change in v4):
> >
> >  1. Dropped the patch of adding "supm" into extensions.yaml. At the same
> >     time, I will start another patchset which implements the strategy
> >     outlined by Conor in Link [2] and by Samuel in Link [3].
>
> Okay, that seems reasonable to separate out.
>
> >
> >  2. Dropped the dependency checks for "sha" on "h", "shcounterenw", and
> >     6 others. "sha" implies these extensions, and it should be allowed
> >     to be declared independently. Like "a" implies "zaamo" and "zalrsc".
> >
> >  3. Enchanced the dependency check of "ziccamoa" on "a". Specifically,
> >      - added the dependency check of "ziccamoa" on "zaamo" or on "a".
> >      - added the dependency check of "za64rs" on "zalrsc" or on "a".
> >      - added the dependency check of "ziccrse" on "zalrsc" or "a".
> >     The commit message of this patch is updated too, to better explain the
> >     relationship  between "ziccamoa", "za64rs", "ziccrse" and "a".
> >
> >  4. Enhanced checking dependency of "b" and "zba", "zbb", "zbs", making the
> >     dependency check in both directions, as discussed in [4]. Since "b"
> >     was ratified much later than its component extensions (zba/zbb/zbs),
> >     existing software and kernels expect these explicit strings. This
> >     bidirectional check ensures cores declaring "b" remain compatible
> >     with older software that only recognizes zba/zbb/zbs.
>
> This I asked about in the relevant patch, I would like to know what your
> plan for adding the "b"s is.

Thanks for confirming the above. Yes, I will start a follow up patch to update
the dtsi files related to the "b" extension.

Best regards,
Guodong Xu

>
> Spacemit folks, I assume you weren't planning on taking the
> extensions.yaml stuff via your tree? If you weren't, I'll grab it once
> the question about b is answered.

Hi Conor,

On 21:45 Mon 12 Jan     , Conor Dooley wrote:
> On Sat, Jan 10, 2026 at 01:18:12PM +0800, Guodong Xu wrote:
> 
> > Hi, Conor
> > 
> > For the binding riscv/extensions.ymal, here's what changed in v3 (no
> > change in v4):
> > 
> >  1. Dropped the patch of adding "supm" into extensions.yaml. At the same
> >     time, I will start another patchset which implements the strategy
> >     outlined by Conor in Link [2] and by Samuel in Link [3].
> 
> Okay, that seems reasonable to separate out.
> 
> > 
> >  2. Dropped the dependency checks for "sha" on "h", "shcounterenw", and
> >     6 others. "sha" implies these extensions, and it should be allowed
> >     to be declared independently. Like "a" implies "zaamo" and "zalrsc".
> > 
> >  3. Enchanced the dependency check of "ziccamoa" on "a". Specifically,
> >      - added the dependency check of "ziccamoa" on "zaamo" or on "a".
> >      - added the dependency check of "za64rs" on "zalrsc" or on "a".
> >      - added the dependency check of "ziccrse" on "zalrsc" or "a".
> >     The commit message of this patch is updated too, to better explain the
> >     relationship  between "ziccamoa", "za64rs", "ziccrse" and "a".
> > 
> >  4. Enhanced checking dependency of "b" and "zba", "zbb", "zbs", making the
> >     dependency check in both directions, as discussed in [4]. Since "b"
> >     was ratified much later than its component extensions (zba/zbb/zbs),
> >     existing software and kernels expect these explicit strings. This
> >     bidirectional check ensures cores declaring "b" remain compatible
> >     with older software that only recognizes zba/zbb/zbs.
> 
> This I asked about in the relevant patch, I would like to know what your
> plan for adding the "b"s is.
> 
..
> Spacemit folks, I assume you weren't planning on taking the
> extensions.yaml stuff via your tree? If you weren't, I'll grab it once
> the question about b is answered.

sure, please take extension stuff which are patches 6-9, for 1-5, it's
all about adding support for SpacemiT K3 SoC, to avoid petential conflicts,
I wouldn't mind if you also taking them? then I can handle the rest 10,11 for DT


-- 
Yixun Lan (dlan)

On Tue, Jan 13, 2026 at 08:21:23AM +0800, Yixun Lan wrote:
> Hi Conor,
> 
> On 21:45 Mon 12 Jan     , Conor Dooley wrote:
> > On Sat, Jan 10, 2026 at 01:18:12PM +0800, Guodong Xu wrote:
> > 
> > > Hi, Conor
> > > 
> > > For the binding riscv/extensions.ymal, here's what changed in v3 (no
> > > change in v4):
> > > 
> > >  1. Dropped the patch of adding "supm" into extensions.yaml. At the same
> > >     time, I will start another patchset which implements the strategy
> > >     outlined by Conor in Link [2] and by Samuel in Link [3].
> > 
> > Okay, that seems reasonable to separate out.
> > 
> > > 
> > >  2. Dropped the dependency checks for "sha" on "h", "shcounterenw", and
> > >     6 others. "sha" implies these extensions, and it should be allowed
> > >     to be declared independently. Like "a" implies "zaamo" and "zalrsc".
> > > 
> > >  3. Enchanced the dependency check of "ziccamoa" on "a". Specifically,
> > >      - added the dependency check of "ziccamoa" on "zaamo" or on "a".
> > >      - added the dependency check of "za64rs" on "zalrsc" or on "a".
> > >      - added the dependency check of "ziccrse" on "zalrsc" or "a".
> > >     The commit message of this patch is updated too, to better explain the
> > >     relationship  between "ziccamoa", "za64rs", "ziccrse" and "a".
> > > 
> > >  4. Enhanced checking dependency of "b" and "zba", "zbb", "zbs", making the
> > >     dependency check in both directions, as discussed in [4]. Since "b"
> > >     was ratified much later than its component extensions (zba/zbb/zbs),
> > >     existing software and kernels expect these explicit strings. This
> > >     bidirectional check ensures cores declaring "b" remain compatible
> > >     with older software that only recognizes zba/zbb/zbs.
> > 
> > This I asked about in the relevant patch, I would like to know what your
> > plan for adding the "b"s is.
> > 
> ..
> > Spacemit folks, I assume you weren't planning on taking the
> > extensions.yaml stuff via your tree? If you weren't, I'll grab it once
> > the question about b is answered.
> 
> sure, please take extension stuff which are patches 6-9, for 1-5, it's
> all about adding support for SpacemiT K3 SoC, to avoid petential conflicts,
> I wouldn't mind if you also taking them? then I can handle the rest 10,11 for DT

Stuff for spacemit is either for you or for the relevant subsystem
maintainers. You're probably safe enough taking the
timer/interrupt-controller stuff if the maintainers don't apply it in a
reasonable period, it's not abnormal for those in particular to go via
the platform maintainer in my experience. Just be clear that you have
done so. I'm only interested in taking 6-9.

On 22:17 Tue 13 Jan     , Conor Dooley wrote:
> On Tue, Jan 13, 2026 at 08:21:23AM +0800, Yixun Lan wrote:
> > Hi Conor,
> > 
> > On 21:45 Mon 12 Jan     , Conor Dooley wrote:
> > > On Sat, Jan 10, 2026 at 01:18:12PM +0800, Guodong Xu wrote:
> > > 
> > > > Hi, Conor
> > > > 
> > > > For the binding riscv/extensions.ymal, here's what changed in v3 (no
> > > > change in v4):
> > > > 
> > > >  1. Dropped the patch of adding "supm" into extensions.yaml. At the same
> > > >     time, I will start another patchset which implements the strategy
> > > >     outlined by Conor in Link [2] and by Samuel in Link [3].
> > > 
> > > Okay, that seems reasonable to separate out.
> > > 
> > > > 
> > > >  2. Dropped the dependency checks for "sha" on "h", "shcounterenw", and
> > > >     6 others. "sha" implies these extensions, and it should be allowed
> > > >     to be declared independently. Like "a" implies "zaamo" and "zalrsc".
> > > > 
> > > >  3. Enchanced the dependency check of "ziccamoa" on "a". Specifically,
> > > >      - added the dependency check of "ziccamoa" on "zaamo" or on "a".
> > > >      - added the dependency check of "za64rs" on "zalrsc" or on "a".
> > > >      - added the dependency check of "ziccrse" on "zalrsc" or "a".
> > > >     The commit message of this patch is updated too, to better explain the
> > > >     relationship  between "ziccamoa", "za64rs", "ziccrse" and "a".
> > > > 
> > > >  4. Enhanced checking dependency of "b" and "zba", "zbb", "zbs", making the
> > > >     dependency check in both directions, as discussed in [4]. Since "b"
> > > >     was ratified much later than its component extensions (zba/zbb/zbs),
> > > >     existing software and kernels expect these explicit strings. This
> > > >     bidirectional check ensures cores declaring "b" remain compatible
> > > >     with older software that only recognizes zba/zbb/zbs.
> > > 
> > > This I asked about in the relevant patch, I would like to know what your
> > > plan for adding the "b"s is.
> > > 
> > ..
> > > Spacemit folks, I assume you weren't planning on taking the
> > > extensions.yaml stuff via your tree? If you weren't, I'll grab it once
> > > the question about b is answered.
> > 
> > sure, please take extension stuff which are patches 6-9, for 1-5, it's
> > all about adding support for SpacemiT K3 SoC, to avoid petential conflicts,
> > I wouldn't mind if you also taking them? then I can handle the rest 10,11 for DT
> 
> Stuff for spacemit is either for you or for the relevant subsystem
> maintainers. You're probably safe enough taking the
> timer/interrupt-controller stuff if the maintainers don't apply it in a
> reasonable period, it's not abnormal for those in particular to go via
> the platform maintainer in my experience. Just be clear that you have
> done so. I'm only interested in taking 6-9.
Hi Conor,
  Ok, I got, thank you!

Hi Paul Walmsley,
  I assume you're responsible for more general riscv stuff with your
effective maintainer hat, so do you mind if I take patches 1-5 via SpacemiT
SoC tree? I think the potential conflicts should be low and easy to fix.
  Or, in the other hand, just let me know which patches you would like
to take, then I will handle the rest. Thanks

-- 
Yixun Lan (dlan)

On Wed, Jan 14, 2026 at 10:14:05AM +0800, Yixun Lan wrote:
> 
> On 22:17 Tue 13 Jan     , Conor Dooley wrote:
> > On Tue, Jan 13, 2026 at 08:21:23AM +0800, Yixun Lan wrote:
> > > Hi Conor,
> > > 
> > > On 21:45 Mon 12 Jan     , Conor Dooley wrote:
> > > > On Sat, Jan 10, 2026 at 01:18:12PM +0800, Guodong Xu wrote:
> > > > 
> > > > > Hi, Conor
> > > > > 
> > > > > For the binding riscv/extensions.ymal, here's what changed in v3 (no
> > > > > change in v4):
> > > > > 
> > > > >  1. Dropped the patch of adding "supm" into extensions.yaml. At the same
> > > > >     time, I will start another patchset which implements the strategy
> > > > >     outlined by Conor in Link [2] and by Samuel in Link [3].
> > > > 
> > > > Okay, that seems reasonable to separate out.
> > > > 
> > > > > 
> > > > >  2. Dropped the dependency checks for "sha" on "h", "shcounterenw", and
> > > > >     6 others. "sha" implies these extensions, and it should be allowed
> > > > >     to be declared independently. Like "a" implies "zaamo" and "zalrsc".
> > > > > 
> > > > >  3. Enchanced the dependency check of "ziccamoa" on "a". Specifically,
> > > > >      - added the dependency check of "ziccamoa" on "zaamo" or on "a".
> > > > >      - added the dependency check of "za64rs" on "zalrsc" or on "a".
> > > > >      - added the dependency check of "ziccrse" on "zalrsc" or "a".
> > > > >     The commit message of this patch is updated too, to better explain the
> > > > >     relationship  between "ziccamoa", "za64rs", "ziccrse" and "a".
> > > > > 
> > > > >  4. Enhanced checking dependency of "b" and "zba", "zbb", "zbs", making the
> > > > >     dependency check in both directions, as discussed in [4]. Since "b"
> > > > >     was ratified much later than its component extensions (zba/zbb/zbs),
> > > > >     existing software and kernels expect these explicit strings. This
> > > > >     bidirectional check ensures cores declaring "b" remain compatible
> > > > >     with older software that only recognizes zba/zbb/zbs.
> > > > 
> > > > This I asked about in the relevant patch, I would like to know what your
> > > > plan for adding the "b"s is.
> > > > 
> > > ..
> > > > Spacemit folks, I assume you weren't planning on taking the
> > > > extensions.yaml stuff via your tree? If you weren't, I'll grab it once
> > > > the question about b is answered.
> > > 
> > > sure, please take extension stuff which are patches 6-9, for 1-5, it's
> > > all about adding support for SpacemiT K3 SoC, to avoid petential conflicts,
> > > I wouldn't mind if you also taking them? then I can handle the rest 10,11 for DT
> > 
> > Stuff for spacemit is either for you or for the relevant subsystem
> > maintainers. You're probably safe enough taking the
> > timer/interrupt-controller stuff if the maintainers don't apply it in a
> > reasonable period, it's not abnormal for those in particular to go via
> > the platform maintainer in my experience. Just be clear that you have
> > done so. I'm only interested in taking 6-9.
> Hi Conor,
>   Ok, I got, thank you!
> 
> Hi Paul Walmsley,
>   I assume you're responsible for more general riscv stuff with your
> effective maintainer hat, so do you mind if I take patches 1-5 via SpacemiT
> SoC tree? I think the potential conflicts should be low and easy to fix.
>   Or, in the other hand, just let me know which patches you would like
> to take, then I will handle the rest. Thanks

Paul would generally only ever take patch 1. You can take 1-5. The timer 
and interrupt-controller bindings tend to not get picked up by the 
subsystem unless there are driver changes too.

Rob

From: Conor Dooley <conor.dooley@microchip.com>

On Sat, 10 Jan 2026 13:18:12 +0800, Guodong Xu wrote:
> 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.
> There are extensive discussions about how to handle these new extensions
> in v2. In v3 (now v4), here is my best understading of what I think we have
> reached consensus on.
> 
> [...]

Applied 6-9 to riscv-dt-for-next :)

[06/11] dt-bindings: riscv: Add B ISA extension description
        https://git.kernel.org/conor/c/0cdb7fc1879b
[07/11] dt-bindings: riscv: Add descriptions for Za64rs, Ziccamoa, Ziccif, and Zicclsm
        https://git.kernel.org/conor/c/b321256a4f36
[08/11] dt-bindings: riscv: Add Ssccptr, Sscounterenw, Sstvala, Sstvecd, Ssu64xl
        https://git.kernel.org/conor/c/c712413333f8
[09/11] dt-bindings: riscv: Add Sha and its comprised extensions
        https://git.kernel.org/conor/c/89febd6a0276

Thanks,
Conor.