Re: [PATCH net-next v16 0/6] net: dsa: mxl862xx: devlink flash and rescue

[Daniel Golle <daniel@makrotopia.org>]

On Fri, 18 Sep 2026 18:07:09 -0700 Jakub Kicinski wrote:
> Having the "rescue mode" which only allows flashing a better / working
> FW is fairly common these days. Did you consider driving the operation
> more from user space. Let the user devlink reload into flashing mode,
> and devlink reload back into normal operation mode?

The reload plumbing itself would look much like the flash_update hook
this series adds: reload_up/reload_down trampolines in the shared
dsa_devlink_ops forwarding to new dsa_switch_ops callbacks, plus
reload_actions. So "DSA has no reload" is not really the obstacle.

The difference is what the callbacks have to do. flash_update is a
pure forward to the driver. reload_* has to reinitialise the switch
while its devlink instance stays alive, since the reload command runs
through it. In DSA that instance is allocated and freed inside
dsa_switch_setup() and dsa_switch_teardown(), bracketing
ops->setup()/ops->teardown(), and the ports, tagger and user netdevs
come up a level higher in dsa_tree_setup(). So reload would need a new
DSA-core path that reinitialises a switch, and its ports, without
tearing down its devlink instance, and in a multi-switch tree touches
only the one switch.

The deferred re-probe avoids all of that by reusing the existing
unbind/register path, which rebuilds everything, a fresh devlink
instance included, so it needs nothing new in the DSA core. And the
helper it uses, device_schedule_reprobe(), is not something this
series invents just to sidestep reload: it should also replace the
open-coded deferred self-reprobe that iwlwifi, hci_h5 and btintel_pcie
already carry[1], where the work function ends by freeing its own
module text from under a racing rmmod. It is worth having on that
merit alone, with mxl862xx its first user and those conversions to
follow. So the re-probe leans on driver-core infrastructure that is
useful regardless; driving this through devlink reload instead would
add the DSA-core reinit path in addition to that helper, which those
three drivers still want, so it is more new code overall than a swap.

For that reason, and because the re-probe is what I have tested, I would
rather keep it, but I will add the DSA reload path if you feel firmware
activation on DSA should go through devlink reload. Either way the
rescue-mode detection at probe stays, since a switch found in MCUboot
has to register something for devlink to be reachable at all.

Cheers,

Daniel

[1]: https://lore.kernel.org/all/cover.1787281239.git.daniel@makrotopia.org/