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

[sashiko-bot@kernel.org]

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