* [PATCH 1/2] mips: econet: add multi-vpe capability to EN751221
2026-07-28 18:49 [PATCH 0/2] mips: econet: add multi-vpe capability to EN751221 Caleb James DeLisle
@ 2026-07-28 18:49 ` Caleb James DeLisle
2026-07-28 19:06 ` sashiko-bot
2026-07-28 18:49 ` [PATCH 2/2] mips: dts: econet: Describe dual-VPE 34Kc processor Caleb James DeLisle
2026-08-03 13:14 ` [PATCH 0/2] mips: econet: add multi-vpe capability to EN751221 Thomas Bogendoerfer
2 siblings, 1 reply; 7+ messages in thread
From: Caleb James DeLisle @ 2026-07-28 18:49 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, robh, krzk+dt, conor+dt, tsbogend, devicetree,
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
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH 1/2] mips: econet: add multi-vpe capability to EN751221
2026-07-28 18:49 ` [PATCH 1/2] " Caleb James DeLisle
@ 2026-07-28 19:06 ` sashiko-bot
2026-07-28 19:36 ` Caleb James DeLisle
0 siblings, 1 reply; 7+ messages in thread
From: sashiko-bot @ 2026-07-28 19:06 UTC (permalink / raw)
To: Caleb James DeLisle; +Cc: conor+dt, devicetree, robh
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 1/2] mips: econet: add multi-vpe capability to EN751221
2026-07-28 19:06 ` sashiko-bot
@ 2026-07-28 19:36 ` Caleb James DeLisle
0 siblings, 0 replies; 7+ messages in thread
From: Caleb James DeLisle @ 2026-07-28 19:36 UTC (permalink / raw)
To: sashiko-reviews; +Cc: conor+dt, devicetree, robh
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;
>> +}
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 2/2] mips: dts: econet: Describe dual-VPE 34Kc processor
2026-07-28 18:49 [PATCH 0/2] mips: econet: add multi-vpe capability to EN751221 Caleb James DeLisle
2026-07-28 18:49 ` [PATCH 1/2] " Caleb James DeLisle
@ 2026-07-28 18:49 ` Caleb James DeLisle
2026-07-28 19:09 ` sashiko-bot
2026-08-03 13:14 ` [PATCH 0/2] mips: econet: add multi-vpe capability to EN751221 Thomas Bogendoerfer
2 siblings, 1 reply; 7+ messages in thread
From: Caleb James DeLisle @ 2026-07-28 18:49 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, robh, krzk+dt, conor+dt, tsbogend, devicetree,
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
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH 2/2] mips: dts: econet: Describe dual-VPE 34Kc processor
2026-07-28 18:49 ` [PATCH 2/2] mips: dts: econet: Describe dual-VPE 34Kc processor Caleb James DeLisle
@ 2026-07-28 19:09 ` sashiko-bot
0 siblings, 0 replies; 7+ messages in thread
From: sashiko-bot @ 2026-07-28 19:09 UTC (permalink / raw)
To: Caleb James DeLisle; +Cc: robh, devicetree, conor+dt
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 0/2] mips: econet: add multi-vpe capability to EN751221
2026-07-28 18:49 [PATCH 0/2] mips: econet: add multi-vpe capability to EN751221 Caleb James DeLisle
2026-07-28 18:49 ` [PATCH 1/2] " Caleb James DeLisle
2026-07-28 18:49 ` [PATCH 2/2] mips: dts: econet: Describe dual-VPE 34Kc processor Caleb James DeLisle
@ 2026-08-03 13:14 ` Thomas Bogendoerfer
2 siblings, 0 replies; 7+ messages in thread
From: Thomas Bogendoerfer @ 2026-08-03 13:14 UTC (permalink / raw)
To: Caleb James DeLisle
Cc: linux-mips, linux-kernel, robh, krzk+dt, conor+dt, devicetree
On Tue, Jul 28, 2026 at 06:49:57PM +0000, Caleb James DeLisle wrote:
> 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(-)
series applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply [flat|nested] 7+ messages in thread