> I also think we shouldn't anymore move things around lists. We walk the > PM tree, that's it. Since we know the state of a given device at any > time, it's rather easy to walk it, even in a non-recursive code (using a > local stack evetnually as a list). That would make it easy to implement > the broadcast of bus states to childs. > > Ok, enough for now. I think this is rather easy to implement, flexible > enough to cover pretty much all needs but the most exotics (which can > always be "hacked"), and will keep existing drivers working by simply, > in the absence of set_power_state(), defaulting on a best-effort basis > to suspend/resume. Oh, an important point still.... the fact that we need power state changes to be done after childs for suspend and before childs for resume... The core can't know what suspend and resume is in the concept of those driver-defined states. There are several ways to solve that. - If the tree walking is done via recursive code (hrm... stacks ?), it can be each driver responsibility to call the childs (via a helper) from it's own set_power_state(). - It can be the bus / system state bits themselves. A higher bit mean a deeper sleep, 0 means running, thus depending on how we transition dicates the ordering. A system transition prevails over a bus state transition of course. - The states can be in order in the array. That is when a given device is going to a "higher" state, childs are notified first, and the opposite. - We can have to callbacks. One before childs, one after childs (that can be useful actually). - We can call the callback twice with an argument indicating if it's before and/or after. - It can be encoded in the state itself. Since transitions from state to state may not always be allowed (it's driver policy to reject illegal transitions and define the array such as system events don't trigger illegal transitions), then we can imagine that the state flags have bits indicating wether we want to be notified before or after childs. I have no preference at this point. Few drivers will be concerned (bus providers that is. Things like U/O/EHCI's etc.. and even there, a common code can implement the policy for all 3 of them). Ben.
