linux-kernel - Re: [markgross@...ngar.org: Re: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)]

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] [day] [month] [year] [list]

Date:	Mon, 3 Oct 2011 17:35:49 -0700
From:	mark gross <markgross@...gnar.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	markgross@...gnar.org, linux-kernel@...r.kernel.org,
	John Stultz <john.stultz@...aro.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, arve@...roid.com,
	Alan Stern <stern@...land.harvard.edu>,
	amit.kucheria@...aro.org, farrowg@...ibm.com,
	"Dmitry Fink (Palm GBU)" <Dmitry.Fink@...m.com>,
	linux-pm@...ts.linux-foundation.org, khilman@...com,
	Magnus Damm <damm@...nsource.se>, mjg@...hat.com,
	peterz@...radead.org
Subject: Re: [markgross@...ngar.org: Re: [RFC] wake up notifications and
 suspend blocking (aka more wakelock stuff)]

On Mon, Oct 03, 2011 at 09:32:26AM +0100, Alan Cox wrote:
> On Sun, 2 Oct 2011 09:48:49 -0700
> mark gross <markgross@...gnar.org> wrote:
> 
> > Forwarding to bigger group for discussion.
> 
> Looks clean enough - only question I have is do we need a separate
> 'suspend block' or can latency do it -suspend is a very very high latency
> event. I guess the suspend block is clearer in intent than abusing latency
> but I do wonder if the actual suspend path should also check latency
> constraints too. If I've asked for 5mS latency then suspend is a wrong
> choice!
> 
I don't think over loading the meaning of cpu_dma_latency would work
well for this.  If cpu_dma_latency constraint is > 5mS then EFAIL a
suspend attempt?  feels clunky.

If you use less than then anyone using a constraint (like some wifi
and audio) would block suspend.  also not so good.  


The poster child for needing this is the USB gadget device with
associated charging over USB.  Here we can't sleep because we'd have a
hard time meeting USB spec if we did.  Also, we don't want to sleep
while charging if charging is under OS control.  (checking temperature
is tricky while suspended.)

--mark

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