[v4,3/3] PM: runtime: Clarify documentation when callbacks are unassigned

Message ID 20210609100610.97830-1-ulf.hansson@linaro.org
State Accepted
Commit 4ec4f059088b48585c337328e05fa930c64d1ba8
Headers show
Series
  • Untitled series #134959
Related show

Commit Message

Ulf Hansson June 9, 2021, 10:06 a.m.
Recent changes to the PM core allows ->runtime_suspend|resume callbacks to
be unassigned.

In the earlier behaviour the PM core would return -ENOSYS, when trying to
runtime resume a device, for example. Let's update the documentation to
clarify this.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

---

Changes in v4:
        - This time, really, fix spelling and further clarified the behaviour,
	according to comments from Alan.

---
 Documentation/power/runtime_pm.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

-- 
2.25.1

Comments

Alan Stern June 9, 2021, 2:16 p.m. | #1
On Wed, Jun 09, 2021 at 12:06:10PM +0200, Ulf Hansson wrote:
> Recent changes to the PM core allows ->runtime_suspend|resume callbacks to

> be unassigned.

> 

> In the earlier behaviour the PM core would return -ENOSYS, when trying to

> runtime resume a device, for example. Let's update the documentation to

> clarify this.

> 

> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

> ---

> 

> Changes in v4:

>         - This time, really, fix spelling and further clarified the behaviour,

> 	according to comments from Alan.

> 

> ---

>  Documentation/power/runtime_pm.rst | 9 +++++++++

>  1 file changed, 9 insertions(+)

> 

> diff --git a/Documentation/power/runtime_pm.rst b/Documentation/power/runtime_pm.rst

> index 18ae21bf7f92..8a0a43811e3a 100644

> --- a/Documentation/power/runtime_pm.rst

> +++ b/Documentation/power/runtime_pm.rst

> @@ -827,6 +827,15 @@ or driver about runtime power changes.  Instead, the driver for the device's

>  parent must take responsibility for telling the device's driver when the

>  parent's power state changes.

>  

> +Note that, in some cases it may not be desirable for subsystems/drivers to call

> +pm_runtime_no_callbacks() for their devices. This could be because a subset of

> +the runtime PM callbacks needs to be implemented, a platform dependent PM

> +domain could get attached to the device or that the device is power managed

> +through a supplier device link. For these reasons and to avoid boilerplate code

> +in subsystems/drivers, the PM core allows runtime PM callbacks to be

> +unassigned. More precisely, if a callback pointer is NULL, the PM core will act

> +as though there was a callback and it returned 0.

> +

>  9. Autosuspend, or automatically-delayed suspends

>  =================================================


Acked-by: Alan Stern <stern@rowland.harvard.edu>


I don't know what happened before.  Maybe the terminal window got 
resized without me noticing, so the lines looked too long when they 
actually weren't.

Alan Stern
Rafael J. Wysocki June 11, 2021, 5:05 p.m. | #2
On Wed, Jun 9, 2021 at 4:16 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>

> On Wed, Jun 09, 2021 at 12:06:10PM +0200, Ulf Hansson wrote:

> > Recent changes to the PM core allows ->runtime_suspend|resume callbacks to

> > be unassigned.

> >

> > In the earlier behaviour the PM core would return -ENOSYS, when trying to

> > runtime resume a device, for example. Let's update the documentation to

> > clarify this.

> >

> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

> > ---

> >

> > Changes in v4:

> >         - This time, really, fix spelling and further clarified the behaviour,

> >       according to comments from Alan.

> >

> > ---

> >  Documentation/power/runtime_pm.rst | 9 +++++++++

> >  1 file changed, 9 insertions(+)

> >

> > diff --git a/Documentation/power/runtime_pm.rst b/Documentation/power/runtime_pm.rst

> > index 18ae21bf7f92..8a0a43811e3a 100644

> > --- a/Documentation/power/runtime_pm.rst

> > +++ b/Documentation/power/runtime_pm.rst

> > @@ -827,6 +827,15 @@ or driver about runtime power changes.  Instead, the driver for the device's

> >  parent must take responsibility for telling the device's driver when the

> >  parent's power state changes.

> >

> > +Note that, in some cases it may not be desirable for subsystems/drivers to call

> > +pm_runtime_no_callbacks() for their devices. This could be because a subset of

> > +the runtime PM callbacks needs to be implemented, a platform dependent PM

> > +domain could get attached to the device or that the device is power managed

> > +through a supplier device link. For these reasons and to avoid boilerplate code

> > +in subsystems/drivers, the PM core allows runtime PM callbacks to be

> > +unassigned. More precisely, if a callback pointer is NULL, the PM core will act

> > +as though there was a callback and it returned 0.

> > +

> >  9. Autosuspend, or automatically-delayed suspends

> >  =================================================

>

> Acked-by: Alan Stern <stern@rowland.harvard.edu>


Applied as 5.14 material along with the [1-2/3] from this series.

Thanks!

Patch

diff --git a/Documentation/power/runtime_pm.rst b/Documentation/power/runtime_pm.rst
index 18ae21bf7f92..8a0a43811e3a 100644
--- a/Documentation/power/runtime_pm.rst
+++ b/Documentation/power/runtime_pm.rst
@@ -827,6 +827,15 @@  or driver about runtime power changes.  Instead, the driver for the device's
 parent must take responsibility for telling the device's driver when the
 parent's power state changes.
 
+Note that, in some cases it may not be desirable for subsystems/drivers to call
+pm_runtime_no_callbacks() for their devices. This could be because a subset of
+the runtime PM callbacks needs to be implemented, a platform dependent PM
+domain could get attached to the device or that the device is power managed
+through a supplier device link. For these reasons and to avoid boilerplate code
+in subsystems/drivers, the PM core allows runtime PM callbacks to be
+unassigned. More precisely, if a callback pointer is NULL, the PM core will act
+as though there was a callback and it returned 0.
+
 9. Autosuspend, or automatically-delayed suspends
 =================================================