2010/5/18 Rafael J. Wysocki <rjw@xxxxxxx>: > On Tuesday 18 May 2010, Arve Hjønnevåg wrote: >> 2010/5/18 Rafael J. Wysocki <rjw@xxxxxxx>: >> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote: >> >> On Mon, May 17, 2010 at 2:44 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: >> >> > On Monday 17 May 2010, Brian Swetland wrote: >> >> >> On Mon, May 17, 2010 at 1:40 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: >> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote: >> >> >> >> > ... >> >> > Now, to make it more "user-friendly", we can simply use >> > queue_delayed_work() with a reasonable delay instead of queue_work() to queue >> > the suspend work (the delay may be configurable via sysfs). >> > >> >> I can add a delay (and the timeout support code does add a delay as an >> optimization) to the unknown wakeup case, but this does not fix the >> problem of a user turning on opportunistic suspend with a user space >> framework that does not use suspend blockers. If the kernel uses >> suspend blockers to make sure the wakeup event makes it to user space, >> but user space does not block suspend, then the system will suspend >> before the event is processed. > > But the user can still manually write to /sys/power/state. :-) > Does adding or removing a delay change this? It seems in only changes how quickly the user can finish that write. I'm not convinced adding a configurable delay here is necessary. Once the driver that enabled the wakeup event has been updated to block suspend until this event gets to user space, then this delay will never be triggered. The kernel cannot tell the difference between a user enabling opportunistic suspend but not wanting it and opportunistic suspend aware user space code deciding that this wakeup event should be ignored. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
