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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
