Re: [PATCH RFC net-next 3/3] net: dsa: mxl862xx: add devlink flash_update and info_get

[Daniel Golle]

On Thu, Jul 09, 2026 at 01:24:49AM +0200, Andrew Lunn wrote:
> On Wed, Jul 08, 2026 at 10:02:39PM +0200, Daniel Golle wrote:
> > On Wed, Jul 08, 2026 at 07:27:21PM +0200, Andrew Lunn wrote:
> > > > + * The flash process takes approximately 15 minutes. Progress is
> > > > + * reported via devlink status notifications. After a successful (or
> > > > + * failed) flash the driver reprobes the device automatically.
> > > 
> > > Have you tested the failed use case?
> > > 
> > > I assume if the firmware in the flash is invalid, the bootloader does
> > > not boot it, and it remains in the bootloader waiting for another
> > > attempt. Does this DSA driver still load, so devlink can be used to
> > > try again?
> > 
> > No. Without a running the firmware the driver doesn't probe and only
> > a special rescue tool allows to recover the hardware.
> > Having the DSA driver detect the presence of the switch stuck in
> > mcuboot mode and probe without registering any user or CPU ports
> > also isn't straight forward.
> 
> And that special rescue tool exists?

Yes, but it's basically a custom bootable Linux image, based on a
patched/old Linux Kernel and vendor SDK driver.
It cannot just run from userspace because (apart from the out-of-tree
mdio-netlink API) there isn't any standard way to access the MDIO bus
from userspace.

> Why not wrap it in a script which unloads the DSA driver, let it do
> its thing, and then reload the DSA driver?

It would need to be yet another driver binding the device on the
MDIO bus, check if the mcuboot C22 MDIO interface responds and if not
fire the firmware API request to put reset the device into mcuboot mode.
And this, issueing a firmware API command, is why it is easier to make
it part of the existing DSA driver which already got a robust and
endian-safe implementation of the firmware API protocol.

> All the other users of devlink flash that i know of can operate while
> the device is still running. So it makes sense for it to be part of
> the driver, it is something just going on in the background. This
> device is different, so i don't really see the advantage of making it
> part of the driver.

The controlled teardown/reprobe/reconfigure as well as the ability to
issue the reboot-into-mcuboot firmware API command are good arguments
imho.