linux-kernel - Re: [PATCH 0/8] Suspend block api (version 6)

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:	Wed, 5 May 2010 21:26:38 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	tytso@....edu, Matthew Garrett <mjg@...hat.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Brian Swetland <swetland@...gle.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Arve Hj?nnev?g <arve@...roid.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
	Paul Walmsley <paul@...an.com>, magnus.damm@...il.com,
	mark gross <mgross@...ux.intel.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Geoff Smith <geoffx.smith@...el.com>, rebecca@...roid.com
Subject: Re: [PATCH 0/8] Suspend block api (version 6)

On Wed, May 05, 2010 at 03:55:34PM -0400, tytso@....edu wrote:

> I confess I've completely lost track of (a) what problem you are
> trying to solve, and (b) how this might relate to some change that
> you'd like to see in the suspend block API.  Could you do a quick
> summary and recap?  I've gone over the entire thread, and it's still
> not clear what change you're advocating for in suspend blockers.

The issue isn't suspend blockers, it's the opportunistic suspend stuff
that goes along with them.  When that is in use the system suspends
vastly more aggressively, including in situations where a runtime PM
based approach like mainline had been adopting would not suspend since
some devices still need to be active, the classic case being keeping the
audio subsystem and baseband live when in a phone call.  This problem
did not appear to have been considered as things stood.  

I'm not really advocating a change in what's there.  What I'm looking
for is some sort of agreement as to how subsystems and drivers that need
to not act on suspend requests from the core in these situations should
do that.  If there is a generic solution it'd probably be an additional
mostly orthogonal interface rather than a change to what's being
proposed here.

What we look like we're converging on is a subsystem/driver local
solution since it doesn't look like a terribly widespread problem.
That's totally OK, it's just that as I have said I don't want to go off
and do that without the general PM community being aware of it so we
avoid anyone running into nasty surprises further down the line.
--
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/