[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100528140537.GE25798@srcf.ucam.org>
Date: Fri, 28 May 2010 15:05:37 +0100
From: Matthew Garrett <mjg59@...f.ucam.org>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Arve Hjønnevåg <arve@...roid.com>,
Alan Stern <stern@...land.harvard.edu>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Florian Mickler <florian@...kler.org>, felipe.balbi@...ia.com,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Fri, May 28, 2010 at 02:55:26PM +0100, Alan Cox wrote:
> The following cannot occur on my laptop for simple idling
>
> Alarm
> Suspend
>
> because the Alarm resets the suspend timer when it is delivered.
Userspace is about to write to /sys/power/state when it gets scheduled.
Alarm delivery occurs at that instant. Kernel has no idea that it's
about to go to sleep, so the driver handles things appropriately and
clears the hardware state. Userspace gets scheduled, writes and the
system suspends. The problem is that having userspace decidie to
initiate a suspend and then actually initiate a suspend isn't an atomic
operation.
--
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