kernel/linux.git/drivers/input/keyboard, branch v4.4.235

Input: gpio-keys - fix check for disabling unsupported keys

2020-05-10T08:26:03+00:00

commit 8679ee4204cfd5cf78b996508ccadc1ec6130f1a upstream. Commit 4ea14a53d8f881034fa9e186653821c4e3d9a8fb ("Input: gpio-keys - report error when disabling unsupported key") tried let user know that they attempted to disable an unsupported key, unfortunately the check is wrong as it believes that all codes are invalid. Fix it by ensuring that keys that we try to disable are subset of keys (or switches) that device reports. Fixes: 4ea14a53d8f8 ("Input: gpio-keys - report error when disabling unsupported key") Reported-by: Ivaylo Dimitrov Tested-by: Ivaylo Dimitrov Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: nomadik-ske-keypad - fix a loop timeout test

2020-01-29T09:21:37+00:00

[ Upstream commit 4d8f727b83bcd6702c2d210330872c9122d2d360 ] The loop exits with "timeout" set to -1 not to 0. Fixes: 1158f0f16224 ("Input: add support for Nomadik SKE keypad controller") Signed-off-by: Dan Carpenter Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: imx_keypad - make sure keyboard can always wake up system

2019-07-21T07:07:07+00:00

[ Upstream commit ce9a53eb3dbca89e7ad86673d94ab886e9bea704 ] There are several scenarios that keyboard can NOT wake up system from suspend, e.g., if a keyboard is depressed between system device suspend phase and device noirq suspend phase, the keyboard ISR will be called and both keyboard depress and release interrupts will be disabled, then keyboard will no longer be able to wake up system. Another scenario would be, if a keyboard is kept depressed, and then system goes into suspend, the expected behavior would be when keyboard is released, system will be waked up, but current implementation can NOT achieve that, because both depress and release interrupts are disabled in ISR, and the event check is still in progress. To fix these issues, need to make sure keyboard's depress or release interrupt is enabled after noirq device suspend phase, this patch moves the suspend/resume callback to noirq suspend/resume phase, and enable the corresponding interrupt according to current keyboard status. Signed-off-by: Anson Huang Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: snvs_pwrkey - initialize necessary driver data before enabling IRQ

2019-05-16T17:45:03+00:00

commit bf2a7ca39fd3ab47ef71c621a7ee69d1813b1f97 upstream. SNVS IRQ is requested before necessary driver data initialized, if there is a pending IRQ during driver probe phase, kernel NULL pointer panic will occur in IRQ handler. To avoid such scenario, just initialize necessary driver data before enabling IRQ. This patch is inspired by NXP's internal kernel tree. Fixes: d3dc6e232215 ("input: keyboard: imx: add snvs power key driver") Signed-off-by: Anson Huang Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: st-keyscan - fix potential zalloc NULL dereference

2019-03-23T07:44:33+00:00

[ Upstream commit 2439d37e1bf8a34d437573c086572abe0f3f1b15 ] This patch fixes the following static checker warning: drivers/input/keyboard/st-keyscan.c:156 keyscan_probe() error: potential zalloc NULL dereference: 'keypad_data->input_dev' Reported-by: Dan Carpenter Signed-off-by: Gabriel Fernandez Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: matrix_keypad - use flush_delayed_work()

2019-03-23T07:44:33+00:00

[ Upstream commit a342083abe576db43594a32d458a61fa81f7cb32 ] We should be using flush_delayed_work() instead of flush_work() in matrix_keypad_stop() to ensure that we are not missing work that is scheduled but not yet put in the workqueue (i.e. its delay timer has not expired yet). Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: omap-keypad - fix idle configuration to not block SoC idle states

2019-01-13T09:05:32+00:00

[ Upstream commit e2ca26ec4f01486661b55b03597c13e2b9c18b73 ] With PM enabled, I noticed that pressing a key on the droid4 keyboard will block deeper idle states for the SoC. Let's fix this by using IRQF_ONESHOT and stop constantly toggling the device OMAP4_KBD_IRQENABLE register as suggested by Dmitry Torokhov . From the hardware point of view, looks like we need to manage the registers for OMAP4_KBD_IRQENABLE and OMAP4_KBD_WAKEUPENABLE together to avoid blocking deeper SoC idle states. And with toggling of OMAP4_KBD_IRQENABLE register now gone with IRQF_ONESHOT, also the SoC idle state problem is gone during runtime. We still also need to clear OMAP4_KBD_WAKEUPENABLE in omap4_keypad_close() though to pair it with omap4_keypad_open() to prevent blocking deeper SoC idle states after rmmod omap4-keypad. Reported-by: Pavel Machek Signed-off-by: Tony Lindgren Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: omap-keypad - fix keyboard debounce configuration

2018-12-21T13:09:53+00:00

[ Upstream commit 6c3516fed7b61a3527459ccfa67fab130d910610 ] I noticed that the Android v3.0.8 kernel on droid4 is using different keypad values from the mainline kernel and does not have issues with keys occasionally being stuck until pressed again. Turns out there was an earlier patch posted to fix this as "Input: omap-keypad: errata i689: Correct debounce time", but it was never reposted to fix use macros for timing calculations. This updated version is using macros, and also fixes the use of the input clock rate to use 32768KiHz instead of 32000KiHz. And we want to use the known good Android kernel values of 3 and 6 instead of 2 and 6 in the earlier patch. Reported-by: Pavel Machek Signed-off-by: Tony Lindgren Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: matrix_keypad - check for errors from of_get_named_gpio()

2018-12-13T08:21:31+00:00

commit d55bda1b3e7c5a87f10da54fdda866a9a9cef30b upstream. "of_get_named_gpio()" returns a negative error value if it fails and drivers should check for this. This missing check was now added to the matrix_keypad driver. In my case "of_get_named_gpio()" returned -EPROBE_DEFER because the referenced GPIOs belong to an I/O expander, which was not yet probed at the point in time when the matrix_keypad driver was loading. Because the driver did not check for errors from the "of_get_named_gpio()" routine, it was assuming that "-EPROBE_DEFER" is actually a GPIO number and continued as usual, which led to further errors like this later on: WARNING: CPU: 3 PID: 167 at drivers/gpio/gpiolib.c:114 gpio_to_desc+0xc8/0xd0 invalid GPIO -517 Note that the "GPIO number" -517 in the error message above is actually "-EPROBE_DEFER". As part of the patch a misleading error message "no platform data defined" was also removed. This does not lead to information loss because the other error paths in matrix_keypad_parse_dt() already print an error. Signed-off-by: Christian Hoff Suggested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: atakbd - fix Atari CapsLock behaviour

2018-10-20T07:52:37+00:00

[ Upstream commit 52d2c7bf7c90217fbe875d2d76f310979c48eb83 ] The CapsLock key on Atari keyboards is not a toggle, it does send the normal make and break scancodes. Drop the CapsLock toggle handling code, which did cause the CapsLock key to merely act as a Shift key. Tested-by: Michael Schmitz Signed-off-by: Michael Schmitz Signed-off-by: Andreas Schwab Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman