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

[Guodong Xu]

On Tue, Jan 13, 2026 at 5:46 AM Conor Dooley <conor at 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.