Re: [PATCH v3 1/3] Input: gpio-keys - add support for wakeup event action
From: Brian Norris <briannorris@chromium.org>
Date: 2018-03-03 01:10:17
Also in:
lkml
Hi Jeffy, On Fri, Mar 02, 2018 at 11:51:00AM +0800, Jeffy Chen wrote:
quoted hunk ↗ jump to hunk
Add support for specifying event actions to trigger wakeup when using the gpio-keys input device as a wakeup source. This would allow the device to configure when to wakeup the system. For example a gpio-keys input device for pen insert, may only want to wakeup the system when ejecting the pen. Suggested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Jeffy Chen <redacted> --- Changes in v3: Adding more comments as Brian suggested. Changes in v2: Specify wakeup event action instead of irq trigger type as Brian suggested. drivers/input/keyboard/gpio_keys.c | 39 ++++++++++++++++++++++++++++++++++ include/linux/gpio_keys.h | 2 ++ include/uapi/linux/input-event-codes.h | 9 ++++++++ 3 files changed, 50 insertions(+)diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c index 87e613dc33b8..607f3960c886 100644 --- a/drivers/input/keyboard/gpio_keys.c +++ b/drivers/input/keyboard/gpio_keys.c
...
quoted hunk ↗ jump to hunk
@@ -586,6 +606,12 @@ static int gpio_keys_setup_key(struct platform_device *pdev, isr = gpio_keys_irq_isr; irqflags = 0; + + /* + * For IRQ buttons, the irq trigger type for press and release + * are the same. So we don't need to reconfigure the trigger + * type for wakeup. + */
Ah, I think I misunderstood what the (non-GPIO) IRQ-based trigger was doing. It's just emulating an instantaneous press/release (or, with a configurable release delay), so there isn't really a way to say "only wake me on one edge". So that still doesn't really mean we use the "same" trigger for all wakeup trigger types. It really just means we can't support any customization here -- we wake based on whatever the IRQ represents (which today is probably just EV_ACT_ANY). I guess it's fine to just ignore the wakeup-trigger-type property here, but it would also be equally valid to reject it outright I think. Anyway, that's only a mild complaint. For the whole series: Tested-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Thanks!
} bdata->code = &ddata->keymap[idx];
...
quoted hunk ↗ jump to hunk
diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 53fbae27b280..d7917b0bd438 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h@@ -32,6 +32,15 @@ #define INPUT_PROP_CNT (INPUT_PROP_MAX + 1) /* + * Event action types + */ +#define EV_ACT_ANY 0x00 /* asserted or deasserted */ +#define EV_ACT_ASSERTED 0x01 /* asserted */ +#define EV_ACT_DEASSERTED 0x02 /* deasserted */ +#define EV_ACT_MAX 0x02 +#define EV_ACT_CNT (EV_ACT_MAX+1) + +/* * Event types */-- 2.11.0