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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260113-swarm-mama-cbd7d0546578@spud>
Date: Tue, 13 Jan 2026 22:17:00 +0000
From: Conor Dooley <conor@...nel.org>
To: Yixun Lan <dlan@...too.org>
Cc: Guodong Xu <guodong@...cstar.com>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Paul Walmsley <pjw@...nel.org>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Samuel Holland <samuel.holland@...ive.com>,
	Anup Patel <anup@...infault.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jirislaby@...nel.org>, Lubomir Rintel <lkundrak@...sk>,
	Yangyu Chen <cyy@...self.name>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Heinrich Schuchardt <xypron.glpk@....de>,
	Kevin Meng Zhang <zhangmeng.kevin@...ux.spacemit.com>,
	Andrew Jones <ajones@...tanamicro.com>, devicetree@...r.kernel.org,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
	spacemit@...ts.linux.dev, linux-serial@...r.kernel.org,
	Krzysztof Kozlowski <krzysztof.kozlowski@....qualcomm.com>,
	Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
	Conor Dooley <conor.dooley@...rochip.com>
Subject: Re: [PATCH v4 00/11] riscv: spacemit: Add SpacemiT K3 SoC and K3
 Pico-ITX board

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.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)