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 22:28:19 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Matthew Garrett <mjg@...hat.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	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>
Subject: Re: [PATCH 0/8] Suspend block api (version 6)

On Wednesday 05 May 2010, Alan Stern wrote:
> On Wed, 5 May 2010, Matthew Garrett wrote:
> 
> > On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:
> > 
> > > One the face of it, a runtime-PM solution would dictate that the
> > > codec's driver ought to turn off the codec whenever the driver thinks
> > > it isn't being used.  Ergo, if the driver didn't know when a call was
> > > in progress, it would use runtime PM to turn off the codec during a
> > > call.
> > 
> > Well, part of the problem is that right now most of our beliefs about 
> > imposed constraints tend to be based on what userspace is doing - "Don't 
> > power down the audio codec when userspace has it open", for instance. 
> > But that goes away with opportunistic suspend. In most cases you don't 
> > want the audio codec to stay awake just because userspace was using it 
> > to make bouncing cow noises, especially if you've just frozen userspace. 
> > So the problem becomes more complicated than it would otherwise be.
> 
> It sounds like the problem can be stated simply enough: At the moment, 
> nobody knows when the codec should be powered down!  Userspace might 
> have some idea, but even if its ideas are right it has no way of 
> communicating them to the kernel.
> 
> The power/control sysfs attribute was intended for just that purpose,
> although it was aimed at runtime PM rather than system PM.  
> Nevertheless, it or something like it could be used.  Of course, there 
> would still remain the issue of userspace telling the kernel not to 
> power down the codec while making bouncing cow noises -- but at this 
> point it's not really a kernel problem any more.

We'd need a separate control, I think.  The problem is, though, that the
Android user space, for example, doesn't use the sysfs attributes of devices,
so this control wouldn't be particularly useful for it.

> P.S.: What happens if a suspend occurs while a call is in progress, so
> the codec is left powered up, and then the call ends?  Does the system
> wake up at that point?  Or does it stay suspended with the codec still
> powered, even though it's not needed any more?

I guess you end up telling the user that the call ended, so the system wakes up.
That's only a guess, though.

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/