On Wed, 20 Apr 2011, Rafael J. Wysocki wrote: > On Wednesday, April 20, 2011, Alan Stern wrote: > > On Wed, 20 Apr 2011, Guennadi Liakhovetski wrote: > ... > > Ah, now I see the problem. It looks like we did not give sufficient > > thought to the case where a device starts off (and therefore should > > finish up) in a powered-down state. Calling pm_runtime_put_sync() > > after unbinding the device driver seems a little futile -- with no > > driver, the subsystem may not be able to power-down the device! > > > > Rafael, how do you think we should handle this? Get rid of the > > pm_runtime_get_no_resume() and pm_runtime_put_sync() calls in > > dd.c:__device_release_driver()? > > I think we need pm_runtime_barrier() in there. Otherwise we risk > removing the driver while there's a runtime PM request pending. > > But we can move the pm_runtime_put_sync() before driver_sysfs_remove(). What happens if another runtime PM request is queued between the put_sync() and the remove callback? We may need a safe way to prevent async runtime PM requests while still allowing synchronous requests. 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
