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: <20260114202627.GA3155416-robh@kernel.org>
Date: Wed, 14 Jan 2026 14:26:27 -0600
From: Rob Herring <robh@...nel.org>
To: Yixun Lan <dlan@...too.org>
Cc: Conor Dooley <conor@...nel.org>, Paul Walmsley <pjw@...nel.org>,
	Guodong Xu <guodong@...cstar.com>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...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 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