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 20:07:58 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Matthew Garrett <mjg@...hat.com>,
	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>
Subject: Re: [PATCH 0/8] Suspend block api (version 6)

On Wed, May 05, 2010 at 02:36:10PM -0400, Alan Stern wrote:

> Clearly if there's a call in progress you don't want to shut the codec
> down.  Are there any other circumstances?  Would they vary according to
> whether the suspend was forced or opportunistic?

Aside from things where the CODEC is acting as a wake source (for stuff
like jack detect) which are obviously already handled it's basically
just when you've got an external audio source flowing through the device
which is going to continue to function during suspend.  Things like FM
radios, for example.  I'm not aware of non-audio examples that are use
case specific and don't just involve utterly ignoring AP suspends.

> In short, I'm trying to get at how much information drivers _really_ 
> need to have about the reason for a system suspend.

It's not exactly the *reason* that makes the difference, it's more that
this aggressive use of suspend makes much more apparent a problem which
might exist anyway for this sort of hardware.

When we get runtime PM delviering similar power levels we'll sidestep
the problem since we won't need to do a system wide suspend.
--
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/