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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 6 May 2010 01:33:59 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	tytso@....edu, Matthew Garrett <mjg@...hat.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Brian Swetland <swetland@...gle.com>,
	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 Thursday 06 May 2010, Mark Brown wrote:
> On Thu, May 06, 2010 at 12:05:01AM +0200, Rafael J. Wysocki wrote:
> 
> > So, gnerenally, we may need a mechanism to specify which components of the
> > system need to stay powered while the whole system is suspended (in addition to
> > wakeup devices, that is).
> 
> > That certainly I can agree with.
> 
> > I'm not sure, however, in what way this is relevant to the $subject patchset.
> 
> The patch set essentially makes using a full system suspend as the
> lowest power state for runtime PM part of the standard Linux power
> management toolkit which means that it's no longer clear as it used to
> be that suspend is an instruction to cease all activity and go into a
> minimal power state if the device is not a wake source.

I don't see why, really.  This patchset doesn't change the meaning of suspend
at all, it only changes the way in which suspend is triggered (if specifically
set up that way).  Even without the patchset you may implement a power
manager in user space that will suspend the system whenever it thinks it's
idle.

> In the primary existing application this change interoperates very poorly
> with at least the current audio subsystem since that handles suspend by
> ceasing all activity and powering as much as it can off, which is sensible for
> manual only suspends but highly undesirable for opportunistic suspend in
> phones.

You said that there's no fundamental difference between manual and
opportunistic suspend.  It only matters what _you_ are going to use suspend
for.  I agree that at the moment it's not suitable for aggressive power
management in phones because of the audio problem, but that applies to
"manual" as well as to "opportunistic" suspend.

You're saying that suspend is not suitable for one particular purpose in its
current form, which is entirely correct, but that doesn't imply that the
patchset is wrong.

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

Powered by blists - more mailing lists