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

[Yixun Lan]

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)