summaryrefslogtreecommitdiff
path: root/drivers/input
AgeCommit message (Collapse)Author
2022-03-01Input: elan_i2c - fix regulator enable count imbalance after suspend/resumeHans de Goede
Before these changes elan_suspend() would only disable the regulator when device_may_wakeup() returns false; whereas elan_resume() would unconditionally enable it, leading to an enable count imbalance when device_may_wakeup() returns true. This triggers the "WARN_ON(regulator->enable_count)" in regulator_put() when the elan_i2c driver gets unbound, this happens e.g. with the hot-plugable dock with Elan I2C touchpad for the Asus TF103C 2-in-1. Fix this by making the regulator_enable() call also be conditional on device_may_wakeup() returning false. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220131135436.29638-2-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-03-01Input: elan_i2c - move regulator_[en|dis]able() out of elan_[en|dis]able_power()Hans de Goede
elan_disable_power() is called conditionally on suspend, where as elan_enable_power() is always called on resume. This leads to an imbalance in the regulator's enable count. Move the regulator_[en|dis]able() calls out of elan_[en|dis]able_power() in preparation of fixing this. No functional changes intended. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220131135436.29638-1-hdegoede@redhat.com [dtor: consolidate elan_[en|dis]able() into elan_set_power()] Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-02-28Input: goodix - workaround Cherry Trail devices with a bogus ACPI ↵Hans de Goede
Interrupt() resource ACPI/x86 devices with a Cherry Trail SoC should have a GpioInt + a regular GPIO ACPI resource in their ACPI tables. Some CHT devices have a bug, where the also is bogus interrupt resource (likely copied from a previous Bay Trail based generation of the device). The i2c-core-acpi code will assign the bogus, non-working, interrupt resource to client->irq. Add a workaround to fix this up. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2043960 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220228111613.363336-1-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-02-28Input: goodix - use the new soc_intel_is_byt() helperHans de Goede
Use the new soc_intel_is_byt() helper from linux/platform_data/x86/soc.h. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220131143539.109142-5-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-02-28Merge tag 'v5.17-rc4' into for-linusDmitry Torokhov
Merge with mainline to get the Intel ASoC generic helpers header and other changes.
2022-02-27Input: samsung-keypad - properly state IOMEM dependencyDavid Gow
Make the samsung-keypad driver explicitly depend on CONFIG_HAS_IOMEM, as it calls devm_ioremap(). This prevents compile errors in some configs (e.g, allyesconfig/randconfig under UML): /usr/bin/ld: drivers/input/keyboard/samsung-keypad.o: in function `samsung_keypad_probe': samsung-keypad.c:(.text+0xc60): undefined reference to `devm_ioremap' Signed-off-by: David Gow <davidgow@google.com> Acked-by: anton ivanov <anton.ivanov@cambridgegreys.com> Link: https://lore.kernel.org/r/20220225041727.1902850-1-davidgow@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-02-18Input: psmouse - set up dependency between PS/2 and SMBus companionsDmitry Torokhov
When we switch from emulated PS/2 to native (RMI4 or Elan) protocols, we create SMBus companion devices that are attached to I2C/SMBus controllers. However, when suspending and resuming, we also need to make sure that we take into account the PS/2 device they are associated with, so that PS/2 device is suspended after the companion and resumed before it, otherwise companions will not work properly. Before I2C devices were marked for asynchronous suspend/resume, this ordering happened naturally, but now we need to enforce it by establishing device links, with PS/2 devices being suppliers and SMBus companions being consumers. Fixes: 172d931910e1 ("i2c: enable async suspend/resume on i2c client devices") Reported-and-tested-by: Hugh Dickins <hughd@google.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Link: https://lore.kernel.org/r/89456fcd-a113-4c82-4b10-a9bcaefac68f@google.com Link: https://lore.kernel.org/r/YgwQN8ynO88CPMju@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-02-15Input: zinitix - add new compatible stringsLinus Walleij
This driver works just fine with the BT404 version of the touchscreen as well. Tested on the Samsung GT-I8160 (Codina) mobile phone. Add all the new variants from the binding document so people can easily test them, we believe most of them work more or less. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220214234033.1052681-1-linus.walleij@linaro.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-02-08Input: clear BTN_RIGHT/MIDDLE on buttonpadsJosé Expósito
Buttonpads are expected to map the INPUT_PROP_BUTTONPAD property bit and the BTN_LEFT key bit. As explained in the specification, where a device has a button type value of 0 (click-pad) or 1 (pressure-pad) there should not be discrete buttons: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection#device-capabilities-feature-report However, some drivers map the BTN_RIGHT and/or BTN_MIDDLE key bits even though the device is a buttonpad and therefore does not have those buttons. This behavior has forced userspace applications like libinput to implement different workarounds and quirks to detect buttonpads and offer to the user the right set of features and configuration options. For more information: https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/726 In order to avoid this issue clear the BTN_RIGHT and BTN_MIDDLE key bits when the input device is register if the INPUT_PROP_BUTTONPAD property bit is set. Notice that this change will not affect udev because it does not check for buttons. See systemd/src/udev/udev-builtin-input_id.c. List of known affected hardware: - Chuwi AeroBook Plus - Chuwi Gemibook - Framework Laptop - GPD Win Max - Huawei MateBook 2020 - Prestigio Smartbook 141 C2 - Purism Librem 14v1 - StarLite Mk II - AMI firmware - StarLite Mk II - Coreboot firmware - StarLite Mk III - AMI firmware - StarLite Mk III - Coreboot firmware - StarLabTop Mk IV - AMI firmware - StarLabTop Mk IV - Coreboot firmware - StarBook Mk V Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20220208174806.17183-1-jose.exposito89@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-02-01Merge tag 'asoc-fix-v5.17-rc2' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.17 Quite a few fixes here, including an unusually large set in the core spurred on by various testing efforts as well as the usual small driver fixes. There are quite a few fixes for out of bounds writes in both the core and the various Qualcomm drivers, plus a couple of fixes for locking in the DPCM code.
2022-01-31Input: wm97xx: Simplify resource managementChristophe JAILLET
Since the commit in the Fixes tag below, 'wm->input_dev' is a managed resource that doesn't need to be explicitly unregistered or freed (see devm_input_allocate_device() documentation) So, remove some unless line of code to slightly simplify it. Fixes: c72f61e74073 ("Input: wm97xx: split out touchscreen registering") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/87dce7e80ea9b191843fa22415ca3aef5f3cc2e6.1643529968.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2022-01-17Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input updates from Dmitry Torokhov: "Updates to Goodix touchscreen driver (addition of pen support) and Silead touchscreen driver (also addition of pen support and parsing of embedded firmware to determine screen size), along with assorted fixes for other drivers" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: ti_am335x_tsc - fix a typo in a comment Input: zinitix - add compatible for bt532 Input: zinitix - handle proper supply names dt-bindings: input/ts/zinitix: Convert to YAML, fix and extend Input: axp20x-pek - revert "always register interrupt handlers" change Input: gpio-keys - avoid clearing twice some memory Input: byd - fix typo in a comment Input: ucb1400_ts - remove redundant variable penup Input: ti_am335x_tsc - lower the X and Y sampling time Input: ti_am335x_tsc - fix STEPCONFIG setup for Z2 Input: ti_am335x_tsc - set ADCREFM for X configuration Input: silead - add pen support Input: silead - add support for EFI-embedded fw using different min/max coordinates Input: goodix - 2 small fixes for pen support Input: goodix - improve gpiod_get() error logging Input: goodix - add pen support Input: ff-core - correct magnitude setting for rumble compatibility Input: palmas-pwrbutton - make a couple of arrays static const Input: wacom_i2c - clean up the query device fields Input: palmas-pwrbutton - use bitfield helpers
2022-01-15Merge branch 'next' into for-linusDmitry Torokhov
Prepare input updates for 5.17 merge window.
2022-01-12Merge tag 'tty-5.17-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial driver updates from Greg KH: "Here is the big set of tty/serial driver updates for 5.17-rc1. Nothing major in here, just lots of good updates and fixes, including: - more tty core cleanups from Jiri as well as mxser driver cleanups. This is the majority of the core diffstat - tty documentation updates from Jiri - platform_get_irq() updates - various serial driver updates for new features and hardware - fifo usage for 8250 console, reducing cpu load a lot - LED fix for keyboards, long-time bugfix that went through many revisions - minor cleanups All have been in linux-next for a while with no reported problems" * tag 'tty-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (119 commits) serial: core: Keep mctrl register state and cached copy in sync serial: stm32: correct loop for dma error handling serial: stm32: fix flow control transfer in DMA mode serial: stm32: rework TX DMA state condition serial: stm32: move tx dma terminate DMA to shutdown serial: pl011: Drop redundant DTR/RTS preservation on close/open serial: pl011: Drop CR register reset on set_termios serial: pl010: Drop CR register reset on set_termios serial: liteuart: fix MODULE_ALIAS serial: 8250_bcm7271: Fix return error code in case of dma_alloc_coherent() failure Revert "serdev: BREAK/FRAME/PARITY/OVERRUN notification prototype V2" tty: goldfish: Use platform_get_irq() to get the interrupt serdev: BREAK/FRAME/PARITY/OVERRUN notification prototype V2 tty: serial: meson: Drop the legacy compatible strings and clock code serial: pmac_zilog: Use platform_get_irq() to get the interrupt serial: bcm63xx: Use platform_get_irq() to get the interrupt serial: ar933x: Use platform_get_irq() to get the interrupt serial: vt8500: Use platform_get_irq() to get the interrupt serial: altera_jtaguart: Use platform_get_irq_optional() to get the interrupt serial: pxa: Use platform_get_irq() to get the interrupt ...
2022-01-10Input: ti_am335x_tsc - fix a typo in a commentQinghua Jin
change 'postion' to 'position' Signed-off-by: Qinghua Jin <qhjin.dev@gmail.com> Link: https://lore.kernel.org/r/20220106084215.355295-1-qhjin.dev@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-01-09Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fix from Dmitry Torokhov: "A small fixup to the Zinitix touchscreen driver to avoid enabling the IRQ line before we successfully requested it" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: zinitix - make sure the IRQ is allocated before it gets enabled
2022-01-08Input: zinitix - add compatible for bt532Nikita Travkin
Zinitix BT532 is another touch controller that seem to implement the same interface as an already supported BT541. Add it to the driver. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20220106072840.36851-5-nikita@trvn.ru Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-01-08Input: zinitix - handle proper supply namesLinus Walleij
The supply names of the Zinitix touchscreen were a bit confused, the new bindings rectifies this. To deal with old and new devicetrees, first check if we have "vddo" and in case that exists assume the old supply names. Else go and look for the new ones. We cannot just get the regulators since we would get an OK and a dummy regulator: we need to check explicitly for the old supply name. Use struct device *dev as a local variable instead of the I2C client since the device is what we are actually obtaining the resources from. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> [Slightly changed the legacy regulator detection] Signed-off-by: Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20220106072840.36851-4-nikita@trvn.ru Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-01-08Input: zinitix - make sure the IRQ is allocated before it gets enabledNikita Travkin
Since irq request is the last thing in the driver probe, it happens later than the input device registration. This means that there is a small time window where if the open method is called the driver will attempt to enable not yet available irq. Fix that by moving the irq request before the input device registration. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Fixes: 26822652c85e ("Input: add zinitix touchscreen driver") Signed-off-by: Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20220106072840.36851-2-nikita@trvn.ru Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-01-08Input: axp20x-pek - revert "always register interrupt handlers" changeHans de Goede
The power button on Cherry Trail systems with an AXP288 PMIC is connected to both the power button pin of the PMIC as well as to a power button GPIO on the Cherry Trail SoC itself. This leads to double power button event reporting which is a problem. Since reporting power button presses through the PMIC is not supported on all PMICs used on Cherry Trail systems, we want to keep the GPIO power button events, so the axp20x-pek code checks for the presence of a GPIO power button and in that case does not register its input-device. On most systems the GPIO power button also can wake-up the system from suspend, so the axp20x-pek driver would also not register its interrupt handler. But on some systems there was a bug causing wakeup by the GPIO power button handler to not work. Commit 9747070c11d6 ("Input: axp20x-pek - always register interrupt handlers") was added as a work around for this registering the axp20x-pek interrupts, but not the input-device on Cherry Trail systems. In the mean time the root-cause of the GPIO power button wakeup events not working has been found and fixed by the "pinctrl: cherryview: Do not allow the same interrupt line to be used by 2 pins" patch, so this is no longer necessary. This reverts the workaround going back to only registering the interrupt handlers on systems where we also register the input-device. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20220106111647.66520-1-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-01-03Input: gpio-keys - avoid clearing twice some memoryChristophe JAILLET
bitmap_parselist() already clears the 'bits' bitmap, so there is no need to clear it when it is allocated. This just wastes some cycles. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/d6ee621b9dd75b92f8831db365cee58dc2025322.1640813136.git.christophe.jaillet@wanadoo.fr Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-01-01Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: "Two small fixups for spaceball joystick driver and appletouch touchpad driver" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: spaceball - fix parsing of movement data packets Input: appletouch - initialize work before device registration
2021-12-30Input: spaceball - fix parsing of movement data packetsLeo L. Schwab
The spaceball.c module was not properly parsing the movement reports coming from the device. The code read axis data as signed 16-bit little-endian values starting at offset 2. In fact, axis data in Spaceball movement reports are signed 16-bit big-endian values starting at offset 3. This was determined first by visually inspecting the data packets, and later verified by consulting: http://spacemice.org/pdf/SpaceBall_2003-3003_Protocol.pdf If this ever worked properly, it was in the time before Git... Signed-off-by: Leo L. Schwab <ewhac@ewhac.org> Link: https://lore.kernel.org/r/20211221101630.1146385-1-ewhac@ewhac.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-30Input: appletouch - initialize work before device registrationPavel Skripkin
Syzbot has reported warning in __flush_work(). This warning is caused by work->func == NULL, which means missing work initialization. This may happen, since input_dev->close() calls cancel_work_sync(&dev->work), but dev->work initalization happens _after_ input_register_device() call. So this patch moves dev->work initialization before registering input device Fixes: 5a6eb676d3bc ("Input: appletouch - improve powersaving for Geyser3 devices") Reported-and-tested-by: syzbot+b88c5eae27386b252bbd@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Link: https://lore.kernel.org/r/20211230141151.17300-1-paskripkin@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-25Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: "A few small updates to drivers. Of note we are now deferring probes of i8042 on some Asus devices as the controller is not ready to respond to queries first time around when the driver is compiled into the kernel" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: elants_i2c - do not check Remark ID on eKTH3900/eKTH5312 Input: atmel_mxt_ts - fix double free in mxt_read_info_block Input: goodix - fix memory leak in goodix_firmware_upload Input: goodix - add id->model mapping for the "9111" model Input: goodix - try not to touch the reset-pin on x86/ACPI devices Input: i8042 - enable deferred probe quirk for ASUS UM325UA Input: elantech - fix stack out of bound access in elantech_change_report_id() Input: iqs626a - prohibit inlining of channel parsing functions Input: i8042 - add deferred probe support
2021-12-20Input: elants_i2c - do not check Remark ID on eKTH3900/eKTH5312Johnny Chuang
The eKTH3900/eKTH5312 series do not support the firmware update rules of Remark ID. Exclude these two series from checking it when updating the firmware in touch controllers. Signed-off-by: Johnny Chuang <johnny.chuang.emc@gmail.com> Link: https://lore.kernel.org/r/1639619603-20616-1-git-send-email-johnny.chuang.emc@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-20Input: byd - fix typo in a commentXiang wangx
The double `the' in a comment is repeated, thus it should be removed. Signed-off-by: Xiang wangx <wangxiang@cdjrlc.com> Link: https://lore.kernel.org/r/20211216082735.11948-1-wangxiang@cdjrlc.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-19Input: ucb1400_ts - remove redundant variable penupColin Ian King
Variable penup is assigned a value but penup is never read later, it is redundant and can be removed. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20211205000525.153999-1-colin.i.king@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-19Input: ti_am335x_tsc - lower the X and Y sampling timeDario Binacchi
The open delay time has to be applied only on the first sample of the X/Y coordinates because on the following samples the ADC channel is not changed. Removing this time from the samples after the first one, "ti,coordinate-readouts" greater than 1, decreases the total acquisition time, allowing to increase the number of acquired coordinates in the time unit. Signed-off-by: Dario Binacchi <dariobin@libero.it> Link: https://lore.kernel.org/r/20211212125358.14416-4-dariobin@libero.it Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-19Input: ti_am335x_tsc - fix STEPCONFIG setup for Z2Dario Binacchi
The Z2 step configuration doesn't erase the SEL_INP_SWC_3_0 bit-field before setting the ADC channel. This way its value could be corrupted by the ADC channel selected for the Z1 coordinate. Fixes: 8c896308feae ("input: ti_am335x_adc: use only FIFO0 and clean up a little") Signed-off-by: Dario Binacchi <dariobin@libero.it> Link: https://lore.kernel.org/r/20211212125358.14416-3-dariobin@libero.it Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-19Input: ti_am335x_tsc - set ADCREFM for X configurationDario Binacchi
As reported by the STEPCONFIG[1-16] registered field descriptions of the TI reference manual, for the ADC "in single ended, SEL_INM_SWC_3_0 must be 1xxx". Unlike the Y and Z coordinates, this bit has not been set for the step configuration registers used to sample the X coordinate. Fixes: 1b8be32e6914 ("Input: add support for TI Touchscreen controller") Signed-off-by: Dario Binacchi <dariobin@libero.it> Link: https://lore.kernel.org/r/20211212125358.14416-2-dariobin@libero.it Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-12Input: silead - add pen supportHans de Goede
Some Silead touchscreens have support for an active (battery powered) pen, add support for this. So far pen-support has only been seen on X86/ACPI (non devicetree) devs, IOW it is not used in actual devicetree files. The devicetree-bindings maintainers have requested properties like these to not be added to the devicetree-bindings, so the new properties are deliberately not added to the existing silead devicetree-bindings documentation. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211122220637.11386-3-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-12Input: silead - add support for EFI-embedded fw using different min/max ↵Hans de Goede
coordinates Unfortunately, at the time of writing this commit message, we have been unable to get permission from Silead, or from device OEMs, to distribute the necessary Silead firmware files in linux-firmware. On a whole bunch of devices the UEFI BIOS code contains a touchscreen driver, which contains an embedded copy of the firmware. The fw-loader code has a "platform" fallback mechanism, which together with info on the firmware from drivers/platform/x86/touchscreen_dmi.c will use the firmware from the UEFI driver when the firmware is missing from /lib/firmware. This makes the touchscreen work OOTB without users needing to manually download the firmware. The firmware bundled with the original Windows/Android is usually newer then the firmware in the UEFI driver and it is better calibrated. This better calibration can lead to significant differences in the reported min/max coordinates. Add support for a new (optional) "silead,efi-fw-min-max" property which provides a set of alternative min/max values to use for the x/y axis when the EFI embedded firmware is used. The new property is only used on (x86) devices which do not use devicetree, IOW it is not used in actual devicetree files. The devicetree-bindings maintainers have requested properties like these to not be added to the devicetree-bindings, so the new property is deliberately not added to the existing silead devicetree-bindings documentation. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211122220637.11386-2-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-12Input: goodix - 2 small fixes for pen supportHans de Goede
2 small fixes for pen support 1. Set the id.vendor field for the pen input_dev 2. Fix a typo in a comment Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211212124242.81019-5-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-12Input: goodix - improve gpiod_get() error loggingHans de Goede
goodix_get_gpio_config() errors are fatal (abort probe()) so log them at KERN_ERR level rather then as debug messages. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211212124242.81019-4-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-12Input: atmel_mxt_ts - fix double free in mxt_read_info_blockJosé Expósito
The "id_buf" buffer is stored in "data->raw_info_block" and freed by "mxt_free_object_table" in case of error. Return instead of jumping to avoid a double free. Addresses-Coverity-ID: 1474582 ("Double free") Fixes: 068bdb67ef74 ("Input: atmel_mxt_ts - fix the firmware update") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20211212194257.68879-1-jose.exposito89@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-09Input: goodix - fix memory leak in goodix_firmware_uploadJosé Expósito
Addresses-Coverity-ID: 1493934 ("Resource leak") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20211208173321.26659-1-jose.exposito89@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-09Input: goodix - add pen supportHans de Goede
Some Goodix touchscreens have support for a (Goodix) active pen, add support for this. The info on how to detect when a pen is down and to detect when the stylus buttons are pressed was lifted from the out of tree Goodix driver with pen support written by Adya: https://gitlab.com/AdyaAdya/goodix-touchscreen-linux-driver/ Since there is no way to tell if pen support is present, the registering of the pen input_dev is delayed till the first pen event is detected. This has been tested on a Trekstor Surftab duo W1, a Chuwi Hi13 and a Cyberbook T116 tablet. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=202161 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204513 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211207100754.31155-3-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-08Merge tag 'v5.15' into nextDmitry Torokhov
Sync up with the mainline to get the latest APIs and DT bindings.
2021-12-06Input: goodix - add id->model mapping for the "9111" modelHans de Goede
Add d->model mapping for the "9111" model, this fixes uses using a wrong config_len of 240 bytes while the "9111" model uses only 186 bytes of config. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211206164747.197309-2-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-06Input: ff-core - correct magnitude setting for rumble compatibilityCharles Keepax
When converting a rumble into a periodic effect, for compatibility, the magnitude is effectively calculated using: magnitude = max(strong_rubble / 3 + weak_rubble / 6, 0x7fff); The rumble magnitudes are both u16 and the resulting magnitude is s16. The max is presumably an attempt to limit the result of the calculation to the maximum possible magnitude for the s16 result, and thus should be a min. However in the case of strong = weak = 0xffff, the result of the first part of the calculation is 0x7fff, meaning that the min would be redundant anyway, so simply remove the current max. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20211130135039.13726-1-ckeepax@opensource.cirrus.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-06Input: palmas-pwrbutton - make a couple of arrays static constColin Ian King
Don't populate a couple of arrays on the stack but instead make them static const. Also makes the object code smaller by a few hundred bytes. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20211129231749.619469-1-colin.i.king@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-06Input: goodix - try not to touch the reset-pin on x86/ACPI devicesHans de Goede
Unless the controller is not responding at boot or after suspend/resume, the driver never resets the controller on x86/ACPI platforms. The driver still requesting the reset pin at probe() though in case it needs it. Until now the driver has always requested the reset pin with GPIOD_IN as type. The idea being to put the pin in high-impedance mode to save power until the driver actually wants to issue a reset. But this means that just requesting the pin can cause issues, since requesting it in another mode then GPIOD_ASIS may cause the pinctrl driver to touch the pin settings. We have already had issues before due to a bug in the pinctrl-cherryview.c driver which has been fixed in commit 921daeeca91b ("pinctrl: cherryview: Preserve CHV_PADCTRL1_INVRXTX_TXDATA flag on GPIOs"). And now it turns out that requesting the reset-pin as GPIOD_IN also stops the touchscreen from working on the GPD P2 max mini-laptop. The behavior of putting the pin in high-impedance mode relies on there being some external pull-up to keep it high and there seems to be no pull-up on the GPD P2 max, causing things to break. This commit fixes this by requesting the reset pin as is when using the x86/ACPI code paths to lookup the GPIOs; and by not dropping it back into input-mode in case the driver does end up issuing a reset for error-recovery. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209061 Fixes: a7d4b171660c ("Input: goodix - add support for getting IRQ + reset GPIOs on Cherry Trail devices") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211206091116.44466-2-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-06Input: i8042 - enable deferred probe quirk for ASUS UM325UASamuel Čavoj
The ASUS UM325UA suffers from the same issue as the ASUS UX425UA, which is a very similar laptop. The i8042 device is not usable immediately after boot and fails to initialize, requiring a deferred retry. Enable the deferred probe quirk for the UM325UA. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190256 Signed-off-by: Samuel Čavoj <samuel@cavoj.net> Link: https://lore.kernel.org/r/20211204015615.232948-1-samuel@cavoj.net Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-12-06Merge 5.16-rc4 into tty-nextGreg Kroah-Hartman
We need the tty/serial driver fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-29Input: wacom_i2c - clean up the query device fieldsAlistair Francis
Improve the query device fields to be more verbose. Signed-off-by: Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20211118123545.102872-1-alistair@alistair23.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-11-29Input: elantech - fix stack out of bound access in elantech_change_report_id()Andrea Righi
The array param[] in elantech_change_report_id() must be at least 3 bytes, because elantech_read_reg_params() is calling ps2_command() with PSMOUSE_CMD_GETINFO, that is going to access 3 bytes from param[], but it's defined in the stack as an array of 2 bytes, therefore we have a potential stack out-of-bounds access here, also confirmed by KASAN: [ 6.512374] BUG: KASAN: stack-out-of-bounds in __ps2_command+0x372/0x7e0 [ 6.512397] Read of size 1 at addr ffff8881024d77c2 by task kworker/2:1/118 [ 6.512416] CPU: 2 PID: 118 Comm: kworker/2:1 Not tainted 5.13.0-22-generic #22+arighi20211110 [ 6.512428] Hardware name: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08 ) 08/14/2020 [ 6.512436] Workqueue: events_long serio_handle_event [ 6.512453] Call Trace: [ 6.512462] show_stack+0x52/0x58 [ 6.512474] dump_stack+0xa1/0xd3 [ 6.512487] print_address_description.constprop.0+0x1d/0x140 [ 6.512502] ? __ps2_command+0x372/0x7e0 [ 6.512516] __kasan_report.cold+0x7d/0x112 [ 6.512527] ? _raw_write_lock_irq+0x20/0xd0 [ 6.512539] ? __ps2_command+0x372/0x7e0 [ 6.512552] kasan_report+0x3c/0x50 [ 6.512564] __asan_load1+0x6a/0x70 [ 6.512575] __ps2_command+0x372/0x7e0 [ 6.512589] ? ps2_drain+0x240/0x240 [ 6.512601] ? dev_printk_emit+0xa2/0xd3 [ 6.512612] ? dev_vprintk_emit+0xc5/0xc5 [ 6.512621] ? __kasan_check_write+0x14/0x20 [ 6.512634] ? mutex_lock+0x8f/0xe0 [ 6.512643] ? __mutex_lock_slowpath+0x20/0x20 [ 6.512655] ps2_command+0x52/0x90 [ 6.512670] elantech_ps2_command+0x4f/0xc0 [psmouse] [ 6.512734] elantech_change_report_id+0x1e6/0x256 [psmouse] [ 6.512799] ? elantech_report_trackpoint.constprop.0.cold+0xd/0xd [psmouse] [ 6.512863] ? ps2_command+0x7f/0x90 [ 6.512877] elantech_query_info.cold+0x6bd/0x9ed [psmouse] [ 6.512943] ? elantech_setup_ps2+0x460/0x460 [psmouse] [ 6.513005] ? psmouse_reset+0x69/0xb0 [psmouse] [ 6.513064] ? psmouse_attr_set_helper+0x2a0/0x2a0 [psmouse] [ 6.513122] ? phys_pmd_init+0x30e/0x521 [ 6.513137] elantech_init+0x8a/0x200 [psmouse] [ 6.513200] ? elantech_init_ps2+0xf0/0xf0 [psmouse] [ 6.513249] ? elantech_query_info+0x440/0x440 [psmouse] [ 6.513296] ? synaptics_send_cmd+0x60/0x60 [psmouse] [ 6.513342] ? elantech_query_info+0x440/0x440 [psmouse] [ 6.513388] ? psmouse_try_protocol+0x11e/0x170 [psmouse] [ 6.513432] psmouse_extensions+0x65d/0x6e0 [psmouse] [ 6.513476] ? psmouse_try_protocol+0x170/0x170 [psmouse] [ 6.513519] ? mutex_unlock+0x22/0x40 [ 6.513526] ? ps2_command+0x7f/0x90 [ 6.513536] ? psmouse_probe+0xa3/0xf0 [psmouse] [ 6.513580] psmouse_switch_protocol+0x27d/0x2e0 [psmouse] [ 6.513624] psmouse_connect+0x272/0x530 [psmouse] [ 6.513669] serio_driver_probe+0x55/0x70 [ 6.513679] really_probe+0x190/0x720 [ 6.513689] driver_probe_device+0x160/0x1f0 [ 6.513697] device_driver_attach+0x119/0x130 [ 6.513705] ? device_driver_attach+0x130/0x130 [ 6.513713] __driver_attach+0xe7/0x1a0 [ 6.513720] ? device_driver_attach+0x130/0x130 [ 6.513728] bus_for_each_dev+0xfb/0x150 [ 6.513738] ? subsys_dev_iter_exit+0x10/0x10 [ 6.513748] ? _raw_write_unlock_bh+0x30/0x30 [ 6.513757] driver_attach+0x2d/0x40 [ 6.513764] serio_handle_event+0x199/0x3d0 [ 6.513775] process_one_work+0x471/0x740 [ 6.513785] worker_thread+0x2d2/0x790 [ 6.513794] ? process_one_work+0x740/0x740 [ 6.513802] kthread+0x1b4/0x1e0 [ 6.513809] ? set_kthread_struct+0x80/0x80 [ 6.513816] ret_from_fork+0x22/0x30 [ 6.513832] The buggy address belongs to the page: [ 6.513838] page:00000000bc35e189 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1024d7 [ 6.513847] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) [ 6.513860] raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000 [ 6.513867] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 6.513872] page dumped because: kasan: bad access detected [ 6.513879] addr ffff8881024d77c2 is located in stack of task kworker/2:1/118 at offset 34 in frame: [ 6.513887] elantech_change_report_id+0x0/0x256 [psmouse] [ 6.513941] this frame has 1 object: [ 6.513947] [32, 34) 'param' [ 6.513956] Memory state around the buggy address: [ 6.513962] ffff8881024d7680: f2 f2 f2 f2 f2 00 00 f3 f3 00 00 00 00 00 00 00 [ 6.513969] ffff8881024d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6.513976] >ffff8881024d7780: 00 00 00 00 f1 f1 f1 f1 02 f3 f3 f3 00 00 00 00 [ 6.513982] ^ [ 6.513988] ffff8881024d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6.513995] ffff8881024d7880: 00 f1 f1 f1 f1 03 f2 03 f2 03 f3 f3 f3 00 00 00 [ 6.514000] ================================================================== Define param[] in elantech_change_report_id() as an array of 3 bytes to prevent the out-of-bounds access in the stack. Fixes: e4c9062717fe ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode") BugLink: https://bugs.launchpad.net/bugs/1945590 Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Reviewed-by: Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20211116095559.24395-1-andrea.righi@canonical.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-11-29Input: palmas-pwrbutton - use bitfield helpersGeert Uytterhoeven
Use the FIELD_PREP() helper, instead of open-coding the same operation. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/f8831b88346b36fc6e01e0910d0db6c94287d2b4.1637593297.git.geert+renesas@glider.be Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-11-28Input: iqs626a - prohibit inlining of channel parsing functionsJeff LaBundy
Some automated builds report a stack frame size in excess of 2 kB for iqs626_probe(); the culprit appears to be the call to iqs626_parse_prop(). To solve this problem, specify noinline_for_stack for all of the iqs626_parse_*() helper functions which are called inside a for loop within iqs626_parse_prop(). As a result, a build with '-Wframe-larger-than' as low as 512 is free of any such warnings. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jeff LaBundy <jeff@labundy.com> Link: https://lore.kernel.org/r/20211129004104.453930-1-jeff@labundy.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-11-28Input: i8042 - add deferred probe supportTakashi Iwai
We've got a bug report about the non-working keyboard on ASUS ZenBook UX425UA. It seems that the PS/2 device isn't ready immediately at boot but takes some seconds to get ready. Until now, the only workaround is to defer the probe, but it's available only when the driver is a module. However, many distros, including openSUSE as in the original report, build the PS/2 input drivers into kernel, hence it won't work easily. This patch adds the support for the deferred probe for i8042 stuff as a workaround of the problem above. When the deferred probe mode is enabled and the device couldn't be probed, it'll be repeated with the standard deferred probe mechanism. The deferred probe mode is enabled either via the new option i8042.probe_defer or via the quirk table entry. As of this patch, the quirk table contains only ASUS ZenBook UX425UA. The deferred probe part is based on Fabio's initial work. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190256 Signed-off-by: Takashi Iwai <tiwai@suse.de> Tested-by: Samuel Čavoj <samuel@cavoj.net> Link: https://lore.kernel.org/r/20211117063757.11380-1-tiwai@suse.de Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
generated by cgit v1.2.3-70-g09d2 (git 2.48.1) at 2025-02-08 23:31:07 +0000