On Wed, 1 Aug 2007, Cornelia Huck wrote: > On Wed, 1 Aug 2007 11:22:12 -0400 (EDT), > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > As it stands right now, every place device_move() gets called is > > already special! > > The "special cases" I was thinking about are those where the order to > suspend/resume is not covered by a parent/child relationship, but by > (possibly random) order of registration. I'd have thought the rule "the > child must be suspended before the parent" was pretty straightforward, > but... So you mean additional requirements, like what I encountered with EHCI. It's peculiar in that the controller contains a hardware switch which can literally connect a USB device to a different (companion) controller, and setting the switch before the companion controller has been resumed won't work. The correct way to handle this would be to set the switch later when the USB device is resumed, but that would be much more awkward. I haven't heard of any other cases. > (The whole list based on registration order thing seems a bit fragile > to me, but I don't know enough of the PM core and suspend/resume in > general to make a better suggestion :/) It hasn't been bad in the past. If A was discovered before B then ipso facto it is safe to suspend B before suspending A. Likewise, in the absence of device_move, if A was discovered before B then A cannot appear below B in the device tree. Of course, this assumes devices are registered as they are discovered. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
