mt7530_remove_common() disposes the per-PHY interrupt mappings first and unregisters the switch second, but phylib only frees those interrupts inside dsa_unregister_switch(). Unbinding the driver therefore frees descriptors that are still in use, and the switch's own regmap-irq thread takes a nested interrupt on one that is already gone. Fixes: ba751e28d442 ("net: dsa: mt7530: add interrupt support") Signed-off-by: Aleksei Sviridkin Assisted-by: LLM --- Found on a Netcraze NC-1012 (MT7981B + MT7531, 6.18.44) directly behind the regulator fix in patch 1: with that one applied the unbind stops faulting in mt7530_remove() and reaches the teardown, where the kernel says what is wrong in words before it dies. # echo mdio-bus:1f > /sys/bus/mdio_bus/drivers/mt7530-mdio/unbind remove_proc_entry: removing non-empty directory 'irq/81', leaking at least 'mt7530-0:02' WARNING: CPU: 0 PID: 4629 at remove_proc_entry+0x1d0/0x1f0 ... mt7530_remove_common+0x1c/0x30 mt7530_remove+0x24/0x90 mdio_remove+0x20/0x40 unbind_store+0xac/0xb0 Unable to handle kernel read from unreadable memory at virtual address 00000000000000ac pc : handle_nested_irq+0x28/0x168 Kernel panic - not syncing: Oops: Fatal exception The WARN comes from unregister_irq_proc() under irq_free_descs(), fired for a mapping that a PHY still holds. The captured record shows one, for mt7530-0:02, and already carries the W taint bit, so at least one earlier WARN fell outside the ramoops window. 294 ms later the switch's own regmap-irq thread - PID 627, Comm irq/53-mt7530 - takes a nested interrupt for a mapping that is already gone: irq_find_mapping() returns 0, irq_to_desc() returns NULL and handle_nested_irq() locks desc->lock without checking, which is the read at +0xac in the trace. Both timestamps are from the same ramoops record. Reach is wider than the board that found it. mt7530_remove_common() is called from both front ends - mt7530-mdio.c and mt7530-mmio.c - so it covers the MMIO parts as well, which have no regulators at all and never meet the defect patch 1 fixes. What decides whether a given switch is hit is not the irq_domain but whether the PHY interrupts are mapped on it. Either mt7530_setup_mdio_irq() created those mappings, which it only does when the devicetree has no mdio node under the switch, or OF created them from per-PHY interrupts properties when it has one. A switch with an irq_domain and neither is left alone: irq_find_mapping() returns 0 for every port and irq_dispose_mapping(0) returns at once. The teardown is guarded on the domain alone, so it walks that loop either way. Tested on the board above, with both patches applied. Two unbind/bind cycles back to back: each unbind removed mdio-bus:1f from the driver directory and took lan1-lan4 with it, each bind brought them back, and the two cabled ports relinked at 1Gbps/full. uptime went from 167 to 183 across both cycles without resetting, and pstore gained no new record. dmesg carries one unrelated WARN, from sysfs_remove_link() under dsa_user_destroy() - a separate DSA teardown-ordering defect, handled on its own - and it fired once, on the first unbind, not on the second. Not tested: any MMIO part - there is no MT7988, EN7581, AN7583 or EN7528 hardware here. The object file was checked instead: after the change mt7530_remove_common() calls dsa_unregister_switch() first and only then tests priv->irq_domain and calls mt7530_free_mdio_irq(). Built with W=1, no warnings; checkpatch --strict clean. drivers/net/dsa/mt7530.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c index 3e61eb3c2b1e..90fd04665ebf 100644 --- a/drivers/net/dsa/mt7530.c +++ b/drivers/net/dsa/mt7530.c @@ -3593,11 +3593,11 @@ EXPORT_SYMBOL_GPL(mt7530_probe_common); void mt7530_remove_common(struct mt7530_priv *priv) { + dsa_unregister_switch(priv->ds); + if (priv->irq_domain) mt7530_free_mdio_irq(priv); - dsa_unregister_switch(priv->ds); - mutex_destroy(&priv->reg_mutex); } EXPORT_SYMBOL_GPL(mt7530_remove_common); -- 2.53.0