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

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