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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx/

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