Re: [PATCH net-next v3 4/4] driver core: handle managed links for class devices

[Andy Shevchenko]

On Tue, Aug 18, 2026 at 12:59:00AM -0600, James Hilliard wrote:
> fw_devlink deliberately lets the nearest device pick up dependencies below
> class-backed firmware nodes because driverless class devices do not
> currently progress through managed device-link states. This can leave
> consumers of class suppliers dormant, while sync-state-only links from
> class consumers never reach the successful-probe cleanup.
> 
> Track class-only devices through equivalent registration and removal
> transitions. Mark them probing before device_add() publishes them, complete
> their incoming and outgoing links after class interfaces run, and enter the
> unbind and no-driver states during device_del(). Preserve firmware links
> below class-backed nodes so later-created descendants can acquire their own
> links.
> 
> Include class registration in wait_for_device_probe() so supplier unbind
> cannot race a class consumer that is still being published. Transition
> managed links which existed before device_add(), remove stale
> waiting_for_supplier attributes and do not revive a link whose supplier has
> already started unbinding.
> 
> During supplier teardown, wait for class registration to finish, but move
> an already registered class consumer directly to the unbinding link state
> because it has no driver to release. Keep consumer-autoremove links valid
> until class consumer removal without triggering driver-only cleanup
> warnings.
> 
> Factor the supplier-bound, consumer-bound and cleanup transitions shared
> with driver-backed devices. Activate late links involving an already
> functional class endpoint instead of trying to reprobe it, and let
> sync-state-only links retire without forcing consumer unbind. Ordinary
> supplier links cannot defer class registration, so they must not be the
> only mechanism on which a class consumer relies for functionality.
> 
> Class devices do not match drivers, so distinguish a genuinely unavailable
> supplier from a probing or registered class endpoint before relaxing
> inferred links. Preserve normal probe and runtime-PM ordering for those
> links. Also recognize class-backed nodes when refreshing dependencies after
> firmware-tree overlays.
> 
> Exclude the internal device-link class because device-link objects are
> registered while the device-links lock is held. Document the class-device
> state transitions and add KUnit coverage for supplier and consumer links,
> pre-existing links, inferred-link preservation, registration waiters and a
> concurrent supplier unbind.

This is enormous change, can it be split to several logically isolated patches?

-- 
With Best Regards,
Andy Shevchenko