On Thu, Sep 2, 2010 at 2:34 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 2 Sep 2010, Colin Cross wrote: > >> That would work, but I still don't see why it's better. With either >> of your changes, the power.completion variable is storing state, and >> not just used for notification. However, the exact meaning of that >> state is unclear, especially during the transition from an aborted >> suspend to resume, and the state is duplicating power.status. Setting >> it to complete in dpm_prepare is especially confusing, because at that >> point nothing is completed, it hasn't even been started. > > The state being waited for varies from time to time and is only > partially related to power.status. Instead of using a completion I > suppose we could have used a new "transition_complete" variable > together with a waitqueue. Would you prefer that? It's effectively > the same thing as a completion, but without the nice packaging already > provided by the kernel. No, that doesn't change anything. What I'd prefer to see is a wait_for_condition on the desired state of the parent. As is, power.completion means one thing during suspend (the device has started, but not finished, suspending), and a different thing during resume (the device has not finished resuming, and may not have started resuming). That difference is exactly what caused the bug - the completion has to be set on init so that it is set before the device starts suspend. I'll send the complete_all on init patch, as it's the only way to fix the problem given the current implementation of dpm_wait. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
