linux.git/drivers/input, branch v6.16-rc2 Linux kernel source tree treewide, timers: Rename from_timer() to timer_container_of() 2025-06-08T07:07:37+00:00 Ingo Molnar mingo@kernel.org 2025-05-09T05:51:14+00:00 41cb08555c4164996d67c78b3bf1c658075b75f1 Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com 
Move this API to the canonical timer_*() namespace.

[ tglx: Redone against pre rc1 ]

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com
Merge branch 'next' into for-linus 2025-06-02T04:41:07+00:00 Dmitry Torokhov dmitry.torokhov@gmail.com 2025-06-02T04:41:07+00:00 4f9786035f9e519db41375818e1d0b5f20da2f10 Prepare input updates for 6.16 merge window. 
Prepare input updates for 6.16 merge window.
Input: ims-pcu - check record size in ims_pcu_flash_firmware() 2025-05-30T23:15:43+00:00 Dan Carpenter dan.carpenter@linaro.org 2025-05-30T23:13:32+00:00 a95ef0199e80f3384eb992889322957d26c00102 The "len" variable comes from the firmware and we generally do trust firmware, but it's always better to double check. If the "len" is too large it could result in memory corruption when we do "memcpy(fragment->data, rec->data, len);" Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/131fd1ae92c828ee9f4fa2de03d8c210ae1f3524.1748463049.git.dan.carpenter@linaro.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
The "len" variable comes from the firmware and we generally do
trust firmware, but it's always better to double check.  If the "len"
is too large it could result in memory corruption when we do
"memcpy(fragment->data, rec->data, len);"

Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/131fd1ae92c828ee9f4fa2de03d8c210ae1f3524.1748463049.git.dan.carpenter@linaro.org
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: gpio-keys - fix possible concurrent access in gpio_keys_irq_timer() 2025-05-30T23:15:42+00:00 Gatien Chevallier gatien.chevallier@foss.st.com 2025-05-30T23:09:23+00:00 8f38219fa139623c29db2cb0f17d0a197a86e344 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 <gatien.chevallier@foss.st.com> 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 <dmitry.torokhov@gmail.com> 
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 <gatien.chevallier@foss.st.com>
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 <dmitry.torokhov@gmail.com>
Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT 2025-05-30T23:15:41+00:00 Fabrice Gasnier fabrice.gasnier@foss.st.com 2025-05-30T22:36:43+00:00 f4a8f561d08e39f7833d4a278ebfb12a41eef15f 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 <bigeasy@linutronix.de> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> 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 <dmitry.torokhov@gmail.com> 
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 <bigeasy@linutronix.de>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
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 <dmitry.torokhov@gmail.com>
Input: synaptics-rmi - fix crash with unsupported versions of F34 2025-05-19T18:58:36+00:00 Dmitry Torokhov dmitry.torokhov@gmail.com 2025-05-05T22:49:59+00:00 ca39500f6af9cfe6823dc5aa8fbaed788d6e35b2 Sysfs interface for updating firmware for RMI devices is available even when F34 probe fails. The code checks for presence of F34 "container" pointer and then tries to use the function data attached to the sub-device. F34 assigns the function data early, before it knows if probe will succeed, leaving behind a stale pointer. Fix this by expanding checks to not only test for presence of F34 "container" but also check if there is driver data assigned to the sub-device, and call dev_set_drvdata() only after we are certain that probe is successful. This is not a complete fix, since F34 will be freed during firmware update, so there is still a race when fetching and accessing this pointer. This race will be addressed in follow-up changes. Reported-by: Hanno Böck <hanno@hboeck.de> Fixes: 29fd0ec2bdbe ("Input: synaptics-rmi4 - add support for F34 device reflash") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/aBlAl6sGulam-Qcx@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
Sysfs interface for updating firmware for RMI devices is available even
when F34 probe fails. The code checks for presence of F34 "container"
pointer and then tries to use the function data attached to the
sub-device. F34 assigns the function data early, before it knows if
probe will succeed, leaving behind a stale pointer.

Fix this by expanding checks to not only test for presence of F34
"container" but also check if there is driver data assigned to the
sub-device, and call dev_set_drvdata() only after we are certain that
probe is successful.

This is not a complete fix, since F34 will be freed during firmware
update, so there is still a race when fetching and accessing this
pointer. This race will be addressed in follow-up changes.

Reported-by: Hanno Böck <hanno@hboeck.de>
Fixes: 29fd0ec2bdbe ("Input: synaptics-rmi4 - add support for F34 device reflash")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/aBlAl6sGulam-Qcx@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: atkbd - do not reset keyboard by default on Loongson 2025-05-19T18:47:39+00:00 Qunqin Zhao zhaoqunqin@loongson.cn 2025-05-19T18:44:02+00:00 21597378dd5123a4d547c014b7d953a88575c910 The keyboard is properly initialized by the firmware on Loongson platform, so full reset of the keyboard is not needed. Switch the default to avoid performing full reset of the keyboard. Signed-off-by: Qunqin Zhao <zhaoqunqin@loongson.cn> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Link: https://lore.kernel.org/r/20250401094154.11527-1-zhaoqunqin@loongson.cn Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
The keyboard is properly initialized by the firmware on Loongson
platform, so full reset of the keyboard is not needed. Switch the
default to avoid performing full reset of the keyboard.

Signed-off-by: Qunqin Zhao <zhaoqunqin@loongson.cn>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://lore.kernel.org/r/20250401094154.11527-1-zhaoqunqin@loongson.cn
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: xpad - send LED and auth done packets to all Xbox One controllers 2025-05-17T01:16:42+00:00 Vicki Pfau vi@endrift.com 2025-05-13T22:54:01+00:00 0d5c604be4cd08bd04075932bfb57da9aaf8820e This mirrors what SDL does, and is closer to Windows's behavior as-is. Signed-off-by: Vicki Pfau <vi@endrift.com> Link: https://lore.kernel.org/r/20250513225411.2718072-4-vi@endrift.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
This mirrors what SDL does, and is closer to Windows's behavior as-is.

Signed-off-by: Vicki Pfau <vi@endrift.com>
Link: https://lore.kernel.org/r/20250513225411.2718072-4-vi@endrift.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: xpad - add the ByoWave Proteus controller 2025-05-17T01:16:37+00:00 Pierre-Loup A. Griffais pgriffais@valvesoftware.com 2025-05-13T22:54:00+00:00 898170cc80f200b91ab6b89d8d5119bc7cbb84d8 Signed-off-by: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com> Signed-off-by: Vicki Pfau <vi@endrift.com> Link: https://lore.kernel.org/r/20250513225411.2718072-3-vi@endrift.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
Signed-off-by: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>
Signed-off-by: Vicki Pfau <vi@endrift.com>
Link: https://lore.kernel.org/r/20250513225411.2718072-3-vi@endrift.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: xpad - allow delaying init packets 2025-05-17T01:15:53+00:00 Vicki Pfau vi@endrift.com 2025-05-13T22:53:59+00:00 036ec442510b04c8740ec6c2d9e995d25719535f Some Xbox One controllers will only start processing the init packets after sending the GIP announce packet. While most controllers send this packet immediately, others will delay for some time, e.g. if a dongle needs to connect to an actual controller first. In those cases, we want to delay until we receive the announce packet before sending the init sequence. Signed-off-by: Vicki Pfau <vi@endrift.com> Link: https://lore.kernel.org/r/20250513225411.2718072-2-vi@endrift.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
Some Xbox One controllers will only start processing the init packets after
sending the GIP announce packet. While most controllers send this packet
immediately, others will delay for some time, e.g. if a dongle needs to connect
to an actual controller first. In those cases, we want to delay until we
receive the announce packet before sending the init sequence.

Signed-off-by: Vicki Pfau <vi@endrift.com>
Link: https://lore.kernel.org/r/20250513225411.2718072-2-vi@endrift.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>