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(). Thanks > > Following are three patches: > > Patch 1 - Introduce the dpm_list manipulation interfaces. I'm not sure > whether the BUG_ON()s should be WARN_ON()s instead. > > Patch 2 - Make bluetooth use the new interfaces. I didn't introduce > proper handling for device_move() failures. Very lightly tested (did > not break my setup :)), needs proper review. > > Patch 3 - Make s390 use the new interfaces. I'm more confident this > patch is correct, but it is hard to test power management related stuff > without power management support (no regressions were introduced for my > attach/detach testcases though). > > > [1] https://lists.linux-foundation.org/pipermail/linux-pm/2007-July/014428.html > _______________________________________________ > linux-pm mailing list > linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/linux-pm > -- Lei Ming _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
