linux-kernel - Re: [PATCH 7/8] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC

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] [day] [month] [year] [list]

Message-ID: <20260101-legume-engraved-0fae8282cfbe@spud>
Date: Thu, 1 Jan 2026 00:24:00 +0000
From: Conor Dooley <conor@...nel.org>
To: Guodong Xu <guodong@...cstar.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...ive.com>,
	Kevin Meng Zhang <zhangmeng.kevin@...ux.spacemit.com>,
	devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org,
	linux-kernel@...r.kernel.org, spacemit@...ts.linux.dev,
	linux-serial@...r.kernel.org, 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>,
	Yixun Lan <dlan@...too.org>,
	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>
Subject: Re: [PATCH 7/8] riscv: dts: spacemit: add initial device tree of
 SpacemiT K3 SoC

On Fri, Dec 26, 2025 at 02:53:10PM +0800, Guodong Xu wrote:

> As we wait for Samuel to share his opinion, maybe I can submit a patch in
> (I already have it)
> my next version or as in a different patchset to implement what you suggested.
>  - Assign RISCV_ISA_EXT_SUPM a standalone ext number in hwcap.h
>  - Implement a riscv_ext_supm_validate() and put it in the callback of both
>     ssnpm and smnpm.
>  - Kconfig will be kept as a top level gatekeeper, no change.
>  - dt-binding entry for supm will not be added.
> 
> The only reason support me to add sump into to the dt binding
> (extensions.yaml) is it's now a mandatory extension required by RVA23U64.
> However, as you explained, that logic seems not strong enough.

Regardless of what we end up doing in dt, I think you should write the
kernel code as if we are adding it to the binding. That way you can "imply"
supm from both ssnpm and smnpm (see riscv_zvkng_bundled_exts for an
example) and add the validate callback that checks against the privilege
level to supm itself. I don't think sxnpm should be disabled if the
privilege level of the kernel is different to that of the extension
(e.g. s mode kernel and smnpm) or if the kconfig option is disabled
(because I think ssnpm could be providing kvm with pointer masking even
when it is disabled for userspace). I think doing it the way I suggest
works better for those kinds of cases but also will just happen to work
for ACPI systems that have supm without the relevant sxmpm listed.

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