Re: Nested suspends; messages vs. states

[Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]

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.



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]