On Sat, 4 Aug 2012, Rafael J. Wysocki wrote: > On Saturday, August 04, 2012, Alan Stern wrote: > > On Sat, 4 Aug 2012, Rafael J. Wysocki wrote: > > > > > > That wasn't what he meant. What if the code needs to run in the _same_ > > > > context as the caller? For example, with a spinlock held. > > > > > > I see. I think it wouldn't be unreasonable to require that func should take > > > all of the necessary locks by itself. > > > > But then if func was called directly, because the device was at full > > power, it would deadlock trying to acquire a lock the caller already > > holds. > > I wonder why the caller may want to take any locks beforehand? Who knows? :-) The best answer may be for the caller not to hold any locks. In the runtime-PM document's example driver, the lock would be dropped before the resume-and-call. > > Do you have any better suggestions? > > Hmm. What about pm_runtime_get_and_call(dev, func_sync, func_async), where > func_sync() is to be called if the device is already active and func_async() > is to be called if it has to be resumed from the workqueue? That's a little better but not much. It would require storing two function pointers in the dev->power structure. 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
