Linux kernel stable tree https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.12.y 2021-07-14T15:00:14+00:00 2021-07-14T15:00:14+00:00 Zhen Lei thunder.leizhen@huawei.com 2021-05-24T18:52:42+00:00 urn:sha1:71611cc43b0068fae638bf1465ce07539259a638 [ Upstream commit d9b576917a1d0efa293801a264150a1b37691617 ] Return error code -EINVAL rather than '0' when the combo devices are not supported. Fixes: fa71c605c2bb ("Input: combine hil_kbd and hil_ptr drivers") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Link: https://lore.kernel.org/r/20210515030053.6824-1-thunder.leizhen@huawei.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 2021-07-14T14:59:33+00:00 Randy Dunlap rdunlap@infradead.org 2021-05-27T00:12:51+00:00 urn:sha1:0127719085fa0a3478877c353387baf5d6b61c3b [ Upstream commit c1367ee016e3550745315fb9a2dd1e4ce02cdcf6 ] Since the code for ATARI_KBD_CORE does not use drivers/input/keyboard/ code, just move ATARI_KBD_CORE to arch/m68k/Kconfig.machine to remove the dependency on INPUT_KEYBOARD. Removes this kconfig warning: WARNING: unmet direct dependencies detected for ATARI_KBD_CORE Depends on [n]: !UML && INPUT [=y] && INPUT_KEYBOARD [=n] Selected by [y]: - MOUSE_ATARI [=y] && !UML && INPUT [=y] && INPUT_MOUSE [=y] && ATARI [=y] Fixes: c04cb856e20a ("m68k: Atari keyboard and mouse support.") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Suggested-by: Michael Schmitz <schmitzmic@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20210527001251.8529-1-rdunlap@infradead.org Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 2021-04-15T17:23:44+00:00 Linus Torvalds torvalds@linux-foundation.org 2021-04-15T17:23:44+00:00 urn:sha1:1df01322f00a0aedd4a589597ce9c0b680ae6068 Pull input fixes from Dmitry Torokhov: "Just a few driver fixes here" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: elants_i2c - drop zero-checking of ABS_MT_TOUCH_MAJOR resolution Input: elants_i2c - fix division by zero if firmware reports zero phys size Input: nspire-keypad - enable interrupts only when opened Input: i8042 - fix Pegatron C15B ID entry Input: n64joy - fix return value check in n64joy_probe() Input: s6sy761 - fix coordinate read bit shift 2021-03-23T17:55:10+00:00 Fabian Vogt fabian@ritter-vogt.de 2021-03-23T17:45:55+00:00 urn:sha1:69d5ff3e9e51e23d5d81bf48480aa5671be67a71 The driver registers an interrupt handler in _probe, but didn't configure them until later when the _open function is called. In between, the keypad can fire an IRQ due to touchpad activity, which the handler ignores. This causes the kernel to disable the interrupt, blocking the keypad from working. Fix this by disabling interrupts before registering the handler. Additionally, disable them in _close, so that they're only enabled while open. Fixes: fc4f31461892 ("Input: add TI-Nspire keypad support") Signed-off-by: Fabian Vogt <fabian@ritter-vogt.de> Link: https://lore.kernel.org/r/3383725.iizBOSrK1V@linux-e202.suse.de Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2021-02-23T22:56:23+00:00 Linus Torvalds torvalds@linux-foundation.org 2021-02-23T22:56:23+00:00 urn:sha1:e0fbd25bb37e7bb1f5ad9c9f7e5fc89152aec87e Pull input updates from Dmitry Torokhov: "Mostly existing driver fixes plus a new driver for game controllers directly connected to Nintendo 64, and an enhancement for keyboards driven by Chrome OS EC to communicate layout of the top row to userspace" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (47 commits) Input: st1232 - fix NORMAL vs. IDLE state handling Input: aiptek - convert sysfs sprintf/snprintf family to sysfs_emit Input: alps - fix spelling of "positive" ARM: dts: cros-ec-keyboard: Use keymap macros dt-bindings: input: Fix the keymap for LOCK key dt-bindings: input: Create macros for cros-ec keymap Input: cros-ec-keyb - expose function row physical map to userspace dt-bindings: input: cros-ec-keyb: Add a new property describing top row Input: applespi - fix occasional crc errors under load. Input: applespi - don't wait for responses to commands indefinitely. Input: st1232 - add IDLE state as ready condition Input: zinitix - fix return type of zinitix_init_touch() Input: i8042 - add ASUS Zenbook Flip to noselftest list Input: add missing dependencies on CONFIG_HAS_IOMEM Input: joydev - prevent potential read overflow in ioctl Input: elo - fix an error code in elo_connect() Input: xpad - add support for PowerA Enhanced Wired Controller for Xbox Series X|S Input: sur40 - fix an error code in sur40_probe() Input: elants_i2c - detect enum overflow Input: zinitix - remove unneeded semicolon ... 2021-02-23T05:22:15+00:00 Philip Chen philipchen@chromium.org 2021-02-23T05:05:04+00:00 urn:sha1:820c8727956da82b7a841c299fabb2fdca9a37d4 The top-row keys in a keyboard usually have dual functionalities. E.g. A function key "F1" is also an action key "Browser back". Therefore, when an application receives an action key code from a top-row key press, the application needs to know how to correlate the action key code with the function key code and do the conversion whenever necessary. Since the userpace already knows the key scanlines (row/column) associated with a received key code. Essentially, the userspace only needs a mapping between the key row/column and the matching physical location in the top row. So, enhance the cros-ec-keyb driver to create such a mapping and expose it to userspace in the form of a function_row_physmap attribute. The attribute would be a space separated ordered list of row/column codes for the keys in the function row, in a left-to-right order. The attribute will only be present when the device has a custom design for the top-row keys. Signed-off-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210115122412.v7.2.I6542d7d9d0b246e7079bb16b41e697b2ac4b4e39@changeid Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2021-02-23T05:21:03+00:00 Dmitry Torokhov dmitry.torokhov@gmail.com 2021-02-23T05:21:03+00:00 urn:sha1:415e915fdfc775ad0c6675fde1008f6f43dd6251 Merge with mainline to get latest APIs and device tree bindings. 2021-02-19T19:13:29+00:00 Ronald Tschalär ronald@innovation.ch 2021-02-19T19:12:00+00:00 urn:sha1:e64123949e6c9581c97fc14594f1cf34bf1d87a8 For some reason, when the system is under heavy CPU load, the read following the write sometimes occurs unusually quickly, resulting in the read data not being quite ready and hence a bad packet getting read. Adding another delay after reading the status message appears to fix this. Signed-off-by: Ronald Tschalär <ronald@innovation.ch> Link: https://lore.kernel.org/r/20210217190718.11035-2-ronald@innovation.ch Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2021-02-19T19:13:27+00:00 Ronald Tschalär ronald@innovation.ch 2021-02-19T19:10:51+00:00 urn:sha1:0ce1ac23149c6da939a5926c098c270c58c317a0 The response to a command may never arrive or it may be corrupted (and hence dropped) for some reason. While exceedingly rare, when it did happen it blocked all further commands. One way to fix this was to do a suspend/resume. However, recovering automatically seems like a nicer option. Hence this puts a time limit (1 sec) on how long we're willing to wait for a response, after which we assume it got lost. Signed-off-by: Ronald Tschalär <ronald@innovation.ch> Link: https://lore.kernel.org/r/20210217190718.11035-1-ronald@innovation.ch Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2021-02-19T19:02:18+00:00 Dmitry Torokhov dmitry.torokhov@gmail.com 2021-02-19T18:39:16+00:00 urn:sha1:b2e3543b5e193c2be802ae2db0a8ae82ec8c0f66 devm_ioremap_resource() is only guaranteed to be present if CONFIG_HAS_IOMEM is set. Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/YCyauGyqxut69JNz@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>