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 <k...@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 > > >
