From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
Ohad Ben-Cohen <ohad@wizery.com>,
linux-mmc@vger.kernel.org, Magnus Damm <damm@opensource.se>,
Simon Horman <horms@verge.net.au>,
Linux PM mailing list <linux-pm@lists.linux-foundation.org>
Subject: Re: [PATCH/RFC] MMC: remove unbalanced pm_runtime_suspend()
Date: Sat, 23 Apr 2011 00:11:47 +0200 [thread overview]
Message-ID: <201104230011.48073.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1104221709030.1791-100000@iolanthe.rowland.org>
On Friday, April 22, 2011, Alan Stern wrote:
> On Fri, 22 Apr 2011, Rafael J. Wysocki wrote:
>
> > > The barrier would not prevent the race between the notifier and runtie PM
> > > from taking place. Why don't we do something like this instead:
> > >
> > > ---
> > > drivers/base/dd.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > Index: linux-2.6/drivers/base/dd.c
> > > ===================================================================
> > > --- linux-2.6.orig/drivers/base/dd.c
> > > +++ linux-2.6/drivers/base/dd.c
> > > @@ -326,6 +326,8 @@ static void __device_release_driver(stru
> > > BUS_NOTIFY_UNBIND_DRIVER,
> > > dev);
> > >
> > > + pm_runtime_put_sync(dev);
> > > +
> >
> > In fact, I think this one may be _noidle. If we allow the bus/driver
> > to do what they wont, we might as well let them handle the "device idle"
> > case from ->remove().
>
> Maybe... But keeping it put_sync doesn't do any harm. In Guennadi's
> case, it might allow him to get rid of the pm_runtime_suspend() call in
> the remove routine.
>
> > > if (dev->bus && dev->bus->remove)
> > > dev->bus->remove(dev);
> > > else if (drv->remove)
> > > @@ -338,7 +340,6 @@ static void __device_release_driver(stru
> > > BUS_NOTIFY_UNBOUND_DRIVER,
> > > dev);
> > >
> > > - pm_runtime_put_sync(dev);
> > > }
> > > }
>
> Basically this is okay with me, and it should allow Guennadi to avoid
> the extra put/get pair.
OK, so I'm going to put the appended patch into my linux-next branch
(hopefully, the problem is explained sufficiently in the changelog).
> Do you know if any other subsystems rely on the usage_count
> being > 0 during unbinding?
Do you mean if I know of subsystems that the patch below may cause to
fail? No, I don't. :-)
Rafael
---
From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: PM / Runtime: Allow runtime suspend to be done from remove callbacks
The driver core prevents race conditions between device runtime PM
and driver removal from happening by incrementing the runtime PM
usage counter of the device and executing pm_runtime_barrier() before
running the bus notifier and the ->remove() callbacks provided by the
device's subsystem or driver. This guarantees that, if a future
runtime suspend of the device has been scheduled or a runtime resume
or idle request has been queued up right before the driver removal,
it will be canceled or waited for to complete and no other
asynchronous runtime suspend or idle requests for the device will be
put into the PM workqueue until the ->remove() callback returns.
However, this also means that the device's subsystem or driver will
not be able put it into the suspended state by calling
pm_runtime_suspend() from its ->remove() routine. This turns out to
be a major inconvenience for some subsystems and drivers that want to
leave the devices they handle in the suspended state.
To allow subsystems and drivers to put devices into the suspended
state by calling pm_runtime_suspend() from their ->remove() routines
execute pm_runtime_put_sync() after running the bus notifier in
__device_release_driver(). [The bus notifier still needs to be
protected from racing with runtime PM routines, because it is used
by some subsystems to carry out operations affecting the runtime PM
functionality.] This will require subsystems and drivers to make
their ->remove() callbacks avoid races with runtime PM directly, but
it will allow of more flexibility in the handling of devices during
the removal of their drivers.
Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/base/dd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/base/dd.c
===================================================================
--- linux-2.6.orig/drivers/base/dd.c
+++ linux-2.6/drivers/base/dd.c
@@ -326,6 +326,8 @@ static void __device_release_driver(stru
BUS_NOTIFY_UNBIND_DRIVER,
dev);
+ pm_runtime_put_sync(dev);
+
if (dev->bus && dev->bus->remove)
dev->bus->remove(dev);
else if (drv->remove)
@@ -338,7 +340,6 @@ static void __device_release_driver(stru
BUS_NOTIFY_UNBOUND_DRIVER,
dev);
- pm_runtime_put_sync(dev);
}
}
next prev parent reply other threads:[~2011-04-22 22:11 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 10:46 [PATCH/RFC] MMC: remove unbalanced pm_runtime_suspend() Guennadi Liakhovetski
2011-04-19 12:44 ` Ohad Ben-Cohen
2011-04-19 13:23 ` Guennadi Liakhovetski
2011-04-19 14:16 ` Ohad Ben-Cohen
2011-04-19 14:26 ` Alan Stern
2011-04-19 22:59 ` Guennadi Liakhovetski
2011-04-20 14:22 ` Alan Stern
2011-04-20 14:50 ` Guennadi Liakhovetski
2011-04-20 15:12 ` Alan Stern
2011-04-20 20:06 ` Rafael J. Wysocki
2011-04-20 21:16 ` Alan Stern
2011-04-20 21:44 ` Rafael J. Wysocki
2011-04-21 13:58 ` Alan Stern
2011-04-21 18:00 ` Rafael J. Wysocki
2011-04-21 18:36 ` Alan Stern
2011-04-21 20:05 ` Rafael J. Wysocki
2011-04-21 21:48 ` Alan Stern
2011-04-21 22:06 ` Rafael J. Wysocki
2011-04-22 15:20 ` Alan Stern
2011-04-22 20:22 ` Rafael J. Wysocki
2011-04-22 20:25 ` Rafael J. Wysocki
2011-04-22 21:20 ` Alan Stern
2011-04-22 22:11 ` Rafael J. Wysocki [this message]
2011-04-25 10:29 ` [linux-pm] " Rafael J. Wysocki
2011-04-26 10:44 ` Guennadi Liakhovetski
2011-04-26 11:51 ` Rafael J. Wysocki
2011-04-28 22:12 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201104230011.48073.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=damm@opensource.se \
--cc=g.liakhovetski@gmx.de \
--cc=horms@verge.net.au \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=ohad@wizery.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox