Re: [PATCH] PM / runtime: Document steps for device removal

[Alan Stern]

On Sat, 12 Mar 2016, Krzysztof Kozlowski wrote:

> Put a reminder that during device removal drivers should revert all PM
> runtime changes from the probe. Also add a note that
> pm_runtime_disable() won't wait for pending suspend requests if
> autosuspend is not disabled before.
> 
> Signed-off-by: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
> ---
>  Documentation/power/runtime_pm.txt | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
> index 7328cf85236c..c05e5a17a52d 100644
> --- a/Documentation/power/runtime_pm.txt
> +++ b/Documentation/power/runtime_pm.txt
> @@ -410,7 +410,8 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
>        field was previously zero, this prevents subsystem-level runtime PM
>        callbacks from being run for the device), make sure that all of the
>        pending runtime PM operations on the device are either completed or
> -      canceled; returns 1 if there was a resume request pending and it was
> +      canceled (although this depends on disabling autosuspend before
> +      calling this); returns 1 if there was a resume request pending and it was

I don't agree with this change.  All pending operations really are
either completed or cancelled, even if autosuspend is enabled.

Any strange behavior you saw after disabling runtime PM and then 
enabling it again was caused by new operations being started after you 
re-enabled runtime PM.

>        necessary to execute the subsystem-level resume callback for the device
>        to satisfy that request, otherwise 0 is returned
>  
> @@ -586,6 +587,10 @@ drivers to make their ->remove() callbacks avoid races with runtime PM directly,
>  but also it allows of more flexibility in the handling of devices during the
>  removal of their drivers.
>  
> +Drivers in ->remove() callback should undo the runtime PM changes done
> +in ->probe(). Usually this means calling pm_runtime_disable(),
> +pm_runtime_dont_use_autosuspend() etc.
> +

That's a good addition.

>  The user space can effectively disallow the driver of the device to power manage
>  it at run time by changing the value of its /sys/devices/.../power/control
>  attribute to "on", which causes pm_runtime_forbid() to be called.  In principle,

Alan Stern