Hi Alan, > I'm in the midst of changing the Power Management core to make it > acquire the device semaphore of every device during a suspend and > resume. The order of acquisition is the order of device registration, > which normally agrees with the way locks are acquired when going > through the device tree (i.e., parents before children). > > But when you call device_move() that might no longer be true. If a > device is moved so that its new parent was registered _after_ it was, > then the two orders will disagree. This raises the possibility of a > deadlock if any thread ever tries to lock the device while holding the > new parent's lock -- as might happen during an unregistration, for > example. the Bluetooth subsystem or the RFCOMM TTY code to be more precise uses device_move() to attach an registered /dev/rfcommX device node (but not connected) to the appropriate Bluetooth adapter and the low-level piconet connection when you open (and thus connect) it. So mainly we re-parent the TTY to the Bluetooth connection and after the connection terminates we re-parent it to the virtual tree (NULL). Regards Marcel _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
