On Mon, Aug 08, 2005 at 04:03:56PM -0400, Alan Stern wrote: > 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. Pat, I'm not using kobjects in my power object code. If we decide it's necessary, how should we name the power nodes? > > 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. This solution is very similar to the power object tree patch I'm currently working on. The main difference is that I'm using pre-state-change and post-state-change notification methods. The advantage is that we should be able to use an iterative algorithm, allowing for deep power trees. I'll post code soon. > > 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. I think that would be very interesting. Thanks, Adam
