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:	Fri, 7 May 2010 12:21:03 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Arve Hjønnevåg <arve@...roid.com>
Cc:	Brian Swetland <swetland@...gle.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Matthew Garrett <mjg@...hat.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Kevin Hilman <khilman@...prootsystems.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 Fri, May 07, 2010 at 03:57:37AM -0700, Arve Hjønnevåg wrote:
> 2010/5/7 Mark Brown <broonie@...nsource.wolfsonmicro.com>:

> > As discussed elsewhere in the thread a suspend blocker is not desirable
> > here - the AP is not doing anything useful on a voice call so blocking
> > the suspend will just waste power unless runtime PM is good enough to
> > mean opportunistic suspend isn't adding anything anyway.  It will avoid
> > the immediate issue with loosing audio but it's not really what we want
> > to happen.

> I was talking about audio from the AP. Why would you ever turn off
> another core's audio path on suspend?

This goes back to the thing about a full system suspend being a
sledgehammer which doesn't give enough information about what's going
on when it's used like this.  As discussed we need a way to know that
the connections involved are able to stay live during suspend (on a
large proportion of systems suspend is going to mean that the relevant
bits of the board will loose power so need to be shut down) and that
that the intention of the user is that they should do so (this isn't
clear in the general system, especially not if the suspend is initiated
manually).  

With a runtime PM approach this is trivial - we just turn off anything
that isn't in use at the current time.  I'll need to extend ASoC to add
information about what to do on suspend to the existing power data.
--
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/