On Sat, 4 Aug 2012, Rafael J. Wysocki wrote: > On Friday, August 03, 2012, Ming Lei wrote: > > On Fri, Aug 3, 2012 at 10:20 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Thu, 2 Aug 2012, Rafael J. Wysocki wrote: > > > > > 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? > > > > Maybe it isn't good, the 'func' might not be run in the current context > > (irq context or some spinlock is held). > > Then I'd say don't use this interface. If you have code that needs to > be run in a different context, then you have to use a work item (or > equivalent) anyway and you can do a synchronous runtime resume from there. 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. func would need to know whether it should acquire the lock, which means it needs to know whether it was called directly or through the workqueue. I suppose we could pass it an extra argument with this information... but that's a little ugly. 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
