Re: [PATCH net-next v3 0/4] driver core, net: handle fw_devlink for class devices and PHY packages

On Tue, Aug 18, 2026 at 12:58:56AM -0600, James Hilliard wrote:

Managed device links normally advance through probe and removal alongside
a device driver. Driverless class devices are added directly, so their
links do not currently receive equivalent transitions. A class supplier
can leave its consumers dormant, while sync-state-only links from a class
consumer can indefinitely prevent suppliers from receiving sync_state().
Removal also does not unbind consumers of a class supplier.

Ethernet PHY packages expose both sides of this problem. A package node
describes resources shared by member PHYs, but is a container rather than
a device. fw_devlink preserves that topology and temporarily represents
those dependencies through the closest device, which for OF MDIO is the
driverless MDIO bus class device. Its proxy links previously remained
after the real PHY had probed and kept the package suppliers from reaching
sync_state().

Handle the generic class-device lifecycle in the driver core. Put
driverless class devices into the probing state while device_add()
publishes them, complete their incoming and outgoing managed links after
class interfaces run, and apply the corresponding unbind and cleanup
transitions during device_del(). This supports class devices as either
suppliers or consumers and keeps descendant firmware links available for
devices created later. Keep inferred links to probing and registered class
suppliers out of no-driver fallback paths, and recognize class-backed
nodes when refreshing dependencies after firmware-tree overlays.

Keep generic firmware parsing faithful to the described topology. Add a
helper through which a subsystem can copy a container node's direct
supplier links onto the firmware node for a real child device, then use it
from PHY registration before device_add(). The ordinary fw_devlink path
consequently creates each managed PHY link at the normal
device-registration stage.

Finally, defer supplier sync-state callbacks across OF MDIO bus
registration and child population. This closes the interval between
completion of the bus class device and installation of the member PHY
links without adding an MDIO-specific device-link state transition.

This was found while validating an X-Powers AC300 package whose input
clock is supplied by PWM. Before the fix, the PWM driver reported that
sync_state() was pending due to stmmac-0 after the PHY had probed.

The complete series was tested on an Allwinner H616 board with an X-Powers
AC300 PHY package. All five package-derived supplier links targeted the
member PHY and no proxy link remained on the driverless MDIO bus. The PWM
supplier reached state_synced while continuing to generate the PHY clock.
These properties remained true after unbinding and rebinding the MAC, and
the PHY renegotiated a 100 Mbps full-duplex link. Both before and after
that lifecycle test, 8 MiB transfers in each direction compared correctly
and 100 consecutive pings completed without loss.

Validation also included:

  - a full arm64 defconfig Image and modules build with W=1;
  - KUnit tests for class supplier/consumer transitions, inferred-link
    preservation, and fwnode supplier copying and device-link conversion;
    and
  - strict per-patch checkpatch and whitespace checks.

Assisted-by: Codex:gpt-5.6-sol

Seems the commit messages are also copy'n'pasted from AI. Please, make sure
that it's clear, straight to the point and not a saga with unneeded details
and obvious explanations.

-- 
With Best Regards,
Andy Shevchenko