Lines Matching +full:on +full:- +full:device
5 Device links
9 that are borne out of a parent/child relationship within the device
11 are ordered based on this relationship, i.e. children are always suspended
14 Sometimes there is a need to represent device dependencies beyond the
19 dependencies, i.e. that one device must be bound to a driver before
22 Often these two dependency types come together, so a device depends on
26 Device links allow representation of such dependencies in the driver core.
28 In its standard or *managed* form, a device link combines *both* dependency
30 "supplier" device and its "consumer" devices, and it guarantees driver
31 presence on the supplier. The consumer devices are not probed before the
35 When driver presence on the supplier is irrelevant and only correct
36 suspend/resume and shutdown ordering is needed, the device link may
38 enforcing driver presence on the supplier is optional.
41 ``DL_FLAG_PM_RUNTIME`` flag on addition of the device link, the PM core
48 The earliest point in time when device links can be added is after
53 remains in a consistent state: E.g. a device link cannot be added in
56 or the device link needs to be added from a function which is guaranteed
58 device ``->probe`` callback or a boot-time PCI quirk.
60 Another example for an inconsistent state would be a device link that
62 ``->probe`` callback while the supplier hasn't started to probe yet: Had the
63 driver core known about the device link earlier, it wouldn't have probed the
64 consumer in the first place. The onus is thus on the consumer to check
65 presence of the supplier after adding the link, and defer probing on
66 non-presence. [Note that it is valid to create a link from the consumer's
67 ``->probe`` callback while the supplier is still probing, but the consumer must
72 If a device link with ``DL_FLAG_STATELESS`` set (i.e. a stateless device link)
73 is added in the ``->probe`` callback of the supplier or consumer driver, it is
74 typically deleted in its ``->remove`` callback for symmetry. That way, if the
75 driver is compiled as a module, the device link is added on module load and
76 orderly deleted on unload. The same restrictions that apply to device link
78 to deletion. Device links managed by the driver core are deleted automatically
81 Several flags may be specified on device link addition, two of which
87 Two other flags are specifically targeted at use cases where the device
88 link is added from the consumer's ``->probe`` callback: ``DL_FLAG_RPM_ACTIVE``
90 device link. ``DL_FLAG_AUTOREMOVE_CONSUMER`` causes the device link to be
93 Similarly, when the device link is added from supplier's ``->probe`` callback,
94 ``DL_FLAG_AUTOREMOVE_SUPPLIER`` causes the device link to be automatically
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.
110 device links (i.e. when ``DL_FLAG_STATELESS`` is not specified on link addition)
116 Moreover, managed device links cannot be deleted directly. They are deleted
119 However, stateless device links (i.e. device links with ``DL_FLAG_STATELESS``
124 Sometimes drivers depend on optional resources. They are able to operate
128 resources at probe time but on non-presence there is no way to know whether
133 for drivers as switching between modes of operation at runtime based on the
135 based on probe deferral. In any case optional resources are beyond the
136 scope of device links.
141 * An MMU device exists alongside a busmaster device, both are in the same
143 device and shall be runtime resumed and kept active whenever and as long
144 as the busmaster device is active. The busmaster device's driver shall
145 not bind before the MMU is bound. To achieve this, a device link with
146 runtime PM integration is added from the busmaster device (consumer)
147 to the MMU device (supplier). The effect with regards to runtime PM
148 is the same as if the MMU was the parent of the master device.
153 switch, but rather the MMU device serves the busmaster device and is
154 useless without it. A device link creates a synthetic hierarchical
158 and an NHI device to manage the PCIe switch. On resume from system sleep,
159 the NHI device needs to re-establish PCI tunnels to attached devices
163 device links from the hotplug ports (consumers) to the NHI device
168 for HDMI/DP audio. In the device hierarchy the HDA controller is a sibling
169 of the VGA device, yet both share the same power domain and the HDA
171 VGA device. A device link from the HDA controller (consumer) to the
172 VGA device (supplier) aptly represents this relationship.
174 * ACPI allows definition of a device start order by way of _DEP objects.
175 A classical example is when ACPI power management methods on one device
178 management of the device in question to work.
181 video processing IP cores on transparent memory access IP cores that handle
188 class or device type callbacks. It is intended for devices sharing
189 a single on/off switch, however it does not guarantee a specific
197 device link and does not allow for shutdown ordering or driver presence
198 dependencies. It also cannot be used on ACPI systems.
203 The device hierarchy, which -- as the name implies -- is a tree,
204 becomes a directed acyclic graph once device links are added.
208 no device links present, the two lists are a flattened, one-dimensional
209 representations of the device tree such that a device is placed behind
211 or OpenFirmware device tree top-down and appending devices to the lists
214 Once device links are added, the lists need to satisfy the additional
215 constraint that a device is placed behind all its suppliers, recursively.
216 To ensure this, upon addition of the device link the consumer and the
217 entire sub-graph below it (all children and consumers of the consumer)
222 verified upon device link addition that the supplier is not dependent
223 on the consumer or any children or consumers of the consumer.
228 Notably this also prevents the addition of a device link from a parent
229 device to a child. However the converse is allowed, i.e. a device link
232 such a device link only makes sense if a driver presence dependency is
233 needed on top of that. In this case driver authors should weigh
234 carefully if a device link is at all the right tool for the purpose.
236 add a device flag causing the parent driver to be probed before the
242 .. kernel-doc:: include/linux/device.h
255 * The initial state of a device link is automatically determined by
256 :c:func:`device_link_add()` based on the driver presence on the supplier
260 * When a supplier device is bound to a driver, links to its consumers
265 * Before a consumer device is probed, presence of supplier drivers is
280 * When the consumer's driver is later on removed, links to suppliers revert
305 .. kernel-doc:: drivers/base/core.c