On Mon, 8 Aug 2005, Patrick Mochel wrote: > > On Sat, 6 Aug 2005, Alan Stern wrote: > > > Brief recap: To avoid races, the RTPM code in a driver will need to > > lock the device while it does its work. The locking-order > > requirement for dev->sem is that locks can only be acquired going > > _down_ the device tree: a thread that owns a child's lock may not try > > to lock the parent. However RTPM involves notifications that go _up_ > > the tree. This makes it impossible to acquire the locks we need. > > > > There doesn't appear to be any way to make this work as stated. So > > instead, we add a second semaphore to struct device: dev->power_sem. > > The rule for locking is that power_sem's can only be acquired going > > _up_ the power DAG. In addition, if a thread holds a device's > > power_sem then it may not try to lock any device's regular semaphore. > > (That is, first lock dev->sem, then lock dev->power_sem, then go up > > the DAG only acquiring power_sem's.) > > At first thought, it seems Ok with the caveat that it should go in to a > separate object (the power object with which to create the power DAG). > This should make it a bit easier to understand and follow. Good -- mainly I just wanted to check that the idea wasn't totally off-base. Putting the power_sem into the power object makes sense. There are still one or two patches pending for USB power management. Once those have been submitted and added to Greg's tree, I'll put together something that implements most of this RTPM stuff for USB. It'll make a good working example to stimulate future discussions. Alan Stern
