Ok, I'm starting a new thread for this one, it's getting messy... So, my initial proposal, was to have a simple dependency mecanism in the core, that consist of having driver state indicate their depedencies on parent states (either an integer or a bit mask). However, that requires ordering of states (from "low" to "high" power) in order to properly deal with calling the child before/after and some people, notably David, disagree with the model. I'm not 100% "pro" my proposed model, it is again just an idea I had that I think would solve the majority of cases. Maybe we can do something a bit more flexible. We remove the dependency information, and we put it back under driver (child) responsibility, and to deal with that, what we do is add 2 routines to the device: parent_state_will_change() and parent_state_changed(). They are called on all childs respectively before and after a parent state change. No need for the core to know the state ordering, the device "knows" what to do here. It's a bit more callbacks than what I would have liked, but it makes sense still... The problem is that the only sane way I see for now to properly cascade these down the tree is recursive calls from bridge enter_state routines, which may have evil stack consumption issues... Unless somebody comes up with a smart idea. I'm also not 100% sure how to fir the system PM in that picture. They'll end up beeing called when the parent gets it's system PM suspend() for example, so the only difference here is that the child will already have suspend()'d before it gets parent_state_will_change() and parent_state_changed() for it's parent's own suspend(). I suppose that isn't an issue... Ben.
