docs / driver-api: Fix structure references in device_link.rst

The format of the structure references in device_link.rst is
incorrect, because it doesn't cause proper references to the
struct data types to be generated (for struct dev_pm_domain in
particular).

Fix that by using the :c:type:`struct name <name>` convention
for encoding references to struct data types.

Fixes: aad800403a87 (Documentation/core-api/device_link: Add initial documentation)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

authored by

Rafael J. Wysocki and committed by
Jonathan Corbet
bd856262 e3941cd9

+10 -8
+10 -8
Documentation/driver-api/device_link.rst
··· 1 ============ 2 Device links 3 ============ ··· 123 is the same as if the MMU was the parent of the master device. 124 125 The fact that both devices share the same power domain would normally 126 - suggest usage of a :c:type:`struct dev_pm_domain` or :c:type:`struct 127 - generic_pm_domain`, however these are not independent devices that 128 - happen to share a power switch, but rather the MMU device serves the 129 - busmaster device and is useless without it. A device link creates a 130 - synthetic hierarchical relationship between the devices and is thus 131 - more apt. 132 133 * A Thunderbolt host controller comprises a number of PCIe hotplug ports 134 and an NHI device to manage the PCIe switch. On resume from system sleep, ··· 159 Alternatives 160 ============ 161 162 - * A :c:type:`struct dev_pm_domain` can be used to override the bus, 163 class or device type callbacks. It is intended for devices sharing 164 a single on/off switch, however it does not guarantee a specific 165 suspend/resume ordering, this needs to be implemented separately. ··· 168 suspended. Furthermore it cannot be used to enforce a specific shutdown 169 ordering or a driver presence dependency. 170 171 - * A :c:type:`struct generic_pm_domain` is a lot more heavyweight than a 172 device link and does not allow for shutdown ordering or driver presence 173 dependencies. It also cannot be used on ACPI systems. 174
··· 1 + .. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain <dev_pm_domain>` 2 + .. |struct generic_pm_domain| replace:: :c:type:`struct generic_pm_domain <generic_pm_domain>` 3 + 4 ============ 5 Device links 6 ============ ··· 120 is the same as if the MMU was the parent of the master device. 121 122 The fact that both devices share the same power domain would normally 123 + suggest usage of a |struct dev_pm_domain| or |struct generic_pm_domain|, 124 + however these are not independent devices that happen to share a power 125 + switch, but rather the MMU device serves the busmaster device and is 126 + useless without it. A device link creates a synthetic hierarchical 127 + relationship between the devices and is thus more apt. 128 129 * A Thunderbolt host controller comprises a number of PCIe hotplug ports 130 and an NHI device to manage the PCIe switch. On resume from system sleep, ··· 157 Alternatives 158 ============ 159 160 + * A |struct dev_pm_domain| can be used to override the bus, 161 class or device type callbacks. It is intended for devices sharing 162 a single on/off switch, however it does not guarantee a specific 163 suspend/resume ordering, this needs to be implemented separately. ··· 166 suspended. Furthermore it cannot be used to enforce a specific shutdown 167 ordering or a driver presence dependency. 168 169 + * A |struct generic_pm_domain| is a lot more heavyweight than a 170 device link and does not allow for shutdown ordering or driver presence 171 dependencies. It also cannot be used on ACPI systems. 172