)]}'
{
  "commit": "0b2bbfee2bcb80017d4d47e94f8dc92151dcdd6f",
  "tree": "9892ecb81b45e3c167a52d22d17f3e851ed13f50",
  "parents": [
    "7c9f391ec89cb621d7af375ace2eb9a6248e5b9d",
    "0d80ba0a204c6a16bd7778b50de578dff107c0fe"
  ],
  "author": {
    "name": "Jakub Kicinski",
    "email": "kuba@kernel.org",
    "time": "Thu Sep 24 08:16:58 2026 -0700"
  },
  "committer": {
    "name": "Jakub Kicinski",
    "email": "kuba@kernel.org",
    "time": "Thu Sep 24 08:16:58 2026 -0700"
  },
  "message": "Merge branch \u0027net-dsa-mt7530-fix-two-crashes-on-driver-unbind\u0027\n\nAleksei Sviridkin says:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nnet: dsa: mt7530: fix two crashes on driver unbind\n\nUnbinding the MT7530 driver from an MT7531 dereferences NULL in\nregulator_disable(). On a Netcraze NC-1012 (MT7981B + MT7531, 6.18.44):\n\n  # echo mdio-bus:1f \u003e /sys/bus/mdio_bus/drivers/mt7530-mdio/unbind\n\noopses there, and the build it was found on sets CONFIG_PANIC_ON_OOPS, so\nthe board goes down with it. Fix that and the same command gets as far as\nmt7530_remove_common(), which disposes interrupt mappings the switch\u0027s own\nregmap-irq chip still owns; the regmap-irq thread then faults in\nhandle_nested_irq() later in the same teardown. rmmod reaches both, since\nmdio_module_driver() calls .remove on module exit.\n\nPatch 1 is the regulator one. mt7530_probe() requests the core and io\nsupplies only for ID_MT7530 and mt7530_setup() enables them under the same\ntest, but mt7530_remove() disables them unconditionally, so on an MT7621 or\nan MT7531 both pointers are still NULL from devm_kzalloc(). It reaches the\nMDIO front end only.\n\nPatch 2 is the interrupt one, and it reaches further.\nmt7530_remove_common() disposes the per-PHY interrupt mappings by hand from\n.remove, while the regmap-irq chip that owns the domain is devm-registered\nand its parent interrupt is only freed once .remove has returned.\nregmap_del_irq_chip() disposes the same mappings itself, in an order that\ncannot race, so the driver\u0027s call adds nothing but a window. That helper is\ncalled from both front ends, so the defect also covers the MMIO parts -\nMT7988, EN7581, AN7583 and EN7528 - which have no regulators and never meet\nthe first defect at all.\n\nThe order is not arbitrary. On an MT7531 the regulator fault happens in the\nfirst thing mt7530_remove() does with the switch, so execution never\nreaches the interrupt defect. The second only became visible once the first\nwas fixed, which is also how both came to be found on one board.\n\nFound and verified there. Without patch 1 the unbind panics in\nregulator_disable(); with patch 1 alone the panic moves on to\nhandle_nested_irq(); with both, three unbind/bind cycles run, two back to\nback and a third after a pause. In the two whose dmesg was captured, each\nunbind removes the switch from the driver directory and takes lan1 to lan4\nwith it, each bind brings them back, and lan1 relinks at 1Gbps/full after\nboth binds, lan4 after the second. uptime rose from 58 to 202 seconds\nacross the three without resetting and pstore gained no new record. The\nthird cycle stayed unbound long enough to read the descriptors: no mt7530\nline in /proc/interrupts and no irq/79, irq/80 or irq/81 directory, and the\nnext bind reuses those three numbers - regmap-irq freeing and disposing\nwhat the driver no longer touches. The kernel under test was identified by\nthe sha256 of its ELF notes section, read from /sys/kernel/notes on the\nrunning board and computed in advance from the flashed image.\n\nWhat hardware could not answer here. There is no MT7530 or MT7621 part on\nthis bench, so the ID_MT7530 branch that patch 1 adds was checked by\nreading the generated code rather than by running it, and no MMIO part was\navailable to exercise patch 2 on that front end either. One unrelated WARN\nremains across the unbind, from sysfs_remove_link() under\ndsa_user_destroy(); it is a separate DSA teardown-ordering defect and is\nnot addressed here.\n\nv1: https://lore.kernel.org/20260914202421.2737079-1-f@lex.la\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nLink: https://patch.msgid.link/20260918015020.2518315-1-f@lex.la\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n",
  "tree_diff": []
}