Re: Nested suspends; messages vs. states

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

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

On Wednesday 23 March 2005 12:29 pm, Nigel Cunningham wrote:
> Hi
> 
> On Thu, 2005-03-24 at 06:06, David Brownell wrote:
> > On Tuesday 22 March 2005 4:52 pm, Patrick Mochel wrote:
> > > > 
> > > I think the core should always call ->suspend() for a device, regardless
> > > of whether it thinks it's in a low power state, or inactive. This is
> > > specifically for the reason that a device could be a low-power runtime
> > > state when the system is suspended.
> > 
> > I don't quite see a need for this.  If the parent/bridge driver knows
> > the device is adequately suspended, why kick it again?  It's actually
> > rather annoying -- and error/bug prone! -- to have to code drivers to
> > detect and cope with superfluous suspend calls.
> 
> I would think it would be simpler not to have the parent/bridge check
> whether the device is already suspended, and to just have all the logic
> that decides what to do in the driver. I'm only thinking intuitively,
> but it sounds like that should help with avoiding race conditions.

Maybe the solution should involve a parent/child handshake; that'd
be the place to address potential races, and it could include the
notification folk seem to want.  

You're suggesting a tradeoff which shifts work from the bridges,
which won't be numerous, to the drivers, which will be.  I still
don't see a need to do that, and I'd rather take opportunities to
make the drivers simpler.

- Dave

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