[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1110131111200.2026-100000@iolanthe.rowland.org>
Date: Thu, 13 Oct 2011 11:16:23 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: NeilBrown <neilb@...e.de>
cc: markgross@...gnar.org, <linux-kernel@...r.kernel.org>,
John Stultz <john.stultz@...aro.org>,
"Rafael J. Wysocki" <rjw@...k.pl>, <arve@...roid.com>,
<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: [RFC] wake up notifications and suspend
blocking (aka more wakelock stuff)]
On Thu, 13 Oct 2011, NeilBrown wrote:
> Nope, but I'm keen for you to convince me. Identify a wakeup event that
> cannot be made visible to poll (or to user-space by some other
> mechanism) before the wakeup_source needs to be deactivated. Or if I've
> misunderstood what sort of notification is problematic, help me understand.
Here's an example (just for kicks, not completely relevant to your
discussion): A USB keyboard key release. Unlike key presses, key
releases need not generate input events. If no processes are
monitoring the raw keyboard event queue then the release is not visible
to userspace at all, hence not visible before the wakeup_source needs
to be deactivated.
Alan Stern
--
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