Hello Dmitry,
I may have found a potential bug in the "gpio_keys" driver. FYI, I am running the 4.14 LTS kernel on my system, but from my understanding of the issue, it seems that this would still occur in the latest version of the kernel.
The problem:
In the 4.14 LTS kernel, both key press and release events can generate a wake event. In the 5.x kernel, wake events are configurable for press only, release only or "both" (see "wakeup-event-action" binding). The issue can occur in the "both" case or release/deasserted case. Let's imagine that a system is suspended when a gpio key button is pressed, and subsequently resumed when the button is released. If we look at the sequence of actions and events reported by the input system, we can see the potential problem:
Button Pressed
Event Value 1
System Suspend
Button Released
System Wake & Resume
Event Value 0
Event Value 1
Event Value 0
As you can see the input system will report an extra button event/press. This appears to be caused in gpio_keys_gpio_isr by the following statement:
if (bdata->suspended &&
(button->type == 0 || button->type == EV_KEY)) {
/*
* Simulate wakeup key press in case the key has
* already released by the time we got interrupt
* handler to run.
*/
input_report_key(bdata->input, button->code, 1);
}
This code does not seem to take into account that the wake event may have been caused by a button release action, and just assumes we must have a button press.
This can obviously be problematic in the use case I mentioned, as the system would be put in a constant loop between waking and sleeping. While there are other ways to deal with or react to this issue in the userspace, it seems that the driver should probably take this into account.
Thoughts?
Thanks,
Ken Sloat
