[PATCH 0/2] mips: econet: add multi-vpe capability to EN751221

[PATCH 0/2] mips: econet: add multi-vpe capability to EN751221

[Caleb James DeLisle]

The EN751221 is a MIPS 34Kc so it supports MIPS_SMP_MT, but until now
this was disabled because to enable it requires the interrupt
controller to be in VEIC mode and previously only cascading mode was
supported by the interrupt controller driver. Since
commit 2ee2a685ee83 ("irqchip/econet-en751221: Support MIPS 34Kc VEIC mode")
the intc driver now supports VEIC mode. Add SMP_MT to init.c and
update the Device Tree to recognize dual VPE.

Caleb James DeLisle (2):
  mips: econet: add multi-vpe capability to EN751221
  mips: dts: econet: Describe dual-VPE 34Kc processor

 arch/mips/boot/dts/econet/en751221.dtsi |  7 +++++
 arch/mips/econet/Kconfig                |  4 +--
 arch/mips/econet/init.c                 | 42 ++++++++++++++++++++++++-
 3 files changed, 49 insertions(+), 4 deletions(-)


base-commit: 27c61f8565a438b2d1dea6f6a47af0e6dc12c112
-- 
2.39.5

[PATCH 1/2] mips: econet: add multi-vpe capability to EN751221

[Caleb James DeLisle]

EN751221 is a 34Kc so it has two VPEs (threads) but MIPS_SMP_MT
requires VEIC to be enabled in the interrupt controller, which only
became supported in
commit 2ee2a685ee83 ("irqchip/econet-en751221: Support MIPS 34Kc VEIC mode")

Register SMP_MT on startup and override init_secondary with CPU
interrupt unmasking as required by the EN751221 VEIC intc hardware.

Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
---
 arch/mips/econet/Kconfig |  4 +---
 arch/mips/econet/init.c  | 42 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/arch/mips/econet/Kconfig b/arch/mips/econet/Kconfig
index b37b9d25d5a4..579fb5b01532 100644
--- a/arch/mips/econet/Kconfig
+++ b/arch/mips/econet/Kconfig
@@ -16,9 +16,7 @@ choice
 		select HAVE_PCI
 		select IRQ_MIPS_CPU
 		select PCI_DRIVERS_GENERIC
-		select SMP
-		select SMP_UP
-		select SYS_SUPPORTS_SMP
+		select SYS_SUPPORTS_MULTITHREADING
 		help
 		  The EN751221 family includes EN7512, RN7513, EN7521, EN7526.
 		  They are based on single core MIPS 34Kc processors. To boot
diff --git a/arch/mips/econet/init.c b/arch/mips/econet/init.c
index 6f43ffb209cb..ae45b8788504 100644
--- a/arch/mips/econet/init.c
+++ b/arch/mips/econet/init.c
@@ -28,6 +28,41 @@ static void hw_reset(char *command)
 	iowrite32(RESET, CR_AHB_RSTCR);
 }
 
+/*
+ * vsmp_init_secondary expects either GIC or cascading interrupt configuration.
+ * The EN751221 is a 34Kc with VEIC, but not GIC compatible. The cascading
+ * configuration enables lines 6 and 7 for performance counters, but when this
+ * is done on the EN751221 intc with VEIC enabled, it causes the whole intc to
+ * stop sending interrupts.
+ * Only unmask lines 0 and 1 (software interrupts) in init_secondary.
+ */
+#ifdef CONFIG_MIPS_MT_SMP
+extern const struct plat_smp_ops vsmp_smp_ops;
+static struct plat_smp_ops en75_smp_ops __ro_after_init;
+
+static void en751221_init_secondary(void)
+{
+	write_c0_status((read_c0_status() & ~ST0_IM) |
+		(STATUSF_IP0 | STATUSF_IP1));
+}
+
+static int __init en751221_register_vsmp_smp_ops(void)
+{
+	if (!cpu_has_mipsmt)
+		return -ENODEV;
+
+	en75_smp_ops = vsmp_smp_ops;
+	en75_smp_ops.init_secondary = en751221_init_secondary;
+	register_smp_ops(&en75_smp_ops);
+	return 0;
+}
+#else
+static int __init en751221_register_vsmp_smp_ops(void)
+{
+	return -ENODEV;
+}
+#endif /* CONFIG_MIPS_MT_SMP */
+
 /* 1. Bring up early printk. */
 void __init prom_init(void)
 {
@@ -51,11 +86,16 @@ void __init plat_mem_setup(void)
 	early_init_dt_scan_memory();
 }
 
-/* 3. Overload __weak device_tree_init(), add SMP_UP ops */
+/* 3. Overload __weak device_tree_init(), add SMP ops */
 void __init device_tree_init(void)
 {
 	unflatten_and_copy_device_tree();
 
+	/* EN751221 dual-vpe */
+	if (!en751221_register_vsmp_smp_ops())
+		return;
+
+	/* EN751221 with MT_SMP disabled */
 	register_up_smp_ops();
 }
 
-- 
2.39.5

Re: [PATCH 1/2] mips: econet: add multi-vpe capability to EN751221

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditionally masking hardware interrupts in en751221_init_secondary breaks the secondary CPU's timer if the system boots with VEIC disabled.
--

--- Patch [1]: [PATCH 1/2] mips: econet: add multi-vpe capability to EN751221 ---
commit 29d4bfd90711d72516d1c7a3132dda2ae50742fc
Author: Caleb James DeLisle <cjd@cjdns.fr>

mips: econet: add multi-vpe capability to EN751221

This commit registers SMP_MT on startup and overrides init_secondary with
CPU interrupt unmasking required by the EN751221 VEIC intc hardware.

> diff --git a/arch/mips/econet/init.c b/arch/mips/econet/init.c
> --- a/arch/mips/econet/init.c
> +++ b/arch/mips/econet/init.c
[ ... ]
> +static void en751221_init_secondary(void)
> +{
> +	write_c0_status((read_c0_status() & ~ST0_IM) |
> +		(STATUSF_IP0 | STATUSF_IP1));
> +}
> +
> +static int __init en751221_register_vsmp_smp_ops(void)
> +{
> +	if (!cpu_has_mipsmt)
> +		return -ENODEV;

[Severity: High]
If the system boots with VEIC disabled (e.g., falling back to cascading mode),
will this break the secondary CPU's timer?

By registering these VEIC-specific SMP operations here without checking
cpu_has_veic, en751221_init_secondary() will execute on the secondary CPU.

Since en751221_init_secondary() clears ST0_IM unconditionally, it masks
hardware interrupts including the timer interrupt. Could this lead to
boot stalls or RCU hangs on non-VEIC setups?

> +
> +	en75_smp_ops = vsmp_smp_ops;
> +	en75_smp_ops.init_secondary = en751221_init_secondary;
> +	register_smp_ops(&en75_smp_ops);
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728184959.102441-1-cjd@cjdns.fr?part=1

Re: [PATCH 1/2] mips: econet: add multi-vpe capability to EN751221

[Caleb James DeLisle]

On 28/07/2026 21:06, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Unconditionally masking hardware interrupts in en751221_init_secondary breaks the secondary CPU's timer if the system boots with VEIC disabled.

I didn't mention it in the commit message because SMP_MT implies _EI and 
_VI, enabling VEIC. But lines 6 and 7 are in fact unconditionally dead 
on the EN751221, the classical MIPS timer is not present.

Thanks,

Caleb

> --
>
> --- Patch [1]: [PATCH 1/2] mips: econet: add multi-vpe capability to EN751221 ---
> commit 29d4bfd90711d72516d1c7a3132dda2ae50742fc
> Author: Caleb James DeLisle <cjd@cjdns.fr>
>
> mips: econet: add multi-vpe capability to EN751221
>
> This commit registers SMP_MT on startup and overrides init_secondary with
> CPU interrupt unmasking required by the EN751221 VEIC intc hardware.
>
>> diff --git a/arch/mips/econet/init.c b/arch/mips/econet/init.c
>> --- a/arch/mips/econet/init.c
>> +++ b/arch/mips/econet/init.c
> [ ... ]
>> +static void en751221_init_secondary(void)
>> +{
>> +	write_c0_status((read_c0_status() & ~ST0_IM) |
>> +		(STATUSF_IP0 | STATUSF_IP1));
>> +}
>> +
>> +static int __init en751221_register_vsmp_smp_ops(void)
>> +{
>> +	if (!cpu_has_mipsmt)
>> +		return -ENODEV;
> [Severity: High]
> If the system boots with VEIC disabled (e.g., falling back to cascading mode),
> will this break the secondary CPU's timer?
>
> By registering these VEIC-specific SMP operations here without checking
> cpu_has_veic, en751221_init_secondary() will execute on the secondary CPU.
>
> Since en751221_init_secondary() clears ST0_IM unconditionally, it masks
> hardware interrupts including the timer interrupt. Could this lead to
> boot stalls or RCU hangs on non-VEIC setups?
>
>> +
>> +	en75_smp_ops = vsmp_smp_ops;
>> +	en75_smp_ops.init_secondary = en751221_init_secondary;
>> +	register_smp_ops(&en75_smp_ops);
>> +	return 0;
>> +}

[PATCH 2/2] mips: dts: econet: Describe dual-VPE 34Kc processor

[Caleb James DeLisle]

The 34Kc processor has two VPEs (threads) and the interrupt controller
on the EN751221 re-routes (in hardware) the software interrupt pins
zero and one to numbers 7 and 8 in the flat VEIC interrupt domain.

Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
---
 arch/mips/boot/dts/econet/en751221.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/mips/boot/dts/econet/en751221.dtsi b/arch/mips/boot/dts/econet/en751221.dtsi
index 72cb65654c34..57ae84a8a9f8 100644
--- a/arch/mips/boot/dts/econet/en751221.dtsi
+++ b/arch/mips/boot/dts/econet/en751221.dtsi
@@ -23,6 +23,12 @@ cpu@0 {
 			compatible = "mips,mips34Kc";
 			reg = <0>;
 		};
+
+		cpu@1 {
+			device_type = "cpu";
+			compatible = "mips,mips34Kc";
+			reg = <1>;
+		};
 	};
 
 	cpuintc: interrupt-controller {
@@ -65,6 +71,7 @@ intc: interrupt-controller@1fb40000 {
 		interrupt-controller;
 		#interrupt-cells = <1>;
 		econet,shadow-interrupts = <7 2>, <8 3>, <13 12>, <30 29>;
+		econet,cpu-interrupt-map = <7 0>, <8 1>;
 	};
 
 	pciecfg: pciecfg@1fb80000 {
-- 
2.39.5

Re: [PATCH 2/2] mips: dts: econet: Describe dual-VPE 34Kc processor

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Off-by-one array bounds check in `get_shadow_interrupts()` allows out-of-bounds write.
- [High] Bitwise shift overflow and incorrect register targeting when unmasking CPU interrupts >= 32 in `econet_cpu_init()`.
--

--- Patch [2]: [PATCH 2/2] mips: dts: econet: Describe dual-VPE 34Kc processor ---
commit 2334c8459979130dce8cf68994de6842f0bba377
Author: Caleb James DeLisle <cjd@cjdns.fr>

mips: dts: econet: Describe dual-VPE 34Kc processor
    
The 34Kc processor has two VPEs (threads) and the interrupt controller
on the EN751221 re-routes (in hardware) the software interrupt pins
zero and one to numbers 7 and 8 in the flat VEIC interrupt domain.

> diff --git a/arch/mips/boot/dts/econet/en751221.dtsi b/arch/mips/boot/dts/econet/en751221.dtsi
> index 72cb65654c341..57ae84a8a9f85 100644
> --- a/arch/mips/boot/dts/econet/en751221.dtsi
> +++ b/arch/mips/boot/dts/econet/en751221.dtsi

[ ... ]

> @@ -65,6 +71,7 @@ intc: interrupt-controller@1fb40000 {
>  		interrupt-controller;
>  		#interrupt-cells = <1>;
>  		econet,shadow-interrupts = <7 2>, <8 3>, <13 12>, <30 29>;

[Severity: High]
This isn't a bug introduced by this patch, but is there an off-by-one array
bounds check in the driver that parses this property?

Looking at get_shadow_interrupts() in drivers/irqchip/irq-econet-en751221.c,
the bounds check uses > instead of >=:

    if (shadow > IRQ_COUNT) {
        ...

If a device tree supplies a shadow interrupt number of 40 (which equals
IRQ_COUNT), this check evaluates to false. This allows an out-of-bounds
write of one byte past the end of the econet_intc struct:

    econet_intc.interrupt_shadows[shadow] = IS_SHADOW;

Could this lead to adjacent memory corruption if malformed device tree data
is parsed?

> +		econet,cpu-interrupt-map = <7 0>, <8 1>;

[Severity: High]
This is a pre-existing issue, but does parsing this property expose a bitwise
shift overflow and incorrect register targeting in the driver if receive
IRQs >= 32 are provided?

In drivers/irqchip/irq-econet-en751221.c:econet_cpu_init(), the code validates
input up to IRQ_COUNT - 1 (39), but unconditionally applies BIT(receive) to a
32-bit mask:

    mask |= BIT(receive);

It then writes this to REG_MASK0, which is only for IRQs 0-31, ignoring
REG_MASK1:

    econet_wreg(REG_MASK0, mask, mask);

Since the driver explicitly validates input up to 39, could providing a device
tree with receive IRQs >= 32 trigger undefined behavior and functional failures?

>  	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728184959.102441-1-cjd@cjdns.fr?part=2