On Wednesday 23 March 2005 12:29 pm, Nigel Cunningham wrote:

Hi

On Thu, 2005-03-24 at 06:06, David Brownell wrote:

quoted

On Tuesday 22 March 2005 4:52 pm, Patrick Mochel wrote:

quoted

quoted

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