kernel/git/next/linux-next.git/drivers/input/keyboard, branch master

Merge branch 'next' of https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git

2026-09-10T15:06:51+00:00

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git

2026-09-10T12:20:37+00:00

Merge branch 'for-linus' of https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git

2026-09-10T11:52:20+00:00

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

Input: samsung-keypad - remove support for platform data

2026-09-04T14:06:43+00:00

Because there are no more users of samsung_keypad_platdata left in the kernel remove support for it from the driver. The driver supports generic device properties so all configuration should be done using them instead of a custom platform data. Acked-by: Bartosz Golaszewski Signed-off-by: Dmitry Torokhov Link: https://patch.msgid.link/20260711-samsung-kp-v3-5-b2fcaba77aff@gmail.com Signed-off-by: Krzysztof Kozlowski

Input: samsung-keypad - handle compact binding

2026-09-04T14:06:01+00:00

Add support for standard matrix keymap binding (in addition to the existing verbose binding with a sub-node for each key). This will allow easier conversions from platform data to device properties when using static device properties. Acked-by: Bartosz Golaszewski Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov Link: https://patch.msgid.link/20260711-samsung-kp-v3-2-b2fcaba77aff@gmail.com Signed-off-by: Krzysztof Kozlowski

Input: atkbd - skip deactivate for Xiaomi Redmi Book Pro 16 2026

2026-08-28T12:03:22+00:00

The internal keyboard of the Xiaomi Redmi Book Pro 16 2026 (board TM2425) does not work: atkbd_probe() succeeds and every command is ACKed, but no scancodes ever arrive afterwards. Testing on the hardware through serio_raw shows that ATKBD_CMD_RESET_DIS (0xF5) is the culprit. After 0xF5 the embedded controller keeps ACKing commands but stops delivering scancodes, and neither ATKBD_CMD_ENABLE (0xF4) nor ATKBD_CMD_RESET_BAT (0xFF) bring them back. Only re-enabling the keyboard interface at the controller level (i8042 command 0xAE, or rewriting the command byte as i8042_port_close() does) revives it. Running the init sequence without 0xF5 (0xED 0x00, 0xF3 0x00, 0xF4) keeps the keyboard working. 'i8042.dumbkbd=1' also works around this, but then the driver never writes to the keyboard and the LEDs cannot be controlled. Use the existing atkbd_deactivate_fixup quirk instead, as done for the sibling TM2424 by commit 3a046db33bb9 ("Input: atkbd - skip deactivate for Xiaomi Book Pro 14's internal keyboard"). Tested on v7.2: keyboard, Caps Lock LED and s2idle suspend/resume all work. DMI: XIAOMI REDMI Book Pro 16 2026/TM2425, BIOS RMAPT6B0P0909 05/22/2026 Fixes: 9cf6e24c9fbf ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID") Cc: stable@vger.kernel.org Signed-off-by: Alexei Turtanov <9alexei9@gmail.com> Link: https://patch.msgid.link/20260828112239.18081-1-9alexei9@gmail.com Signed-off-by: Dmitry Torokhov

Input: st-keyscan - improve probe error handling

2026-08-27T12:37:45+00:00

Use dev_err_probe() for devm_clk_get() to prevent log spam when probe returns -EPROBE_DEFER. Drop the redundant error message after devm_request_irq(), since the helper already reports request failures internally. Return the original error from platform_get_irq() instead of replacing it with -EINVAL. Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260727101125.28291-2-phucduc.bui@gmail.com Signed-off-by: Dmitry Torokhov

Input: snvs_pwrkey - tidy up error reporting in probe

2026-08-27T12:37:45+00:00

Do not print the error twice when acquiring clock fails and drop the redundant error message after devm_request_irq(), as the helper already reports request failures internally. Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260727101125.28291-1-phucduc.bui@gmail.com Signed-off-by: Dmitry Torokhov

Input: adp5588-keys - cache GPIO state before registering the gpiochip

2026-08-26T12:23:44+00:00

So as not to clobber any pre-programmed GPIO state in the execution of its gpiochip ops, the driver caches things during probe time. However, since those ops can be called both during and immediately after the call to devm_gpiochip_add_data(), it is imperative that things are cached before that. That's not the case right now, so reorder the two steps to prevent any clobbering. In the concrete example which motivated this change, a bootloader was preconfiguring an important GPIO output to HIGH before booting the kernel. Linux would then inadvertently set that output to LOW while configuring a GPIO hog on a discrete GPIO line within the same 8-bit bank (because the cached value was 0=LOW). Fixes: ba9f507a1bea ("Input: adp5588-keys - export unused GPIO pins") Signed-off-by: Alvin Šipraga Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20260818-adp5588-gpio-cache-v1-1-650a2674fc0d@analog.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov