On Wed, 1 Aug 2007, Rafael J. Wysocki wrote: > > > (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. > > Which is a weak assupmtion ... > > Well, we seem to have some examples of possible situations in which the > design might not be adequate and that's alarming. > > Perhaps we should create dpm_active right before the suspend, by really > traversing the device tree, when we own all device semaphores and no device > objects can be added/removed? We're doing okay the way things are. Changing the order is more likely to cause new problems than to solve existing ones. In fact, I would go even farther. Let's document the ordering given by dpm_active (by default, in order of registration) so that drivers can depend on it, and let's add special routines to change the order for the few cases that require it -- under driver control. A "move to the end" routine would solve the EHCI issue. It ought to solve the problems associated with device_move() also, provided the device being moved doesn't have any children. Cornelia and Marcel, is that the case? When a ccw_device or RFCOMM TTY is reparented under a new device, do any children get moved along with it? Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
