linux-kernel - Re: [linux-pm] suspend blockers & Android integration

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]

Date:	Fri, 11 Jun 2010 09:28:22 -0500
From:	James Bottomley <James.Bottomley@...e.de>
To:	David Brownell <david-b@...bell.net>
Cc:	Brian Swetland <swetland@...gle.com>, Pavel Machek <pavel@....cz>,
	tytso@....edu, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Florian Mickler <florian@...kler.org>,
	Neil Brown <neilb@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Felipe Balbi <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] suspend blockers & Android integration

On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
> Do we at least have a clean way that a driver can
> reject a system suspend?  I've lost track of many
> issues, but maybe this could be phrased as a QOS
> constraint:  the current config of driver X needs
> clock Y active to enter the  target system suspend
> state, driver's suspend() method reports as much.  Then the entry to
> that system state gets blocked
> if the clock isn't enabled.

So in QoS modifications to android patches, the answer is "yes" ...
except that the current android patch set didn't actually have this type
of wakelock in it.

Android wants an idleness suspend block (or pm qos constraint) that a
driver can set to prevent the system idleness power govenor from
dropping into a power state too low for the driver, so in USB terms this
would prevent the states that shut down the clock.  For android, it
prevented shutdown of an internal i2c bus.

The one thing that does look difficult is that these power constraints
are device (and sometimes SoC) specific.  Expressing them in a generic
way for the cpu govenors to make sense of might be hard.

> (That QOS constraint should be removed when that
> driver no longer needs to issue wakeups; that's
> not quite the same as "removed by driver.resume().

The USB one needs user input, doesn't it, since user hot plug might (or
might not) be one of the wakeup sources.

James

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