Lines Matching +full:in +full:- +full:between
7 By default, the driver core only enforces dependencies between devices
14 mere parent/child relationship, e.g. between siblings, and have the
25 Device links allow representation of such dependencies in the driver core.
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
36 simply be set up with the ``DL_FLAG_STATELESS`` flag. In other words,
47 The earliest point in time when device links can be added is after
52 remains in a consistent state: E.g. a device link cannot be added in
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.
61 ``->probe`` callback while the supplier hasn't started to probe yet: Had the
63 consumer in the first place. The onus is thus on the consumer to check
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
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
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,
117 by the driver core when they are not necessary any more in accordance with the
125 :c:func:`device_link_add()` may cause the PM-runtime usage counter of the
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
135 it with PM-runtime disabled, between the :c:func:`device_link_add()` and
139 in a degraded mode (reduced feature set or performance) when those resources
141 or work in PIO mode. The controller can determine presence of the optional
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
147 for drivers as switching between modes of operation at runtime based on the
149 based on probe deferral. In any case optional resources are beyond the
155 * An MMU device exists alongside a busmaster device, both are in the same
169 relationship between the devices and is thus more apt.
173 the NHI device needs to re-establish PCI tunnels to attached devices
181 * Discrete GPUs in hybrid graphics laptops often feature an HDA controller
182 for HDMI/DP audio. In the device hierarchy the HDA controller is a sibling
190 are implemented in terms of I\ :sup:`2`\ C accesses and require a specific
192 management of the device in question to work.
194 * In some SoCs a functional dependency exists from display, video codec and
217 The device hierarchy, which -- as the name implies -- is a tree,
222 no device links present, the two lists are a flattened, one-dimensional
225 or OpenFirmware device tree top-down and appending devices to the lists
231 entire sub-graph below it (all children and consumers of the consumer)
245 correct suspend/resume and shutdown ordering between parent and child,
247 needed on top of that. In this case driver authors should weigh
256 .. kernel-doc:: include/linux/device.h
280 verified by checking the consumer device is not in the wait_for_suppliers
281 list and by checking that links to suppliers are in ``DL_STATE_AVAILABLE``
298 :c:func:`device_links_driver_cleanup()`, which in turn is called from
312 Once all links to consumers are in ``DL_STATE_SUPPLIER_UNBIND`` state,