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). >> And what if you are a parent waited for by a child to resume so that _it_ >> can process its data? Would you still want to process your data in the >> resume callback in that case? Looks the child is always resumed after its parent completes the resuming, and current pm_runtime_get doesn't delay the resume of the parent, and just make the .runtime_resume run in another context. Also are there actual examples about the above situation? > > Okay, those are valid reasons. (Although a device handling I/O > requests isn't likely to have a child with its own independent I/O > handling.) IMO, the .runtime_resume callback can handle the IO things easily via scheduling worker function if the driver don't want to delay its children's resume. Thanks, -- Ming Lei -- 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
