[OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: fix always missing first event

David Bauer mail at david-bauer.net
Thu Jun 13 16:56:51 EDT 2019

Hello Petr,

On 13.06.19 21:50, Petr Štetiar wrote:
> David Bauer <mail at david-bauer.net> [2019-06-11 23:52:46]:
> Hi,
>> I ran into problems booting multiple QCA9558 boards, namely the OCEDO
>> Koala and the devolo WiFi pro 1200e with the current master. Both
>> devices always go into failsafe mode when powering on.
> ar71xx or ath79? Can you test if it happens also with the interrupt based
> `gpio-keys` variant?

I did some further testing, the issue on my Koala was a hardware fault
(the reset switch was physically broken m( ). With the hardware button
fixed, it does not show this behavior.

This was expected though as it uses polled gpio-keys instead of the
interrupt based ones.

The devolo WiFi pro 1200e is ath79 with the interrupt-based gpio-keys.
The issue is not present when using polled gpio-keys. The device does
not go into failsafe when using polled GPIO keys.

>> I haven't dug deeper into this issue, but reverting 6c5bfaac84 leads
>> into both boards booting normally.
> could you please compile kernel with `CONFIG_KERNEL_DYNAMIC_DEBUG=y` and then
> add to the kernel cmdline `gpio_button_hotplug.dyndbg='file gpio-button* +p'`
> (or to modprobe args) and provide the output?

I did some further testing and i think i've found the culprit - On
probe the GPIO reads high. Shortly after probe, an interrupt is received
and the GPIO switched to low which triggers a button event and therefore
sends the device into failsafe. I suppose the GPIO has just switched to
a stable state which triggers this interrupt.

I've prepared a patch which reads the initial state after the debounce
interval on probe to ensure only real button presses will trigger an
event. I will send this patch shortly.

Best wishes

> Thanks.
> -- ynezz

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list