[PATCH] riscv: dts: spacemit: k3: enable status of mimsic and maplic to okay

[PATCH] riscv: dts: spacemit: k3: enable status of mimsic and maplic to okay

[E Shattow]

Change the "reserved" status of mimsic and maplic to "okay". There is
an mainline OpenSBI user of this and setting status okay resolves the
stall of Linux when probing peripherals at boot.

Fixes: 56f37e391a62 ("riscv: dts: spacemit: add initial support for K3 SoC")
Signed-off-by: E Shattow <e@freeshell.de>

---

Follows a discussion changing the status at U-Boot mailing list:
https://lore.kernel.org/u-boot/20261028184526.1887640-2-e@freeshell.de/

Moving the discussion to LKML as there are differences of opinion on
whether this should be changed in Linux or let remain to downstream
users changing this in firmware that requires it. The change is
trivial to carry downstream in mainline U-Boot.
---
 arch/riscv/boot/dts/spacemit/k3.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
index a5fb72e23dcf..4b3362b64e26 100644
--- a/arch/riscv/boot/dts/spacemit/k3.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
@@ -1452,7 +1452,7 @@ mimsic: interrupt-controller@f1000000 {
 			msi-controller;
 			riscv,hart-index-bits = <4>;
 			riscv,num-ids = <511>;
-			status = "reserved";
+			status = "okay";
 		};
 
 		maplic: interrupt-controller@f1800000 {
@@ -1464,7 +1464,7 @@ maplic: interrupt-controller@f1800000 {
 			riscv,children = <&saplic>;
 			riscv,delegation = <&saplic 1 512>;
 			riscv,num-sources = <512>;
-			status = "reserved";
+			status = "okay";
 		};
 
 		aclint_mswi: interrupt-controller@f1810000 {

base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8
-- 
2.53.0

Re: [PATCH] riscv: dts: spacemit: k3: enable status of mimsic and maplic to okay

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] riscv: dts: spacemit: enabling M-mode mimsic and maplic breaks S-mode boot
--

commit 20f17376632e73238d57264a563c4880863fe4a3
Author: E Shattow <e@freeshell.de>

riscv: dts: spacemit: k3: enable status of mimsic and maplic to okay

This commit changes the status property of the mimsic and maplic interrupt
controller nodes in k3.dtsi from "reserved" to "okay" for OpenSBI use.

> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> index a5fb72e23dcfa..4b3362b64e266 100644
> --- a/arch/riscv/boot/dts/spacemit/k3.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> @@ -1452,7 +1452,7 @@ mimsic: interrupt-controller@f1000000 {
>  			msi-controller;
>  			riscv,hart-index-bits = <4>;
>  			riscv,num-ids = <511>;
> -			status = "reserved";
> +			status = "okay";
>  		};
>  
>  		maplic: interrupt-controller@f1800000 {
> @@ -1464,7 +1464,7 @@ maplic: interrupt-controller@f1800000 {
>  			riscv,children = <&saplic>;
>  			riscv,delegation = <&saplic 1 512>;
>  			riscv,num-sources = <512>;
> -			status = "reserved";
> +			status = "okay";

[Severity: High]
Does enabling mimsic and maplic in k3.dtsi cause a boot regression when
S-mode Linux boots with a kernel-built DTB loaded in S-mode (for example via
U-Boot extlinux/booti/EFI, GRUB, or kexec) where OpenSBI's coldboot
fdt_fixups() did not patch the newly loaded DTB?

Unlike aclint_mswi and aclint_mtimer, which have no Linux driver, mimsic and
maplic match the riscv,imsics and riscv,aplic irqchip drivers, while S-mode
Linux is meant to use simsic and saplic.

When mimsic has status = "okay", of_irq_init() invokes
imsic_early_dt_init() -> imsic_setup_state() on mimsic after simsic, which
fails because the singleton imsic state is already initialized:

drivers/irqchip/irq-riscv-imsic-state.c:imsic_setup_state() {
	if (imsic) {
		pr_err("%pfwP: already initialized hence ignoring\n", fwnode);
		return -EALREADY;
	}
}

Because early irqchip init fails, of_irq_init() clears OF_POPULATED on mimsic
and exposes it to platform device probing, where imsic_platform_dt_probe() ->
imsic_platform_probe_common() fails with -ENODEV:

drivers/irqchip/irq-riscv-imsic-platform.c:imsic_platform_probe_common() {
	if (imsic && imsic->global.fwnode != fwnode) {
		pr_err("%pfwP: fwnode mismatch\n", fwnode);
		return -ENODEV;
	}
}

With mimsic failing to bind, maplic (which has msi-parent = <&mimsic>) is
left permanently deferred under default fw_devlink. Furthermore, if
aplic_probe() runs on maplic (such as when fw_devlink is permissive or off),
aplic_probe() -> aplic_msi_setup() -> aplic_setup_priv() calls
aplic_init_hw_irqs() before resolving the msi-parent domain:

drivers/irqchip/irq-riscv-aplic-main.c:aplic_init_hw_irqs() {
	/* Disable all interrupts */
	for (i = 0; i <= priv->nr_irqs; i += 32)
		writel(-1U, priv->regs + APLIC_CLRIE_BASE + (i / 32) * sizeof(u32));

	/* Set interrupt type and default priority for all interrupts */
	for (i = 1; i <= priv->nr_irqs; i++) {
		writel(0, priv->regs + APLIC_SOURCECFG_BASE + (i - 1) * sizeof(u32));
		writel(APLIC_DEFAULT_PRIORITY,
		       priv->regs + APLIC_TARGET_BASE + (i - 1) * sizeof(u32));
	}

	/* Clear APLIC domaincfg */
	writel(0, priv->regs + APLIC_DOMAINCFG);
}

Won't writing to maplic's M-mode MMIO registers at 0xf1800000 from S-mode
either trigger an immediate Store/AMO access fault panic due to OpenSBI's PMP
protection or wipe out the M-mode interrupt delegation to saplic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261029162343.1896134-1-e@freeshell.de?part=1

Re: [PATCH] riscv: dts: spacemit: k3: enable status of mimsic and maplic to okay

[Troy Mitchell]

[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]

Hi E,

On Thu Oct 29, 2026 at 9:23 AM -0700, E Shattow wrote:
> Change the "reserved" status of mimsic and maplic to "okay". There is
> an mainline OpenSBI user of this and setting status okay resolves the
> stall of Linux when probing peripherals at boot.

Thanks for bringing this here. I still think status = "reserved" in
k3.dtsi is the right description.

(To clarify the Acked-by I gave on the U-Boot thread: it was for
carrying the override in spacemit-k3-u-boot.dtsi, not for changing
the kernel DT)

> @@ -1452,7 +1452,7 @@ mimsic: interrupt-controller@f1000000 {
>  			msi-controller;
>  			riscv,hart-index-bits = <4>;
>  			riscv,num-ids = <511>;
> -			status = "reserved";
> +			status = "okay";
>  		};
>  
>  		maplic: interrupt-controller@f1800000 {
> @@ -1464,7 +1464,7 @@ maplic: interrupt-controller@f1800000 {
>  			riscv,children = <&saplic>;
>  			riscv,delegation = <&saplic 1 512>;
>  			riscv,num-sources = <512>;
> -			status = "reserved";
> +			status = "okay";
>  		};
> Fixes: 56f37e391a62 ("riscv: dts: spacemit: add initial support for K3 SoC")
I don't think this is a bug in the kernel DT either.

This was also discussed when k3.dtsi was reviewed [1]. The DTB built
from the kernel tree is often loaded directly by the bootloader (e.g.
from /boot) instead of the FDT that OpenSBI has already fixed up. With
"okay" there, Linux would probe the M-level IMSIC/APLIC and take an
access fault. The compromise back then was to keep them out of the
kernel's view in k3.dtsi ("disabled" at first, "reserved" since v5)
and enable them for the firmware build in -u-boot.dtsi, which is
exactly what your U-Boot patch does.

(Also replacing Guodong's address with his current one in Cc.)

[1] https://lore.kernel.org/all/77f9a001-7f0a-4c29-abcb-501e875da117@sifive.com/

-- 
Troy Mitchell

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH] riscv: dts: spacemit: k3: enable status of mimsic and maplic to okay

[Anirudh Srinivasan]

Hi Troy,

On Thu, Oct 29, 2026 at 9:04 PM Troy Mitchell
<troy.mitchell@linux.spacemit.com> wrote:
>
> Hi E,
>
> On Thu Oct 29, 2026 at 9:23 AM -0700, E Shattow wrote:
> > Change the "reserved" status of mimsic and maplic to "okay". There is
> > an mainline OpenSBI user of this and setting status okay resolves the
> > stall of Linux when probing peripherals at boot.
>
> Thanks for bringing this here. I still think status = "reserved" in
> k3.dtsi is the right description.
>
> (To clarify the Acked-by I gave on the U-Boot thread: it was for
> carrying the override in spacemit-k3-u-boot.dtsi, not for changing
> the kernel DT)
>
> > @@ -1452,7 +1452,7 @@ mimsic: interrupt-controller@f1000000 {
> >                       msi-controller;
> >                       riscv,hart-index-bits = <4>;
> >                       riscv,num-ids = <511>;
> > -                     status = "reserved";
> > +                     status = "okay";
> >               };
> >
> >               maplic: interrupt-controller@f1800000 {
> > @@ -1464,7 +1464,7 @@ maplic: interrupt-controller@f1800000 {
> >                       riscv,children = <&saplic>;
> >                       riscv,delegation = <&saplic 1 512>;
> >                       riscv,num-sources = <512>;
> > -                     status = "reserved";
> > +                     status = "okay";
> >               };
> > Fixes: 56f37e391a62 ("riscv: dts: spacemit: add initial support for K3 SoC")
> I don't think this is a bug in the kernel DT either.
>
> This was also discussed when k3.dtsi was reviewed [1]. The DTB built
> from the kernel tree is often loaded directly by the bootloader (e.g.
> from /boot) instead of the FDT that OpenSBI has already fixed up. With
> "okay" there, Linux would probe the M-level IMSIC/APLIC and take an
> access fault. The compromise back then was to keep them out of the
> kernel's view in k3.dtsi ("disabled" at first, "reserved" since v5)
> and enable them for the firmware build in -u-boot.dtsi, which is
> exactly what your U-Boot patch does.
>
> (Also replacing Guodong's address with his current one in Cc.)
>
> [1] https://lore.kernel.org/all/77f9a001-7f0a-4c29-abcb-501e875da117@sifive.com/

Linux will skip probing the M-IMSIC because of this piece of code in
imsic_get_parent_hartid. It returns -EINVAL unless it sees interrupt
ID 9.

    /*
     * Skip interrupts other than external interrupts for
     * current privilege level.
     */
    if (parent.args[0] != RV_IRQ_EXT)
        return -EINVAL;

I see this in the logs

[    0.000000] riscv-imsic: interrupt-controller@a0000000: no parent
irqs available
[    0.000000] riscv-imsic: interrupt-controller@a0000000: failed to
setup state (error -22)
[    0.000000] OF: of_irq_init: Failed to init
/soc/interrupt-controller@a0000000 ((____ptrval____)), parent
(____ptrval____)
[    0.000000] riscv-imsic: interrupt-controller@a4000000: providing
IPIs using interrupt 1

(a0 is m-imsic, a4 is s-imsic)

[   10.727605] platform cc000000.interrupt-controller: deferred probe
pending: platform: supplier a0000000.interrupt-controller not ready

The M-APLIC probe is deferred, because the M-IMSIC wasn't probed and
there is a dependency in the DT for it.

This shouldn't cause access faults as far as I can tell.

One would have to implement a dt fixup in u-boot like Heinrich
mentions in that thread to solve this.

>
> --
> Troy Mitchell