lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2724221.P8uryjLFJe@vostro.rjw.lan>
Date:	Sun, 22 Jun 2014 15:35:54 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Kevin Hilman <khilman@...aro.org>, Allen Yu <alleny@...dia.com>,
	Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] PM / Runtime: let rpm_resume fail if rpm disabled and device suspended.

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists