Re: [PATCH 1/1] PM / Runtime: let rpm_resume fail if rpm disabled and device suspended.

[Rafael J. Wysocki]

On Saturday, June 21, 2014 09:34:28 AM Alan Stern wrote:
> On Fri, 20 Jun 2014, Kevin Hilman wrote:
> 
> > > For a general device, the fact that dev->power.is_suspended is set
> > > means the device _has_ been powered down.  Even though the
> > > runtime_status may not have changed, the PM core has to assume the
> > > device is not available for use.
> > 
> > This is where things get fuzzy because of the overlap between system PM
> > and runtime PM.  It makes sense that from a system PM perspecitve, the
> > core has to assume the device isn't available.  But from a runtime PM
> > perspective, we know that it is, so we allow the *runtime PM* requests
> > to succeed.
> 
> Well, to be fair, from a runtime PM perspective the core _doesn't_
> know that the device is available.  For example, if we were talking
> about a USB device rather than an I2C device, it _wouldn't_ be
> available.
> 
> The fact is, after ->suspend returns some devices are still available
> and some aren't.  Currently the PM core doesn't know which are which.

That's correct.  As a result of this, the core should not make any assumptions
about the device's physical state after ->suspend() has been executed.

Well, the core shouldn't actually make any assumptions about the device's
physical state at any given time at all, because it never knows what that state
is.

What it can do (and what the runtime PM rules are for) is to refuse to carry
out operations that generally don't make sense, like calling ->runtime_resume()
twice in a row, for example.

Currently, we have separate rules for runtime PM and for system suspend/resume,
but it looks like we really need to establish a set of rules that will cover
*both* runtime PM and system suspend/resume at the same time.  Of course, it
needs to be compatible with the existing rules as far as reasonably possible.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/