The "transition_started" thing is a little odd. I get the feeling that
it shouldn't be set back to false during dpm_resume_noirq() at all.
Maybe I'm not quite thinking straight just now...
They can. We explicitly allow new devices to be registered during the
final "complete" phase, and we grudgingly allow it even during the
"resume" phase, if the parent has already been resumed.
The "prepare" traversal is ordered in the forward direction so that if
a child is registered beneath a device during that device's ->prepare
callback, it will end up in the right place (i.e., after the parent in
the list). The "complete" traversal should work out the same way, only
in reverse. Which means we should _start_ with everything on the other
list, and move each device onto the dpm_list just _before_ invoking its
The way the code is now, it looks like a child registered during the
parent's callback will end up in the wrong place.
The situation isn't quite as bad as it seems, if you assume that a
child will never be registered at a time when its parent is still
suspended. Right now we warn if such a thing happens but we don't
I don't see anything wrong with changing over to multiple list heads.
It might even allow us to remove the dev->power.status field.