kernel/linux.git/drivers/input/keyboard/gpio_keys.c, branch linux-7.0.y

Input: gpio_keys - fall back to platform_get_irq() for interrupt-only keys

2026-02-01T08:05:00+00:00

To allow transitioning away from gpio-keys platform data attempt to retrieve IRQ for interrupt-only keys using platform_get_irq_optional() if interrupt is not specified in platform data. Signed-off-by: Dmitry Torokhov

Input: gpio_keys - replace use of system_wq with system_dfl_wq

2025-12-19T04:52:47+00:00

Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This patch continues the effort to refactor worqueue APIs, which has begun with the change introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") This specific workload do not benefit from a per-cpu workqueue, so use the default unbound workqueue (system_dfl_wq) instead. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Link: https://patch.msgid.link/20251106141955.218911-2-marco.crivellari@suse.com Signed-off-by: Dmitry Torokhov

Input: gpio-keys - fix possible concurrent access in gpio_keys_irq_timer()

2025-05-30T23:15:42+00:00

gpio_keys_irq_isr() and gpio_keys_irq_timer() access the same resources. There could be a concurrent access if a GPIO interrupt occurs in parallel of a HR timer interrupt. Guard back those resources with a spinlock. Fixes: 019002f20cb5 ("Input: gpio-keys - use hrtimer for release timer") Signed-off-by: Gatien Chevallier Link: https://lore.kernel.org/r/20250528-gpio_keys_preempt_rt-v2-2-3fc55a9c3619@foss.st.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov

Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT

2025-05-30T23:15:41+00:00

When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in hard irq context, but the input_event() takes a spin_lock, which isn't allowed there as it is converted to a rt_spin_lock(). [ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0 ... [ 4054.290195] __might_resched+0x13c/0x1f4 [ 4054.290209] rt_spin_lock+0x54/0x11c [ 4054.290219] input_event+0x48/0x80 [ 4054.290230] gpio_keys_irq_timer+0x4c/0x78 [ 4054.290243] __hrtimer_run_queues+0x1a4/0x438 [ 4054.290257] hrtimer_interrupt+0xe4/0x240 [ 4054.290269] arch_timer_handler_phys+0x2c/0x44 [ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c [ 4054.290297] handle_irq_desc+0x40/0x58 [ 4054.290307] generic_handle_domain_irq+0x1c/0x28 [ 4054.290316] gic_handle_irq+0x44/0xcc Considering the gpio_keys_irq_isr() can run in any context, e.g. it can be threaded, it seems there's no point in requesting the timer isr to run in hard irq context. Relax the hrtimer not to use the hard context. Fixes: 019002f20cb5 ("Input: gpio-keys - use hrtimer for release timer") Suggested-by: Sebastian Andrzej Siewior Signed-off-by: Fabrice Gasnier Signed-off-by: Gatien Chevallier Link: https://lore.kernel.org/r/20250528-gpio_keys_preempt_rt-v2-1-3fc55a9c3619@foss.st.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov

treewide: Convert new and leftover hrtimer_init() users

2025-04-05T08:30:17+00:00

hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Coccinelle scripted cleanup. Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar

Input: gpio_keys - avoid using GPIOF_ACTIVE_LOW

2024-11-09T13:55:33+00:00

Avoid using GPIOF_ACTIVE_LOW as it's deprecated and subject to remove. Signed-off-by: Andy Shevchenko Acked-by: Dmitry Torokhov Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20241104093609.156059-2-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski

Input: gpio-keys - switch to using cleanup functions

2024-09-06T05:53:20+00:00

Start using __free() and guard() primitives to simplify the code and error handling. This makes the code more compact and error handling more robust by ensuring that locks are released in all code paths when control leaves critical section and all allocated memory is freed. Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20240825051627.2848495-6-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov

Input: gpio_keys - use device_for_each_child_node_scoped()

2024-07-16T00:02:13+00:00

Switch to the _scoped() version introduced in commit 365130fd47af ("device property: Introduce device_for_each_child_node_scoped()") to remove the need for manual calling of fwnode_handle_put() in the paths where the code exits the loop early. Signed-off-by: Javier Carrasco Link: https://lore.kernel.org/r/20240412-input_device_for_each_child_node_scoped-v1-3-dbad1bc7ea84@gmail.com Signed-off-by: Dmitry Torokhov

Input: gpio-keys - filter gpio_keys -EPROBE_DEFER error messages

2023-12-29T07:44:55+00:00

commit ae42f9288846 ("gpio: Return EPROBE_DEFER if gc->to_irq is NULL") make gpiod_to_irq() possible to return -EPROBE_DEFER when the racing happens. This causes the following error message to be printed: gpio-keys gpio_keys: Unable to get irq number for GPIO 0, error -517 Fix that by changing dev_err() to dev_err_probe() Signed-off-by: Hermes Zhang Link: https://lore.kernel.org/r/20231229013657.692600-1-Hermes.Zhang@axis.com Signed-off-by: Dmitry Torokhov

Input: gpio-keys - add system suspend support for dedicated wakeirqs

2023-11-30T20:06:55+00:00

Some SoCs have a separate dedicated wake-up interrupt controller that can be used to wake up the system from deeper idle states. We already support configuring a separate interrupt for a gpio-keys button to be used with a gpio line. However, we are lacking support system suspend for cases where a separate interrupt needs to be used in deeper sleep modes. Because of it's nature, gpio-keys does not know about the runtime PM state of the button gpios, and may have several gpio buttons configured for each gpio-keys device instance. Implementing runtime PM support for gpio-keys does not help, and we cannot use drivers/base/power/wakeirq.c support. We need to implement custom wakeirq support for gpio-keys. For handling a dedicated wakeirq for system suspend, we enable and disable it with gpio_keys_enable_wakeup() and gpio_keys_disable_wakeup() that we already use based on device_may_wakeup(). Some systems may have a dedicated wakeirq that can also be used as the main interrupt, this is already working for gpio-keys. Let's add some wakeirq related comments while at it as the usage with a gpio line and separate interrupt line may not be obvious. Tested-by: Dhruva Gole Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20231129110618.27551-2-tony@atomide.com Signed-off-by: Dmitry Torokhov