[PATCH v4 0/2] PM: runtime: Overhaul kerneldoc, runtime_pm.rst docs
From: Brian Norris
Date: Thu Oct 01 2026 - 12:20:25 EST
The runtime PM documentation could use some improvements and additions,
to help guide people less familiar with the main runtime PM concepts and
its internal implementation details.
v1 is here:
https://lore.kernel.org/all/20260904212000.4167880-1-briannorris@xxxxxxxxxxxx/
v2 is here:
https://lore.kernel.org/all/20260923174711.1283986-1-briannorris@xxxxxxxxxxxx/
v3 is here:
https://lore.kernel.org/all/20260930025044.104824-1-briannorris@xxxxxxxxxxxx/
Most of the v1-v3 series has been applied already. For the remaining
work:
- Clarifying core concepts in the Introduction. (Pretty much all new
readers I encounter have a hard time with the difference between
"enabled", "allowed", and "active".)
- Adding Example driver patterns -- because the API is so large and
complicated, it can help to try to walk people through standard
practices, and what everything means in context.
Feel free to add suggestions! Within reason, I'm open to tackling more
here, as I think many people have many valid perspectives on exactly why
and how the docs do or don't serve people well today. Or I can tackle
less, if you think some of my choices are not improvements.
Some possible follow-ups I'm toying with:
* Slimming down the API might be better than heavily documenting it. A
smaller API is a more digestible API.
My only concrete next step: drop __pm_runtime_put_autosuspend(). Its
last user is nearly gone:
https://lore.kernel.org/all/20260806-smmu-rpm-v4-1-8183d007331c@xxxxxxxxxxxxxxxx/
I could also see deprecating one of
pm_runtime_put_sync{,_suspend,_autosuspend}(). They all do slightly
different things, but I'm not sure every difference is actually fully
intentional (or at least, not necessary).
* Tweaking some of the behavior on pm_runtime_barrier(). Today, it's
very asymmetric, as it prefers resume. But I believe there may be
value in making it flush (not just cancel) pending suspend too. That
may be in a future proposal; for now, I just try to make its
asymmetry more clear in the docs.
* Sand down some more rough edges on return codes. For example, it's
very difficult to get any useful meaning out of pm_runtime_put_sync()
return codes. There's a high chance that anyone trying to treat
return codes as errors is inviting bugs. (Is -EAGAIN a failure?)
Of course, the answer there is not "document it better" -- we can
make it easier to use.
* Adjust the way devm_pm_runtime_enable() works, specifically for
remove()/teardown. Currently, this is very hard to use correctly --
some common driver patterns may assume that a device will tear down
while RPM_SUSPENDED; but that's not actually guaranteed. Notably,
this makes some of the "Examples" section fairly tricky/subtle.
Regards,
Brian
Changes in v4:
* Significantly overhaul introduction, based on Rafael's
feedback/rewrite
* Drop most implementation details (struct fields) and API names from
intro
* Expand the "in use" and dependencies concepts in the introduction
Changes in v3:
* Rewrite Examples to avoid devm_* at first, to highlight correct
approaches
* Include error-handling and remove() in any probe() Examples
* Advise more caution when using devm_*, as ordering issues are subtle
Changes in v2:
* Major rework on Introduction section, especially regarding "enabled"
and "active"
* Add appropriate teardown to "Probe with Hardware Powered Off"
Example, as the remove() + power-off behavior is subtle here, and
easy to get wrong
* Drop changes that are already applied
* Add a few new fix patches, noticed while reviewing the rest
* Move Introduction patch near the end of the series, as it is a likely
target for further discussion and modification.
* Correct Ulf's email address
* CC linux-doc
Brian Norris (2):
PM: runtime: Expand introduction with core concepts and structure
PM: runtime: Add Example Driver Patterns section
Documentation/power/runtime_pm.rst | 589 ++++++++++++++++++++++++++++-
1 file changed, 568 insertions(+), 21 deletions(-)
--
2.56.0.rc1.315.gc6ed9934b7-goog