Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v5.18.2 2022-05-21T23:58:43+00:00 2022-05-21T23:58:43+00:00 Linus Torvalds torvalds@linux-foundation.org 2022-05-21T23:58:43+00:00 urn:sha1:4c493b1a41274c3f9b754036cd8431903306cdf3 Pull input fixes from Dmitry Torokhov: "A small fixup to ili210x touchscreen driver, and updated maintainer entry for the device tree binding of Mediatek 6779 keypad: - fix reset timing of Ilitek touchscreens - update maintainer entry of DT binding of Mediatek 6779 keypad" * tag 'input-for-v5.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: ili210x - use one common reset implementation Input: ili210x - fix reset timing dt-bindings: input: mediatek,mt6779-keypad: update maintainer 2022-05-18T21:31:31+00:00 Marek Vasut marex@denx.de 2022-05-18T21:30:09+00:00 urn:sha1:b26ff9137183309c18cdfe931e1cafcf3c1a980d Rename ili251x_hardware_reset() to ili210x_hardware_reset(), change its parameter from struct device * to struct gpio_desc *, and use it as one single consistent reset implementation all over the driver. Also increase the minimum reset duration to 12ms, to make sure the reset is really within the spec. Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20220518210423.106555-1-marex@denx.de Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2022-05-18T21:31:30+00:00 Marek Vasut marex@denx.de 2022-05-18T21:28:32+00:00 urn:sha1:e4920d42ce0e9c8aafb7f64b6d9d4ae02161e51e According to Ilitek "231x & ILI251x Programming Guide" Version: 2.30 "2.1. Power Sequence", "T4 Chip Reset and discharge time" is minimum 10ms and "T2 Chip initial time" is maximum 150ms. Adjust the reset timings such that T4 is 12ms and T2 is 160ms to fit those figures. This prevents sporadic touch controller start up failures when some systems with at least ILI251x controller boot, without this patch the systems sometimes fail to communicate with the touch controller. Fixes: 201f3c803544c ("Input: ili210x - add reset GPIO support") Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20220518204901.93534-1-marex@denx.de Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2022-04-23T16:52:07+00:00 Linus Torvalds torvalds@linux-foundation.org 2022-04-23T16:52:07+00:00 urn:sha1:0fe86b27cbad8003e90aa78ebd19c3d8a3eb89a5 Pull input fixes from Dmitry Torokhov: - a new set of keycodes to be used by marine navigation systems - minor fixes to omap4-keypad and cypress-sf drivers * tag 'input-for-v5.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: add Marine Navigation Keycodes Input: omap4-keypad - fix pm_runtime_get_sync() error checking Input: cypress-sf - register a callback to disable the regulators 2022-04-17T20:13:34+00:00 Miaoqian Lin linmq006@gmail.com 2022-04-17T20:03:31+00:00 urn:sha1:81022a170462d38ea10612cb67e8e2c529d58abe If the device is already in a runtime PM enabled state pm_runtime_get_sync() will return 1, so a test for negative value should be used to check for errors. Fixes: f77621cc640a ("Input: omap-keypad - dynamically handle register offsets") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20220412070131.19848-1-linmq006@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2022-04-09T02:34:46+00:00 Zheyu Ma zheyuma97@gmail.com 2022-04-09T02:30:49+00:00 urn:sha1:fd0a4b39870d49ff15f6966470185409e261f20f When the driver fails to probe, we will get the following splat: [ 19.311970] ------------[ cut here ]------------ [ 19.312566] WARNING: CPU: 3 PID: 375 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0 [ 19.317591] RIP: 0010:_regulator_put+0x3ec/0x4e0 [ 19.328831] Call Trace: [ 19.329112] <TASK> [ 19.329369] regulator_bulk_free+0x82/0xe0 [ 19.329860] devres_release_group+0x319/0x3d0 [ 19.330357] i2c_device_probe+0x766/0x940 Fix this by adding a callback that will deal with the disabling when the driver fails to probe. Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Link: https://lore.kernel.org/r/20220409022629.3493557-1-zheyuma97@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2022-04-01T17:14:32+00:00 Linus Torvalds torvalds@linux-foundation.org 2022-04-01T17:14:32+00:00 urn:sha1:aa240ee7883487201d0c6cc537ec1c4cd6cb2a9e Pull input updates from Dmitry Torokhov: - a revert of a patch resetting extra buttons on touchpads claiming to be buttonpads as this caused regression on certain Dell devices - a new driver for Mediatek MT6779 keypad - a new driver for Imagis touchscreen - rework of Google/Chrome OS "Vivaldi" keyboard handling - assorted driver fixes. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (31 commits) Revert "Input: clear BTN_RIGHT/MIDDLE on buttonpads" Input: adi - remove redundant variable z Input: add Imagis touchscreen driver dt-bindings: input/touchscreen: bindings for Imagis Input: synaptics - enable InterTouch on ThinkPad T14/P14s Gen 1 AMD Input: stmfts - fix reference leak in stmfts_input_open Input: add bounds checking to input_set_capability() Input: iqs5xx - use local input_dev pointer HID: google: modify HID device groups of eel HID: google: Add support for vivaldi to hid-hammer HID: google: extract Vivaldi hid feature mapping for use in hid-hammer Input: extract ChromeOS vivaldi physmap show function HID: google: switch to devm when registering keyboard backlight LED Input: mt6779-keypad - fix signedness bug Input: mt6779-keypad - add MediaTek keypad driver dt-bindings: input: Add bindings for Mediatek matrix keypad Input: da9063 - use devm_delayed_work_autocancel() Input: goodix - fix race on driver unbind Input: goodix - use input_copy_abs() helper Input: add input_copy_abs() function ... 2022-04-01T04:17:52+00:00 José Expósito jose.exposito89@gmail.com 2022-04-01T04:15:36+00:00 urn:sha1:8b188fba75195745026e11d408e4a7e94e01d701 This reverts commit 37ef4c19b4c659926ce65a7ac709ceaefb211c40. The touchpad present in the Dell Precision 7550 and 7750 laptops reports a HID_DG_BUTTONTYPE of type MT_BUTTONTYPE_CLICKPAD. However, the device is not a clickpad, it is a touchpad with physical buttons. In order to fix this issue, a quirk for the device was introduced in libinput [1] [2] to disable the INPUT_PROP_BUTTONPAD property: [Precision 7x50 Touchpad] MatchBus=i2c MatchUdevType=touchpad MatchDMIModalias=dmi:*svnDellInc.:pnPrecision7?50* AttrInputPropDisable=INPUT_PROP_BUTTONPAD However, because of the change introduced in 37ef4c19b4 ("Input: clear BTN_RIGHT/MIDDLE on buttonpads") the BTN_RIGHT key bit is not mapped anymore breaking the device right click button and making impossible to workaround it in user space. In order to avoid breakage on other present or future devices, revert the patch causing the issue. Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220321184404.20025-1-jose.exposito89@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2022-03-31T04:14:18+00:00 Dmitry Torokhov dmitry.torokhov@gmail.com 2022-03-31T04:14:18+00:00 urn:sha1:5710faba8a2a15349c9001bd4b2cd958e56c90fa Prepare input updates for 5.18 merge window. 2022-03-28T21:32:39+00:00 Linus Torvalds torvalds@linux-foundation.org 2022-03-28T21:32:39+00:00 urn:sha1:a701f370b521b2ed0654a9da7cf424b3ff8fa73d Pull xen updates from Juergen Gross: - A bunch of minor cleanups - A fix for kexec in Xen dom0 when executed on a high cpu number - A fix for resuming after suspend of a Xen guest with assigned PCI devices - A fix for a crash due to not disabled preemption when resuming as Xen dom0 * tag 'for-linus-5.18-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen: fix is_xen_pmu() xen: don't hang when resuming PCI device arch:x86:xen: Remove unnecessary assignment in xen_apic_read() xen/grant-table: remove readonly parameter from functions xen/grant-table: remove gnttab_*transfer*() functions drivers/xen: use helper macro __ATTR_RW x86/xen: Fix kerneldoc warning xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32 xen: use time_is_before_eq_jiffies() instead of open coding it