From: Andy Lutomirski <luto@mit.edu>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Alan Stern <stern@rowland.harvard.edu>,
mark gross <640e9920@gmail.com>, Neil Brown <neilb@suse.de>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Arve@smtp1.linux-foundation.org,
Florian Mickler <florian@mickler.org>,
Linux-pm mailing list <linux-pm@lists.linux-foundation.org>
Subject: Re: [update] Re: [RFC][PATCH] PM: Avoid losing wakeup events during suspend
Date: Thu, 24 Jun 2010 10:16:40 -0400 [thread overview]
Message-ID: <4C2368C8.7020708@mit.edu> (raw)
In-Reply-To: <201006222159.28081.rjw__37084.1419128284$1277237903$gmane$org@sisk.pl>
Rafael J. Wysocki wrote:
> On Tuesday, June 22, 2010, Rafael J. Wysocki wrote:
>> On Tuesday, June 22, 2010, Alan Stern wrote:
>>> On Tue, 22 Jun 2010, Rafael J. Wysocki wrote:
> ...
>>>> So, even if we can say when the kernel has finished processing the event
>>>> (although that would be complicated in the PCIe case above), I don't think
>>>> it's generally possible to ensure that the entire processing of a wakeup event
>>>> has been completed. This leads to the question whether or not it is worth
>>>> trying to detect the ending of the processing of a wakeup event.
>>> As Arve pointed out, in some cases it definitely is worthwhile (the
>>> gpio keypad matrix example). In other cases there may be no reasonable
>>> way to tell. That doesn't mean we have to give up entirely.
>> Well, I'm not sure, because that really depends on the hardware and bus in
>> question. The necessary condition seems to be that the event be detected
>> and handled entirely by the same functional unit (eg. a device driver) within
>> the kernel and such that it is able to detect whether or not user space has
>> acquired the event information. That doesn't seem to be a common case to me.
>
> Anyway, below's an update that addresses this particular case.
>
> It adds two more functions, pm_wakeup_begin() and pm_wakeup_end()
> that play similar roles to suspend_block() and suspend_unblock(), but they
> don't operate on suspend blocker objects. Instead, the first of them increases
> a counter of events in progress and the other one decreases this counter.
> Together they have the same effect as pm_wakeup_event(), but the counter
> of wakeup events in progress they operate on is also checked by
> pm_check_wakeup_events().
>
> Thus there are two ways kernel subsystems can signal wakeup events. First,
> if the event is not explicitly handed over to user space and "instantaneous",
> they can simply call pm_wakeup_event() and be done with it. Second, if the
> event is going to be delivered to user space, the subsystem that processes
> the event can call pm_wakeup_begin() right when the event is detected and
> pm_wakeup_end() when it's been handed over to user space.
How does userspace handle this without races? (I don't see an example
in a driver that talks to userspace in your code...)
For example, if I push a button on my keyboard, the driver calls
pm_wakeup_begin(). Then userspace reads the key from the evdev device
and tells the userspace suspend manager not to go to sleep.
But there's a race: the keyboard driver (or input subsystem) could call
pm_wakeup_end() before the userspace program has a chance to tell the
suspend manager not to sleep.
One possibility would be for poll to report that events are pending
without calling pm_wakeup_end(), giving userspace a chance to prevent
itself from suspending before actually reading the event.
(Also, should "echo mem >/sys/power/state" be different from "echo
mem_respect_suspend_blockers >/sys/power/state?" If I physically press
the suspend key on my laptop, I want it to go to sleep even though I'm
still holding the Fn key that was part of the suspend hotkey.)
--Andy
next prev parent reply other threads:[~2010-06-24 14:16 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-19 22:05 [RFC][PATCH] PM: Avoid losing wakeup events during suspend Rafael J. Wysocki
2010-06-20 5:52 ` mark gross
2010-06-20 12:49 ` Rafael J. Wysocki
2010-06-20 23:13 ` mark gross
2010-06-20 16:28 ` Alan Stern
2010-06-20 21:50 ` Rafael J. Wysocki
2010-06-21 2:23 ` Alan Stern
2010-06-21 5:32 ` Florian Mickler
2010-06-21 15:23 ` Alan Stern
2010-06-21 20:38 ` Florian Mickler
2010-06-21 22:18 ` Alan Stern
2010-06-21 22:40 ` Rafael J. Wysocki
2010-06-21 22:48 ` Rafael J. Wysocki
2010-06-22 0:50 ` Arve Hjønnevåg
2010-06-22 10:21 ` Rafael J. Wysocki
2010-06-22 14:35 ` Alan Stern
2010-06-22 15:35 ` Rafael J. Wysocki
2010-06-22 19:55 ` Alan Stern
2010-06-22 20:58 ` Rafael J. Wysocki
2010-06-22 19:59 ` [update] " Rafael J. Wysocki
2010-06-22 20:34 ` Alan Stern
2010-06-22 21:41 ` Rafael J. Wysocki
2010-06-23 2:12 ` Alan Stern
2010-06-23 10:09 ` Rafael J. Wysocki
2010-06-23 15:21 ` Alan Stern
2010-06-23 22:17 ` Rafael J. Wysocki
2010-06-24 13:13 ` [update 2] " Rafael J. Wysocki
2010-06-24 15:06 ` Rafael J. Wysocki
2010-06-24 15:35 ` Alan Stern
2010-06-24 23:00 ` [update 3] " Rafael J. Wysocki
2010-06-25 14:42 ` Alan Stern
2010-06-25 20:33 ` Rafael J. Wysocki
2010-06-24 15:44 ` [update 2] " Alan Stern
2010-06-24 16:19 ` Rafael J. Wysocki
2010-06-24 17:09 ` Alan Stern
2010-06-24 23:06 ` Rafael J. Wysocki
2010-06-25 15:09 ` Alan Stern
2010-06-25 20:37 ` Rafael J. Wysocki
2010-06-25 20:57 ` Alan Stern
2010-06-25 6:40 ` Florian Mickler
2010-06-25 13:28 ` Rafael J. Wysocki
[not found] ` <201006222159.28081.rjw__37084.1419128284$1277237903$gmane$org@sisk.pl>
2010-06-24 14:16 ` Andy Lutomirski [this message]
2010-06-24 14:45 ` [update] " Alan Stern
2010-06-24 14:48 ` Rafael J. Wysocki
2010-06-24 15:21 ` Andy Lutomirski
2010-06-22 23:00 ` mark gross
2010-06-21 16:54 ` Alan Stern
2010-06-21 20:40 ` Florian Mickler
2010-06-21 21:18 ` Rafael J. Wysocki
2010-06-21 22:27 ` Alan Stern
2010-06-21 6:13 ` mark gross
2010-06-21 12:10 ` tytso
2010-06-21 12:22 ` Alan Cox
2010-06-21 12:26 ` Florian Mickler
2010-06-21 13:42 ` tytso
2010-06-21 14:01 ` Alan Cox
2010-06-22 1:07 ` mark gross
2010-06-21 16:01 ` Alan Stern
2010-06-22 1:25 ` mark gross
2010-06-22 2:24 ` Alan Stern
2010-06-21 21:58 ` Rafael J. Wysocki
2010-06-20 22:58 ` mark gross
2010-06-21 2:33 ` Alan Stern
2010-06-21 4:04 ` [linux-pm] " David Brownell
2010-06-21 6:02 ` David Brownell
2010-06-21 15:06 ` Alan Stern
2010-06-21 5:55 ` mark gross
2010-06-21 12:39 ` Florian Mickler
2010-06-21 15:57 ` Alan Stern
2010-06-22 1:58 ` mark gross
2010-06-22 2:46 ` Alan Stern
2010-06-22 9:24 ` Rafael J. Wysocki
2010-06-22 6:18 ` Florian Mickler
2010-06-22 23:22 ` mark gross
2010-06-22 9:29 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C2368C8.7020708@mit.edu \
--to=luto@mit.edu \
--cc=640e9920@gmail.com \
--cc=Arve@smtp1.linux-foundation.org \
--cc=dmitry.torokhov@gmail.com \
--cc=florian@mickler.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=neilb@suse.de \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).