From mboxrd@z Thu Jan 1 00:00:00 1970 From: Krzysztof Kozlowski Subject: Re: [PATCH] PM / runtime: Document steps for device removal Date: Tue, 15 Mar 2016 08:54:07 +0900 Message-ID: <56E74F1F.1090103@samsung.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: Received: from mailout3.w1.samsung.com ([210.118.77.13]:8870 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753781AbcCNXyO (ORCPT ); Mon, 14 Mar 2016 19:54:14 -0400 In-reply-to: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Alan Stern , Krzysztof Kozlowski Cc: "Rafael J. Wysocki" , Len Brown , Pavel Machek , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org 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 >> --- >> 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 > > >