On Tuesday, 31 July 2007 17:11, Alan Stern wrote: > On Tue, 31 Jul 2007, Cornelia Huck wrote: > > > On Mon, 30 Jul 2007 13:34:35 -0400 (EDT), > > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > As long as you never hold the device semaphores of both the parent and > > > the child there shouldn't be any problem. Could this happen when a > > > subchannel structure is deallocated? > > > > This is indeed what happens, since we unregister the child ccw_device > > from the (io_)subchannel's remove function. > > > > (We used to do unregistering of the ccw_device via a workqueue (in > > order to avoid livelocks on a no longer existing bus semaphore), but > > removed it since it seemed to be needlessly complicated code.) > > It sounds like you might be in trouble with suspend anyway (if S390 > implemented it). As things stand now, the PM core would try to suspend > the subchannel before suspending the ccw_device, because the subchannel > was registered later. > > Marcel, you might be in a similar position. The PM core could try to > suspend a Bluetooth adapter before suspending its child TTY node. > > I wonder if device_move() shouldn't change the order of entries in the > dpm_active list so that the new parent (and all its ancestors) get > moved up ahead of the device's position? But that might cause other > problems... Still, if the ordering of dpm_active doesn't reflect the relationships between devices, we're in trouble anyway. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
