On Wed, 2005-03-23 at 21:02 -0800, David Brownell wrote: > > If we kept it at that, we could just call down to the bridge drivers and > > have them iterate over the devices on their bus to suspend them. This > > would push all the handling of leaf devices to the bus subsystems > > themselves. That would keep the core simple, not matter to the leaf device > > drivers, and place the burden on the bridge drivers. > > Benjamin didn't much like it much at all when I proposed that ... :) Yes and no ... I dislike the word 'bus' here as I think we are drawing an incorrect difference between a bus and a device, but it seems you agree from your previous comments. I think a model where we call the parent enter_state(), and that parent is responsible to do all of the dependency resolving (including changing child states) within his enter_state() call is nice. However, I'm wondering what will be the stack usage of such a model on deep bus layouts... > > The bridge driver largely don't exist (except for USB hubs), the > > requirements aren't very tough, and it would localize the semantics where > > they need to be - in the bus subsystems. > > Yes to localizing semantics!! Though as for requirements, that's > not always true. I don't agree with the bus subsystem beeing a good place here. I don't like it for lots of reasons and never liked it, because it totally lacks the notion of a bus "instance" among others... It's de-facto a device "bus type", so it's a "bus type" subsystem more than a "bus subsystem" imho. But careful explanation might still change my mind here. Ben.
