On Thu, 2 Sep 2010, Colin Cross wrote: > You're right, wait_event would be much worse. > > I think there's another race condition during suspend. If an > asynchronous device calls device_pm_wait_for_dev on a device that > hasn't had device_suspend called on it yet, power.completion will > still be set from initialization or the last time it completed resume, > and it won't wait. That can't happen in a properly-designed system. It would mean the async device didn't suspend because it was waiting for a device which was registered before it -- and that would deadlock even if you used synchronous suspend. > Assuming that problem is fixed somehow, there's also a deadlock > possibility. Consider 3 devices. A, B, and C, registered in that > order. A is async, and the suspend handler calls > device_pm_wait_for_dev(C). B's suspend handler returns an error. A's > suspend handler is now stuck waiting on C->power.completion, but > device_suspend(C) will never be called. Why not? The normal suspend order is last-to-first, so C will be suspended before B. > There are also an unhandled edge condition - what is the expected > behavior for a call to device_pm_wait_for_dev on a device if the > suspend handler for that device returns an error? Currently, the > calling device will continue as if the target device had suspended. It looks like __device_suspend needs to set async_error. Which means async_suspend doesn't need to set it. This is indeed a bug. > What about splitting power.completion into two flags, > power.suspend_complete and power.resume_complete? > power.resume_complete is initialized to 1, because the devices start > resumed. Clear power.suspend_complete for all devices at the > beginning of dpm_suspend, and clear power.resume_complete for any > device that is suspended at the beginning of dpm_resume. The > semantics of each flag is then always clear. Any time between the > beginning and end of dpm_suspend, waiting on any device's > power.suspend_complete will block until that device is in suspend. > Any time between the beginning and end of dpm_resume, waiting on > power.resume_complete will block IFF the device is suspended. How are you going to wait for these things? With wait_event? Didn't you say above that it would be worse than using completions? > A solution to the 2nd and 3rd problems would still be needed - a way > to abort drivers that call device_pm_wait_for_dev when suspend is > aborted, and a return value to tell them the device being waited on is > not suspended. No solutions are needed. See above. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
