Skip to content

Commit e3941cd

Browse files
rafaeljwJonathan Corbet
authored andcommitted
PM / docs: Fix structure references in device.rst
There is a better way to represent structure references than it was done in device.rst by commit 730c4c0 (PM / sleep / docs: Convert PM notifiers document to reST), which is to use "struct name" as a link caption (e.g. :c:type:`struct device <device>`). That will cause sphinx to generate a proper reference to the data type in question (struct device in the example above) and "struct name" will work as the link in the HTML output. Fix device.rst by using that convention where applicable. Fixes: 730c4c0 (PM / sleep / docs: Convert PM notifiers document to reST) Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]>
1 parent 62924fd commit e3941cd

File tree

1 file changed

+38
-34
lines changed

1 file changed

+38
-34
lines changed

Documentation/driver-api/pm/devices.rst

Lines changed: 38 additions & 34 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,10 @@
1-
.. |struct| replace:: :c:type:`struct`
1+
.. |struct dev_pm_ops| replace:: :c:type:`struct dev_pm_ops <dev_pm_ops>`
2+
.. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain <dev_pm_domain>`
3+
.. |struct bus_type| replace:: :c:type:`struct bus_type <bus_type>`
4+
.. |struct device_type| replace:: :c:type:`struct device_type <device_type>`
5+
.. |struct class| replace:: :c:type:`struct class <class>`
6+
.. |struct wakeup_source| replace:: :c:type:`struct wakeup_source <wakeup_source>`
7+
.. |struct device| replace:: :c:type:`struct device <device>`
28

39
==============================
410
Device Power Management Basics
@@ -95,32 +101,31 @@ Device Power Management Operations
95101

96102
Device power management operations, at the subsystem level as well as at the
97103
device driver level, are implemented by defining and populating objects of type
98-
|struct| :c:type:`dev_pm_ops` defined in :file:`include/linux/pm.h`.
99-
The roles of the methods included in it will be explained in what follows. For
100-
now, it should be sufficient to remember that the last three methods are
101-
specific to runtime power management while the remaining ones are used during
102-
system-wide power transitions.
104+
|struct dev_pm_ops| defined in :file:`include/linux/pm.h`. The roles of the
105+
methods included in it will be explained in what follows. For now, it should be
106+
sufficient to remember that the last three methods are specific to runtime power
107+
management while the remaining ones are used during system-wide power
108+
transitions.
103109

104110
There also is a deprecated "old" or "legacy" interface for power management
105111
operations available at least for some subsystems. This approach does not use
106-
|struct| :c:type:`dev_pm_ops` objects and it is suitable only for implementing
107-
system sleep power management methods in a limited way. Therefore it is not
108-
described in this document, so please refer directly to the source code for more
112+
|struct dev_pm_ops| objects and it is suitable only for implementing system
113+
sleep power management methods in a limited way. Therefore it is not described
114+
in this document, so please refer directly to the source code for more
109115
information about it.
110116

111117

112118
Subsystem-Level Methods
113119
-----------------------
114120

115121
The core methods to suspend and resume devices reside in
116-
|struct| :c:type:`dev_pm_ops` pointed to by the :c:member:`ops`
117-
member of |struct| :c:type:`dev_pm_domain`, or by the :c:member:`pm`
118-
member of |struct| :c:type:`bus_type`, |struct| :c:type:`device_type` and
119-
|struct| :c:type:`class`. They are mostly of interest to the people writing
120-
infrastructure for platforms and buses, like PCI or USB, or device type and
121-
device class drivers. They also are relevant to the writers of device drivers
122-
whose subsystems (PM domains, device types, device classes and bus types) don't
123-
provide all power management methods.
122+
|struct dev_pm_ops| pointed to by the :c:member:`ops` member of
123+
|struct dev_pm_domain|, or by the :c:member:`pm` member of |struct bus_type|,
124+
|struct device_type| and |struct class|. They are mostly of interest to the
125+
people writing infrastructure for platforms and buses, like PCI or USB, or
126+
device type and device class drivers. They also are relevant to the writers of
127+
device drivers whose subsystems (PM domains, device types, device classes and
128+
bus types) don't provide all power management methods.
124129

125130
Bus drivers implement these methods as appropriate for the hardware and the
126131
drivers using it; PCI works differently from USB, and so on. Not many people
@@ -145,12 +150,11 @@ The :c:member:`power.can_wakeup` flag just records whether the device (and its
145150
driver) can physically support wakeup events. The
146151
:c:func:`device_set_wakeup_capable()` routine affects this flag. The
147152
:c:member:`power.wakeup` field is a pointer to an object of type
148-
|struct| :c:type:`wakeup_source` used for controlling whether or not
149-
the device should use its system wakeup mechanism and for notifying the
150-
PM core of system wakeup events signaled by the device. This object is only
151-
present for wakeup-capable devices (i.e. devices whose
152-
:c:member:`can_wakeup` flags are set) and is created (or removed) by
153-
:c:func:`device_set_wakeup_capable()`.
153+
|struct wakeup_source| used for controlling whether or not the device should use
154+
its system wakeup mechanism and for notifying the PM core of system wakeup
155+
events signaled by the device. This object is only present for wakeup-capable
156+
devices (i.e. devices whose :c:member:`can_wakeup` flags are set) and is created
157+
(or removed) by :c:func:`device_set_wakeup_capable()`.
154158

155159
Whether or not a device is capable of issuing wakeup events is a hardware
156160
matter, and the kernel is responsible for keeping track of it. By contrast,
@@ -670,17 +674,17 @@ nested inside another power domain. The nested domain is referred to as the
670674
sub-domain of the parent domain.
671675

672676
Support for power domains is provided through the :c:member:`pm_domain` field of
673-
|struct| :c:type:`device`. This field is a pointer to an object of
674-
type |struct| :c:type:`dev_pm_domain`, defined in :file:`include/linux/pm.h``,
675-
providing a set of power management callbacks analogous to the subsystem-level
676-
and device driver callbacks that are executed for the given device during all
677-
power transitions, instead of the respective subsystem-level callbacks.
678-
Specifically, if a device's :c:member:`pm_domain` pointer is not NULL, the
679-
``->suspend()`` callback from the object pointed to by it will be executed
680-
instead of its subsystem's (e.g. bus type's) ``->suspend()`` callback and
681-
analogously for all of the remaining callbacks. In other words, power
682-
management domain callbacks, if defined for the given device, always take
683-
precedence over the callbacks provided by the device's subsystem (e.g. bus type).
677+
|struct device|. This field is a pointer to an object of type
678+
|struct dev_pm_domain|, defined in :file:`include/linux/pm.h``, providing a set
679+
of power management callbacks analogous to the subsystem-level and device driver
680+
callbacks that are executed for the given device during all power transitions,
681+
instead of the respective subsystem-level callbacks. Specifically, if a
682+
device's :c:member:`pm_domain` pointer is not NULL, the ``->suspend()`` callback
683+
from the object pointed to by it will be executed instead of its subsystem's
684+
(e.g. bus type's) ``->suspend()`` callback and analogously for all of the
685+
remaining callbacks. In other words, power management domain callbacks, if
686+
defined for the given device, always take precedence over the callbacks provided
687+
by the device's subsystem (e.g. bus type).
684688

685689
The support for device power management domains is only relevant to platforms
686690
needing to use the same device driver power management callbacks in many

0 commit comments

Comments
 (0)