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

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

[Krzysztof Kozlowski]

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@kernel.org>
---
 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
       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.
+
 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,
-- 
2.1.4

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@kernel.org>
> ---
>  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

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@kernel.org>
> ---
>  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

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

[Krzysztof Kozlowski]

On 13.03.2016 01:57, Alan Stern wrote:
> 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@kernel.org>
>> ---
>>  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.

Hmmm, okay, I'll resend only with second part below.

Best regards,
Krzysztof

> 
>>        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
> 
> 
>