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. > However, I believe that if func is going to be called through the workqueue, > the usage counter should be incremented before the preceding resume and > decremented after func returns by the workqueue thread. Okay. > > 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. > > I agree. I'd prefer to avoid that, if possible. Do you have any better suggestions? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
