[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

[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