[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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[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