On Tue, 3 Mar 2009, Ming Lei wrote: > 2009/3/3 Cornelia Huck <cornelia.huck@xxxxxxxxxx>: > > Hi, > > > > in thread [1], we discussed the issue of device_move() causing a > > reordering of devices without adapting the ancestral order in dpm_list. > > If a device is moved to a new parent that was registered after the > > device itself, it would still be after its new parent in dpm_list, thus > > causing the parent to be suspended before its child. > > > > This patchset attempts to remedy this situation by introducing an > > interface for a driver to manipulate dpm_list with the dpm_list_mtx > > held. (device_move() does not have enough information to do this > > manipulation itself.) The calling sequence for a driver would be: > > > > - lock the dpm_list > > - call device_move() > > - if device_move() succeeded, fix up dpm_list > > - unlock the dpm_list > > IMHO, It is better to fix up dpm_list inside device_move() , like device_add(), > which may let s390, bluetooth or other possible users more happy with > device_remove(). I agree; it would be cleaner if device_move() could fix up dpm_list directly. If it doesn't have enough information to do so then change the interface so that it does. That should be pretty easy since there are only a handful of callers. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
