On Wednesday 10 June 2009, Oliver Neukum wrote: > Am Mittwoch, 10. Juni 2009 10:29:26 schrieb Rafael J. Wysocki: > > Argh, I forgot about some important things. > > > > First, there are devices with no parent (actually, it would be much easier > > if they had a default dummy parent, but that's a separate issue). > > > > Second, the parent has to be taken into account in the asynchronous resume > > path too (which BTW is more complicated). > > What happens if the parent's parent is also suspended? It seems to me that > you must code this recursively. Hmm, I thought I did. [Looks] pm_request_resume(dev) will call pm_request_resume(dev->parent), if necessary, and that will call pm_request_resume(dev->parent->parent) and so on. Each of them will queue a work item and the one for the topmost parent will be queued first. So, the resume requests for all parents will be executed before the one for the device, due to the fact that the workqueue is singlethread. Well, there is a bug related to it, namely pm_autosuspend() may change the status to RPM_SUSPENDED after pm_request_resume() has changed it to RPM_WAKE, that needs fixing. Best, Rafael -- 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
