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