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

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