On Thu, 2 Aug 2012, Alan Stern wrote: > On Thu, 2 Aug 2012, Rafael J. Wysocki wrote: > > > > I don't know about that -- the logic involved in doing the processing > > > within the resume callback isn't terribly complicated. At least, not > > > much more complicated than the logic involved in setting up a custom > > > work routine as you suggest. > > > > That's why I had the idea of pm_request_resume_and_call(dev, func) > > described in this message: > > > > http://marc.info/?l=linux-usb&m=134377126804170&w=4 > > > > although perheps it would be better to call it something like > > pm_runtime_async_resume_and_call(dev, func). > > Hmmm. You'd probably want a version that does a "get" at the same > time. I suppose you would call func directly if the device was already > resumed, without going through the workqueue? > > Yes, I agree this would be a better interface then pm_runtime_get. A few problems: What happens if a system sleep begins after pm_runtime_async_resume_and_call() but before the runtime resume? When the system wakes up, the device will be back at full power without ever executing a runtime PM call. Then how will func get invoked? What happens if the driver is unbound after pm_runtime_async_resume_and_call() but before the runtime resume? The When the runtime resume occurs, func will be invoked -- and the driver might not even be in memory any more. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
