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. Do you know if any other subsystems rely on the usage_count being > 0 during unbinding? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
