On Wednesday, April 20, 2011, Alan Stern wrote: > 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. What about making a rule that it is invalid to schedule a future suspend or queue a resume request of a device whose driver is being removed? Arguably, we can't prevent people from shooting themselves in the foot this way or another and I'm not sure if this particular case is worth additional handling. Thanks, Rafael -- 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
