Documentation/driver-api/device_link.rst

7 By default, the driver core only enforces dependencies between devices
15 driver core automatically take care of them.
17 Secondly, the driver core by default does not enforce any driver presence
18 dependencies, i.e. that one device must be bound to a driver before
22 another one both with regards to driver presence *and* with regards to
25 Device links allow representation of such dependencies in the driver core.
29 "supplier" device and its "consumer" devices, and it guarantees driver
31 supplier is bound to a driver, and they're unbound before the supplier
34 When driver presence on the supplier is irrelevant and only correct
37 enforcing driver presence on the supplier is optional.
60 represents a driver presence dependency, yet is added from the consumer's
62 driver core known about the device link earlier, it wouldn't have probed the
72 is added in the ``->probe`` callback of the supplier or consumer driver, it is
74 driver is compiled as a module, the device link is added on module load and
77 to deletion.  Device links managed by the driver core are deleted automatically
82 driver presence dependency is needed (but only correct suspend/resume and
98 is set, ``DL_FLAG_AUTOPROBE_CONSUMER`` can be used to request the driver core
99 to probe for a driver for the consumer driver on the link automatically after
100 a driver has been bound to the supplier device.
109 Driver authors should be aware that a driver presence dependency for managed
113 is reached.  Worse, if the supplier driver is blacklisted or missing, the
117 by the driver core when they are not necessary any more in accordance with the
143 they will become available in the near future (due to a supplier driver
158   as the busmaster device is active.  The busmaster device's driver shall
178   (supplier).  A driver presence dependency is not necessary for this
208   ordering or a driver presence dependency.
211   device link and does not allow for shutdown ordering or driver presence
244 from a child to a parent.  Since the driver core already guarantees
246 such a device link only makes sense if a driver presence dependency is
247 needed on top of that.  In this case driver authors should weigh
250 add a device flag causing the parent driver to be probed before the
270   :c:func:`device_link_add()` based on the driver presence on the supplier
274 * When a supplier device is bound to a driver, links to its consumers
295 * When the consumer's driver is later on removed, links to suppliers revert
301 * Before a supplier's driver is removed, links to consumers that are not
302   bound to a driver are updated to ``DL_STATE_SUPPLIER_UNBIND``.
308   Consumers that are bound are freed from their driver; consumers that are
313   the supplier driver is released and the links revert to ``DL_STATE_DORMANT``.