Re: [PATCH net-next v13 4/6] net: dsa: mxl862xx: add devlink flash_update and info_get

[Andrew Lunn <andrew@lunn.ch>]

On Mon, Sep 07, 2026 at 07:38:28PM +0100, Daniel Golle wrote:
> Implement runtime firmware upgrade via "devlink dev flash" and version
> reporting via "devlink dev info":
> 
>   $ devlink dev info mdio_bus/mdio-bus:10
>   mdio_bus/mdio-bus:10:
>     driver mxl862xx
>     versions:
>         fixed:
>           asic.id 8628
>           asic.rev 0
>         running:
>           fw 1.0.70
>         stored:
>           fw 1.0.70
> 
> The "asic.id" and "asic.rev" fixed versions carry the numeric chip part
> number and revision from the static CHIP ID registers (SYS_MISC_REG_RD),
> which userspace such as fwupd matches firmware against; they are omitted
> if the read fails or the part is unfused, so no bogus "0000" is
> published. The switch boots its firmware from its own flash, so "fw" is
> reported as both the running and the stored version; a flashless part
> would omit "stored", distinguishing the two without an API change.
> 
>   $ devlink dev flash mdio_bus/mdio-bus:10 file mxl862xx-fw.bin
> 
> The image, including both payload CRCs, is validated first, so a
> malformed file is rejected without disturbing the running switch. The
> driver then sends SYS_MISC_FW_UPDATE, which reboots the switch into its
> MCUboot bootloader, and transfers the signed image over the SB PDI
> protocol (clause-22 SMDIO), checking every write: a failed address write
> at the half-bank boundary would otherwise misplace half the payload
> unnoticed. A successful transfer reboots the switch into the new
> firmware. The loader verifies the image once the last slice has been
> programmed and publishes the verdict, so a rejected image is reported as
> such rather than as a transfer timeout. The whole cycle takes just under
> a minute.
> 
> For its duration the driver closes all user and conduit interfaces and
> marks the user ports not-present with netif_device_detach() so userspace
> cannot reopen them; the conduit belongs to the MAC driver and is only
> closed. This also stops phylib polling the switch-internal PHYs,
> unreachable in MCUboot. The bridge's deferred STP DISABLED transitions
> are flushed under rtnl so they reach the firmware while it still runs;
> the stats poll and CRC error handler are stopped; and firmware API
> commands from other paths are blocked under the MDIO bus lock so none
> reaches the bus once the switch has rebooted. Progress is reported
> through devlink status notifications.
> 
> The switch leaves MCUboot on its own by booting the new image, but the
> driver has no in-place path back, so it reinitialises with a deferred
> re-probe scheduled regardless of the transfer outcome, using
> device_schedule_reprobe() from the previous patch. The helper's work
> runs in the driver core, off the devlink caller's locking and signal
> context, without this driver holding module or device references, and
> it skips the re-probe if the device is unbound or shut down before it
> fires, so a stale re-probe can neither undo an administrative unbind
> nor detach a device whose ->shutdown() has already run. During the
> teardown the driver's API reads return -ENODEV and writes fake success,
> so it neither stalls on the absent firmware nor consumes buffers it
> never filled; port_mdb_del() takes that -ENODEV for a MAC table that is
> gone and reports success, since there is nothing left to delete. A
> failed re-probe leaves the device unbound, exactly as a failed initial
> probe would, and a further flash is refused until it has run. An
> aborted transfer leaves the switch in MCUboot, where nothing here can
> reach it; the next patch adds the detection that makes such a switch
> flashable again.
> 
> Scheduling the re-probe can only fail on memory allocation, and only
> after the switch has already been flashed. -ENOMEM there is a
> system-wide condition that no driver-level message or recovery attempt
> improves, so it is returned as-is with no further action: the driver
> stays bound with its firmware API short-circuited, and unbinding and
> rebinding it runs the same teardown and fresh probe the re-probe would
> have.
> 
> The closed user ports and conduit are not returned to their pre-flash
> administrative state across the reprobe; userspace brings them back up,
> and restoring it in-driver would need DSA-core support that does not
> yet exist.
> 
> Assisted-by: LLM
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew