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

[Conor Dooley]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20260101/0d0b65b3/attachment.sig>