On Sun, 6 Dec 2009, Arjan van de Ven wrote: > having spent 30 minutes trying to grok this code, I think there may be > a trick in using the async function call infrastructure. > > if each USB hub's resume (hub_resume()) would be done as an async > function call, that would start allowing the hub resumes to go async, > but this is not enough. > > usb_resume_both() would also then need to be an async call itself, and > do its "resume the parent" recursion as a async function call, and then > it needs to do a synchronization before actually resuming the device > itself (provided it is not a hub or hub like device I suppose). > > the later synchronization guarantees that no device will be resumed > before it's parent tree structure is resumed, while allowing parallel > parts of the tree to be resumed in parallel. > > The hard part in this is the locking.... that is getting non-trivial > once you have multiple asynchronous functions executing. That's the whole point of Rafael's async suspend/resume framework. He has done the hard work already. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
