linux-kernel - Re: [PATCH 7/10 v6] PM / Domains: Don't stop wakeup devices during system sleep transitions

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: <87fwmsnqno.fsf@ti.com>
Date:	Wed, 29 Jun 2011 16:50:35 -0700
From:	Kevin Hilman <khilman@...com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Linux PM mailing list <linux-pm@...ts.linux-foundation.org>,
	"Greg Kroah-Hartman" <gregkh@...e.de>,
	Magnus Damm <magnus.damm@...il.com>,
	Paul Walmsley <paul@...an.com>,
	Alan Stern <stern@...land.harvard.edu>,
	LKML <linux-kernel@...r.kernel.org>, linux-sh@...r.kernel.org,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH 7/10 v6] PM / Domains: Don't stop wakeup devices during system sleep transitions

"Rafael J. Wysocki" <rjw@...k.pl> writes:

> From: Rafael J. Wysocki <rjw@...k.pl>
>
> Devices that are set up to wake up the system from sleep states
> should not be stopped and power should not be removed from them
> when the system goes into a sleep state.  

I don't think this belongs in the generic layer since the two
assumptions above are not generally true on embedded systems, and would
result in rather significant power consumption unnecessarily.

First, whether the device should be stopped on device_may_wakeup():

Some IP blocks (at least on OMAP) have "asynchronous" wakeups.  Meaning
that they can generate wakeups even when they're not clocked (a.k.a
stopped).  So in this case, even after a ->stop_device (which clock
gates the IP), it can still generate wakeups.

Second, whether the device should be powered off if device_may_wakeup():

Embedded SoCs have other ways to wakeup than device-level wakeups.

For example, on OMAP, every pad on the SoC can be configured as a wakeup
source So, for example, you could completely power down the UART IP
blocks (and the enclosing power domain), configure the UART RX pad as a
wakeup source, and still wakeup the system on UART activity.  The OMAP
docs call these IO pad wakeups.

On OMAP in fact, this is the common, default behavior when we enable
"off-mode" in idle and/or suspend, since most of the IPs are powered off
but can still wake up the system.

So in summary, even if device_may_wakeup() is true, many devices (with
additional SoC magic) can still generate wakeups even when stopped and
powered off.

Kevin
--
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/