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. Thanks, Pat
