[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100511170348.GA17443@srcf.ucam.org>
Date: Tue, 11 May 2010 18:03:48 +0100
From: Matthew Garrett <mjg@...hat.com>
To: Tony Lindgren <tony@...mide.com>
Cc: "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,
Alan Stern <stern@...land.harvard.edu>,
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>,
Brian Swetland <swetland@...gle.com>
Subject: Re: [PATCH 0/8] Suspend block api (version 6)
On Tue, May 11, 2010 at 09:58:21AM -0700, Tony Lindgren wrote:
> * Matthew Garrett <mjg@...hat.com> [100511 09:41]:
> > Yes. You still need suspend blocks.
>
> Maybe not if echo opportunistic > /sys/power/policy gets cleared by
> the kernel if the kernel idle loop can't make it. That means something
> has blocked the suspend attempt in a driver for example. The system
> keeps running, and the userspace can deal with the situation.
So an event arrives just as userspace does this write. How do you avoid
the race? Plausible answers mostly appear to end up looking like suspend
blockers.
--
Matthew Garrett | mjg59@...f.ucam.org
--
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