On Tuesday, July 08, 2014 01:45:30 PM Dmitry Torokhov wrote:

On Tue, Jul 08, 2014 at 10:52:52PM +0200, Rafael J. Wysocki wrote:

quoted

On Thursday, June 19, 2014 08:51:25 AM Li, Aubrey wrote:

quoted

When the wakeup attribute is set, the GPIO button is capable of
waking up the system from sleep states, including the "freeze"
sleep state.  For that to work, its driver needs to pass the
IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
interrupt will be disabled by suspend_device_irqs() and the
system won't be woken up by it from the "freeze" sleep state.

The suspend_device_irqs() routine is a workaround for drivers
that mishandle interrupts triggered when the devices handled
by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
all drivers that don't have that problem.

The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.

Signed-off-by: Aubrey Li <redacted>
Reviewed-by: Rafael J. Wysocki <redacted>

OK

Due to the lack of response (ie. no objections) and because the issue
addressed by this patch is real, I'm queuing it up as a PM-related fix
for 3.17.

Please do not. The response is till the same: board code should make sure
that enable_irq_wake() does the right thing and keeps interrupts enabled.

Which board code?  That's nothing like that for the platforms in question.

It is wrong to patch drivers for this.

Why is it?  Only drivers know if they can handle incoming interrupts after
having suspended their devices.

Rafael