Lines Matching +full:a +full:- +full:c
8 that are borne out of a parent/child relationship within the device
13 Sometimes there is a need to represent device dependencies beyond the
18 dependencies, i.e. that one device must be bound to a driver before
21 Often these two dependency types come together, so a device depends on
27 In its standard or *managed* form, a device link combines *both* dependency
28 types: It guarantees correct suspend/resume and shutdown ordering between a
31 supplier is bound to a driver, and they're unbound before the supplier
48 :c:func:`device_add()` has been called for the supplier and
49 :c:func:`device_initialize()` has been called for the consumer.
52 remains in a consistent state: E.g. a device link cannot be added in
53 the midst of a suspend/resume transition, so either commencement of
54 such a transition needs to be prevented with :c:func:`lock_system_sleep()`,
55 or the device link needs to be added from a function which is guaranteed
56 not to run in parallel to a suspend/resume transition, such as from a
57 device ``->probe`` callback or a boot-time PCI quirk.
59 Another example for an inconsistent state would be a device link that
60 represents a driver presence dependency, yet is added from the consumer's
61 ``->probe`` callback while the supplier hasn't started to probe yet: Had the
65 non-presence. [Note that it is valid to create a link from the consumer's
66 ``->probe`` callback while the supplier is still probing, but the consumer must
71 If a device link with ``DL_FLAG_STATELESS`` set (i.e. a stateless device link)
72 is added in the ``->probe`` callback of the supplier or consumer driver, it is
73 typically deleted in its ``->remove`` callback for symmetry. That way, if the
74 driver is compiled as a module, the device link is added on module load and
76 addition (e.g. exclusion of a parallel suspend/resume transition) apply equally
87 link is added from the consumer's ``->probe`` callback: ``DL_FLAG_RPM_ACTIVE``
93 Similarly, when the device link is added from supplier's ``->probe`` callback,
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
112 a problem if the consumer is required to probe before a certain initcall level
120 set) are expected to be removed by whoever called :c:func:`device_link_add()`
121 to add them with the help of either :c:func:`device_link_del()` or
122 :c:func:`device_link_remove()`.
125 :c:func:`device_link_add()` may cause the PM-runtime usage counter of the
126 supplier device to remain nonzero after a subsequent invocation of either
127 :c:func:`device_link_del()` or :c:func:`device_link_remove()` to remove the
128 device link returned by it. This happens if :c:func:`device_link_add()` is
129 called twice in a row for the same consumer-supplier pair without removing the
130 link between these calls, in which case allowing the PM-runtime usage counter
132 suspended while the consumer is still PM-runtime-active and that has to be
134 runtime suspend at least once, or call :c:func:`pm_runtime_set_suspended()` for
135 it with PM-runtime disabled, between the :c:func:`device_link_add()` and
136 :c:func:`device_link_del()` or :c:func:`device_link_remove()` calls.]
139 in a degraded mode (reduced feature set or performance) when those resources
140 are not present. An example is an SPI controller that can use a DMA engine
142 resources at probe time but on non-presence there is no way to know whether
143 they will become available in the near future (due to a supplier driver
146 resources become available after probing, but it would come at a high cost
148 availability of such resources would be much more complex than a mechanism
155 * An MMU device exists alongside a busmaster device, both are in the same
159 not bind before the MMU is bound. To achieve this, a device link with
165 suggest usage of a struct dev_pm_domain or struct generic_pm_domain,
166 however these are not independent devices that happen to share a power
168 useless without it. A device link creates a synthetic hierarchical
171 * A Thunderbolt host controller comprises a number of PCIe hotplug ports
173 the NHI device needs to re-establish PCI tunnels to attached devices
178 (supplier). A driver presence dependency is not necessary for this
182 for HDMI/DP audio. In the device hierarchy the HDA controller is a sibling
185 VGA device. A device link from the HDA controller (consumer) to the
188 * ACPI allows definition of a device start order by way of _DEP objects.
189 A classical example is when ACPI power management methods on one device
190 are implemented in terms of I\ :sup:`2`\ C accesses and require a specific
191 I\ :sup:`2`\ C controller to be present and functional for the power
194 * In some SoCs a functional dependency exists from display, video codec and
201 * A struct dev_pm_domain can be used to override the bus,
203 a single on/off switch, however it does not guarantee a specific
207 suspended. Furthermore it cannot be used to enforce a specific shutdown
208 ordering or a driver presence dependency.
210 * A struct generic_pm_domain is a lot more heavyweight than a
217 The device hierarchy, which -- as the name implies -- is a tree,
218 becomes a directed acyclic graph once device links are added.
222 no device links present, the two lists are a flattened, one-dimensional
223 representations of the device tree such that a device is placed behind
225 or OpenFirmware device tree top-down and appending devices to the lists
229 constraint that a device is placed behind all its suppliers, recursively.
231 entire sub-graph below it (all children and consumers of the consumer)
232 are moved to the end of the list. (Call to :c:func:`device_reorder_to_tail()`
233 from :c:func:`device_link_add()`.)
238 (Call to :c:func:`device_is_dependent()` from :c:func:`device_link_add()`.)
239 If that constraint is violated, :c:func:`device_link_add()` will return
240 ``NULL`` and a ``WARNING`` will be logged.
242 Notably this also prevents the addition of a device link from a parent
243 device to a child. However the converse is allowed, i.e. a device link
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
248 carefully if a device link is at all the right tool for the purpose.
249 A more suitable approach might be to simply use deferred probing or
250 add a device flag causing the parent driver to be probed before the
256 .. kernel-doc:: include/linux/device.h
269 * The initial state of a device link is automatically determined by
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
276 (Call to :c:func:`device_links_driver_bound()` from
277 :c:func:`driver_bound()`.)
279 * Before a consumer device is probed, presence of supplier drivers is
283 (Call to :c:func:`device_links_check_suppliers()` from
284 :c:func:`really_probe()`.)
286 (Call to :c:func:`wait_for_device_probe()` from
287 :c:func:`device_links_unbind_consumers()`.)
290 (Call to :c:func:`device_links_no_driver()` from :c:func:`really_probe()`.)
293 (Call to :c:func:`device_links_driver_bound()` from :c:func:`driver_bound()`.)
297 (Call to :c:func:`__device_links_no_driver()` from
298 :c:func:`device_links_driver_cleanup()`, which in turn is called from
299 :c:func:`__device_release_driver()`.)
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``.
303 (Call to :c:func:`device_links_busy()` from
304 :c:func:`__device_release_driver()`.)
306 (Call to :c:func:`device_links_check_suppliers()` from
307 :c:func:`really_probe()`.)
310 (Call to :c:func:`device_links_unbind_consumers()` from
311 :c:func:`__device_release_driver()`.)
314 (Call to :c:func:`device_links_driver_cleanup()` from
315 :c:func:`__device_release_driver()`.)