On Mon, 1 Aug 2005, Alan Stern wrote: > On Mon, 1 Aug 2005, Patrick Mochel wrote: > > On Sat, 30 Jul 2005, Alan Stern wrote: > > > > We have also agreed that runtime power state changes need to bubble up > > > the device tree. To handle this, drivers for interior nodes in the > > > tree can define "link states". > > > > Ah, shame on you - a USBism. > > Not really -- the phrase "link state" isn't used in the USB specification > as far as I know. It's just a simple term I came up with to describe > everything a parent needs to know about the power requirements of a child. > As such it's not specific to any particular bus or technology. Noted. > > > These notifications are one-way, child-to-parent only. We don't need > > > pre- and post-notifications; each message will inform the parent of a > > > single link-state change, which the parent will then carry out. > > > > This may not be true. There could be a race between children notifying > > their parent of state changes if e.g. the states of two children are > > opposite and in the process of inverting (there is one suspended one that > > tries to resume, and one resumed device that tries to suspend). > > I agree that a parent may have to cope with situations where two children > are trying to change state at the same time. struct device->semaphore > should help there. This doesn't affect what I wrote, however. Link-state > changes don't involve races, because a link state describes the > connection between one specific parent and one specific child. If two > different links change state at the same time, that's not a race. For two children changing state at the same time, it is not a race. But, there could be potentially racy conditions when notifying the parent. Maybe. As I think about it more, I'm not sure it's possible to get mixed up, since there should always be _some_ delay between a parent receiving a notification that a child has suspended and the parent actually suspending itself. > > These are limitations to what we have now, but it doesn't have to be that > > way. Ideally, we will have a solution that works flawlessly under the > > current constraints. Otherwise, we should (very carefully) examine ways in > > which we can adjust the current Core to better handle what we need to do. > > I don't want to redesign the Driver Core on a whim; only under specific > > requirements. > > Me neither. In fact, I would go so far as to say that this is the main > impediment to RTPM implementations at the moment. If I knew the answer to > the locking-order problem, I could fix up the USB RTPM code right now. What exactly is the impediment? The locking constraints? Pat
