- 26 Jun, 2023 1 commit
-
-
Dmitry Torokhov authored
Prepare input updates for 6.5 merge window.
-
- 06 Jun, 2023 5 commits
-
-
Caleb Connolly authored
Since PM8998/PM660, the power key debounce register was redefined to support shorter debounce times. On PM8941 the shortest debounce time (represented by register value 0) was 15625us, on PM8998 the shortest debounce time is 62us, with the default being 2ms. Adjust the bit shift to correctly program debounce on PM8998 and newer. Fixes: 68c581d5 ("Input: add Qualcomm PM8941 power key driver") Signed-off-by:
Caleb Connolly <caleb.connolly@linaro.org> Link: https://lore.kernel.org/r/20230529-pm8941-pwrkey-debounce-v1-2-c043a6d5c814@linaro.orgSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Caleb Connolly authored
The only drivers matching pm8???-* are two levels deep, adjust the glob to match them. Signed-off-by:
-
Dmitry Torokhov authored
Instead of constantly checking pointer(s) for non-NULL-ness provide default implementations of trigger() and read() and instantiate them during pore registration if driver-specific versions were not provided. Link: https://lore.kernel.org/r/ZGvoqP5PAAsJuky4@google.comSigned-off-by:
-
Uwe Kleine-König authored
regmap_set_bits() is equivalent to regmap_update_bits() if mask == val. The probe function uses regmap_clear_bits() to enable irqs, so symmetrically make use of regmap_set_bits() to disable them. There is no semantic difference. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/r/20230605161458.117361-2-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning). To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Before this driver might have returned an error. In this case emit a warning that tells more about the problem than the generic warning by the core, and instead of making the remove callback return zero unconditionally, convert to .remove_new() which is equivalent. Signed-off-by:
-
- 23 May, 2023 4 commits
-
-
Dana Elfassy authored
Currently input_grab_device() isn't covered by any tests Thus, adding a test to cover the cases: 1. The device is grabbed successfully 2. Trying to grab a device that is already grabbed by another input handle Signed-off-by:
Dana Elfassy <dangel101@gmail.com> Tested-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
-
Geert Uytterhoeven authored
Use the input_report_key() helper instead of open-coding the same operation. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/185f3320e39000159d4bd843fd3119b94c30d607.1684854795.git.geert+renesas@glider.beSigned-off-by:
-
Ismael Ferreras Morezuelas authored
While doing my research to improve the xpad device names I noticed that the 1532:0037 VID/PID seems to be used by the DeathAdder 2013, so that Razer Sabertooth instance looked wrong and very suspect to me. I didn't see any mention in the official drivers, either. After doing more research, it turns out that the xpad list is used by many other projects (like Steam) as-is [1], this issue was reported [2] and Valve/Sam Lantinga fixed it [3]: [1]: https://github.com/libsdl-org/SDL/blob/dcc5eef0e2395854b254ea2873a4899edab347c6/src/joystick/controller_type.h#L251 [2]: https://steamcommunity.com/app/353380/discussions/0/1743392486228754770/ [3]: https://hg.libsdl.org/SDL/rev/29809f6f0271 (With multiple Internet users reporting similar issues, not linked here) After not being able to find the correct VID/PID combination anywhere on the Internet and not receiving any reply from Razer support I did some additional detective work, it seems like it presents itself as "Razer Sabertooth Gaming Controller (XBOX360)", code 1689:FE00. Leaving us with this: * Razer Sabertooth (1689:fe00) * Razer Sabertooth Elite (24c6:5d04) * Razer DeathAdder 2013 (1532:0037) [note: not a gamepad] So, to sum things up; remove this conflicting/duplicate entry: { 0x1532, 0x0037, "Razer Sabertooth", 0, XTYPE_XBOX360 }, As the real/correct one is already present there, even if the Internet as a whole insists on presenting it as the Razer Sabertooth Elite, which (by all accounts) is not: { 0x1689, 0xfe00, "Razer Sabertooth", 0, XTYPE_XBOX360 }, Actual change in SDL2 referencing this kernel issue: https://github.com/libsdl-org/SDL/commit/e5e54169754ca5d3e86339d968b20126d9da0a15 For more information of the device, take a look here: https://github.com/xboxdrv/xboxdrv/pull/59 You can see a lsusb dump here: https://github.com/xboxdrv/xboxdrv/files/76581/Qa6dBcrv.txt Fixes: f554f619 ("Input: xpad - sync device IDs with xboxdrv") Signed-off-by:
Ismael Ferreras Morezuelas <swyterzone@gmail.com> Reviewed-by:
Cameron Gutman <aicommander@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/5c12dbdb-5774-fc68-5c58-ca596383663e@gmail.comSigned-off-by:
-
Ismael Ferreras Morezuelas authored
The Linux kernel is notorious for misspelling X-Box, X-box, XBox or XBOX; the official spelling is actually just Xbox. Plain and simple. Tried to respect the existing notes but still following the style guide. No functional changes intended. This only affects ancillary parts. Signed-off-by:
-
- 22 May, 2023 1 commit
-
-
Niklas Schnelle authored
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by:
Arnd Bergmann <arnd@kernel.org> Signed-off-by:
Niklas Schnelle <schnelle@linux.ibm.com> Link: https://lore.kernel.org/r/20230522105049.1467313-16-schnelle@linux.ibm.comSigned-off-by:
-
- 18 May, 2023 7 commits
-
-
Dmitry Torokhov authored
Upon receiving a PS/2 command the device and controller are supposed to stop sending normal data (scancodes or movement packets) and instead immediately start delivering ACK/NAK and command response. Unfortunately often EC has an output buffer which may contain latched data by the time the EC receives a command from the host. The kernel used to ignore such data, but that may cause "stuck" keys if the data dropped happens to be a break code or a part of a break code. This occasionally happens, for example, on Chromebooks when the kernel tries to toggle CapsLock LED on a keyboard while user releases Alt+Search keyboard shortcut. Fix this by passing the first non-ACK byte to the normal handler for a handful of PS/2 commands that are expected to be used during normal device operation (as opposed to probe/configuration time). Reviewed-by:
Raul E Rangel <rrangel@chromium.org> Link: https://lore.kernel.org/r/20230511185252.386941-8-dmitry.torokhov@gmail.comSigned-off-by:
-
Dmitry Torokhov authored
Instead of exposing inner workings of libps2 to drivers such as atkbd and psmouse, have them define pre-receive and receive callbacks, and provide a common handler that can be used with underlying serio port. While at this add kerneldoc to the module. Link: https://lore.kernel.org/r/ZGK81cxqjr/KS1kA@google.comSigned-off-by:
-
Dmitry Torokhov authored
When aborting PS/2 command the kernel should [re]set all flags before waking up waiters, otherwise waiting thread may read obsolete values of flags. Reported-by:
-
Dmitry Torokhov authored
Do not try to process "resend" or "reject" responses from the device as normal response data for a command. Reviewed-by:
-
Dmitry Torokhov authored
It is not entirely correct that libps2 sets PS2_FLAG_CMD1 after the device acknowledges each byte sent to the device by the host. Rework the code so that PS2_FLAG_CMD1 and PS2_FLAG_CMD are set only once, at the beginning of PS/2 command execution. Reviewed-by:
-
Dmitry Torokhov authored
When getting unexpected data while waiting for an acknowledgement it does not matter what command phase is currently executed, and ps2_handle_ack() should indicate that no further processing is needed for the received data byte. Remove PS2_FLAG_ACK_CMD and associated handling. Note that while it is possible to make ps2_handle_ack (and ps2_handle_repsonse) return void, it will be done when the code will be converted to common PS/2 interrupt handler later. Reviewed-by:
-
Dmitry Torokhov authored
In preparation of having unified interrupt handler for PS/2 devices, instead of attaching instances of psmouse and atkbd structures as serio's driver data, switch to attaching ps2dev instances. Reviewed-by:
-
- 17 May, 2023 1 commit
-
-
Uwe Kleine-König authored
After commit b8a1a4cd ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f4 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by:
-
- 11 May, 2023 4 commits
-
-
Dmitry Torokhov authored
The kernel only allocate 5 MT slots; check that transmitted slot ID falls within the acceptable range. Link: https://lore.kernel.org/r/ZFnEL91nrT789dbG@google.com Cc: stable@vger.kernel.org Signed-off-by:
-
Hans de Goede authored
Some devices have a wrong entry in their button array which points to a GPIO which is required in another driver, so soc_button_array must not claim it. A specific example of this is the Lenovo Yoga Book X90F / X90L, where the PNP0C40 home button entry points to a GPIO which is not a home button and which is required by the lenovo-yogabook driver. Add a DMI quirk table which can specify an ACPI GPIO resource index which should be skipped; and add an entry for the Lenovo Yoga Book X90F / X90L to this new DMI quirk table. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230414072116.4497-1-hdegoede@redhat.comSigned-off-by:
-
Krzysztof Kozlowski authored
Convert the Cypress All Points Addressable (APA) I2C Touchpad / Trackpad bindings to DT schema. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230511102559.175088-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Marek Vasut authored
Instead of hardcoding IRQ trigger type to IRQF_TRIGGER_HIGH, let's respect the settings specified in the firmware description. Fixes: e27c7292 ("Input: add driver for ADXL345/346 Digital Accelerometers") Signed-off-by:
Marek Vasut <marex@denx.de> Acked-by:
Michael Hennerich <michael.hennerich@analog.com> Link: https://lore.kernel.org/r/20230509203555.549158-1-marex@denx.deSigned-off-by:
-
- 08 May, 2023 3 commits
-
-
Luca Weiss authored
Some pwm vibrators have a dedicated enable GPIO that needs to be set high so that the vibrator works. Add support for that optionally. Signed-off-by:
Luca Weiss <luca@z3ntu.xyz> Reviewed-by:
Brian Masney <bmasney@redhat.com> Reviewed-by:
Sebastian Reichel <sre@kernel.org> Reviewed-by:
-
Luca Weiss authored
Make sure all printed messages end with a newline. Signed-off-by:
-
Luca Weiss authored
Some pwm vibrators have a dedicated enable GPIO that needs to be set high so that the vibrator works. Document that. Signed-off-by:
-
- 06 May, 2023 1 commit
-
-
Marek Vasut authored
Probe the touch controller driver even if resolution information is not available. This can happen e.g. in case the touch controller suffered a failed firmware update and is stuck in bootloader mode. Signed-off-by:
-
- 05 May, 2023 4 commits
-
-
Philipp Puschmann authored
The touch controller needs some time to wake-up after setting the wake-up gpio. Without having a delay after wake-up probing regularly fails in edt_ft5x06_ts_identify() with an error (i.e. EREMOTEIO) that was caused by a failed i2c transfer. The datasheet sets the wake-up time to 5 ms, although it is not entirely clear. Signed-off-by:
Philipp Puschmann <p.puschmann@pironex.com> Link: https://lore.kernel.org/r/20230505115823.545803-1-p.puschmann@pironex.comSigned-off-by:
-
Maximilian Weigand authored
The touchscreen can be put into a deep sleep state that prevents it from emitting touch irqs. Put the touchscreen into deep sleep during suspend if it is not marked as a wakeup source. This also fixes a problem with the touchscreen getting unresponsive after system resume when a falling edge trigger is used for the interrupt. When left on during suspend, the touchscreen would pull the interrupt line down in response to touch events, leaving the interrupt effectively disabled after resume. Signed-off-by:
Maximilian Weigand <mweigand@mweigand.net> Reviewed-by:
Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20230504120316.408687-2-mweigand2017@gmail.comSigned-off-by:
-
Dmitry Torokhov authored
Because the kernel increments device's open count in input_open_device() even if device is inhibited, the counter should always be decremented in input_close_device() to keep it balanced. Fixes: a1816164 ("Input: Add "inhibited" property") Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Link: https://lore.kernel.org/r/ZFFz0xAdPNSL3PT7@google.com Cc: stable@vger.kernel.org Signed-off-by:
-
Dmitry Torokhov authored
Properly initialize input_device_id structure in input_test_match_device_id test to make sure it contains no garbage causing the test to randomly fail. Fixes: fdefcbdd ("Input: Add KUnit tests for some of the input core helper functions") Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Tested-by:
-
- 02 May, 2023 9 commits
-
-
Dmitry Torokhov authored
input_abs_set_val() can nominally call input_alloc_absinfo() which may allocate memory with GFP_KERNEL flag. This does not happen when input_abs_set_val() is called by the input core to set current MT slot when handling a new input event, but it trips certain static analyzers. Rearrange the code to access the relevant structures directly. Reported-by:
Teng Qi <starmiku1207184332@gmail.com> Reviewed-by:
-
Geert Uytterhoeven authored
While KUnit tests that cannot be built as a loadable module must depend on "KUNIT=y", this is not true for modular tests, where it adds an unnecessary limitation. Fix this by relaxing the dependency to "KUNIT". Fixes: fdefcbdd ("Input: Add KUnit tests for some of the input core helper functions") Signed-off-by:
-
Geert Uytterhoeven authored
With CONFIG_DEBUG_SLAB=y: # Subtest: input_core 1..3 input: Test input device as /devices/virtual/input/input1 8<--- cut here --- Unable to handle kernel paging request at virtual address 6b6b6dd7 when read ... __lock_acquire from lock_acquire+0x26c/0x300 lock_acquire from _raw_spin_lock_irqsave+0x50/0x64 _raw_spin_lock_irqsave from devres_remove+0x20/0x7c devres_remove from devres_destroy+0x8/0x24 devres_destroy from input_free_device+0x2c/0x60 input_free_device from kunit_try_run_case+0x70/0x94 [kunit] Without CONFIG_DEBUG_SLAB=y: KTAP version 1 # Subtest: input_core 1..3 input: Test input device as /devices/virtual/input/input1 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 694 at lib/refcount.c:28 refcount_warn_saturate+0x54/0x100 refcount_t: underflow; use-after-free. ... Call Trace: [<0037cad4>] dump_stack+0xc/0x10 [<00377614>] __warn+0x7e/0xb4 [<0037768c>] warn_slowpath_fmt+0x42/0x62 [<001eee1c>] refcount_warn_saturate+0x54/0x100 [<000b1d34>] kfree_const+0x0/0x20 [<0036290a>] __kobject_del+0x0/0x6e [<001eee1c>] refcount_warn_saturate+0x54/0x100 [<00362a1a>] kobject_put+0xa2/0xb6 [<11965770>] kunit_generic_run_threadfn_adapter+0x0/0x1c [kunit] As per the comments for input_allocate_device() and input_register_device(), input_free_device() must be called only to free devices that have not been registered. input_unregister_device() already calls input_put_device(), thus leading to a use-after-free. Moreover, the kunit_suite.exit() method is called after every test case, even on failures. As the test itself already does cleanups in its failure paths, this may lead to a second use-after-free. Fix the first issue by dropping the call to input_allocate_device() from input_test_exit(). Fix the second issue by making the cleanup code conditional on a successful test. Fixes: fdefcbdd ("Input: Add KUnit tests for some of the input core helper functions") Signed-off-by: -
Biswarup Pal authored
Currently, uinput doesn't use the input_set_timestamp API, so any event injected using uinput is not accurately timestamped in terms of measuring when the actual event happened. Hence, call the input_set_timestamp API from uinput in order to provide a more accurate sense of time for the event. Propagate only the timestamps which are a) positive, b) within a pre-defined offset (10 secs) from the current time, and c) not in the future. Signed-off-by:
Biswarup Pal <biswarupp@google.com> Reviewed-by:
Siarhei Vishniakou <svv@google.com> Link: https://lore.kernel.org/r/20230427000152.1407471-1-biswarupp@google.comSigned-off-by:
-
André Apitzsch authored
Add support for touch keys found in some Atmel touch controller configurations. Reviewed-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
André Apitzsch <git@apitzsch.eu> Link: https://lore.kernel.org/r/20230407-atmel_keys-v2-2-92446a4343cb@apitzsch.euSigned-off-by:
-
André Apitzsch authored
In some configurations the touch controller can support the touch keys. Document the linux,keycodes property that enables those keys and specifies the keycodes that should be used to report the key events. Reviewed-by:
-
Michał Mirosław authored
<linux/i8042.h> include uses ENODEV when included with !IS_ENABLED(CONFIG_SERIO_I8042) and so need to include it. Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/49fd4d400d1ab62095e5ed75a6637f883c0d071b.1682795105.git.mirq-linux@rere.qmqm.plSigned-off-by:
-
Duoming Zhou authored
The watchdog_timer can schedule tx_timeout_task and watchdog_work can also arm watchdog_timer. The process is shown below: ----------- timer schedules work ------------ cyttsp4_watchdog_timer() //timer handler schedule_work(&cd->watchdog_work) ----------- work arms timer ------------ cyttsp4_watchdog_work() //workqueue callback function cyttsp4_start_wd_timer() mod_timer(&cd->watchdog_timer, ...) Although del_timer_sync() and cancel_work_sync() are called in cyttsp4_remove(), the timer and workqueue could still be rearmed. As a result, the possible use after free bugs could happen. The process is shown below: (cleanup routine) | (timer and workqueue routine) cyttsp4_remove() | cyttsp4_watchdog_timer() //timer cyttsp4_stop_wd_timer() | schedule_work() del_timer_sync() | | cyttsp4_watchdog_work() //worker | cyttsp4_start_wd_timer() | mod_timer() cancel_work_sync() | | cyttsp4_watchdog_timer() //timer | schedule_work() del_timer_sync() | kfree(cd) //FREE | | cyttsp4_watchdog_work() // reschedule! | cd-> //USE This patch changes del_timer_sync() to timer_shutdown_sync(), which could prevent rearming of the timer from the workqueue. Fixes: 17fb1563 ("Input: cyttsp4 - add core driver for Cypress TMA4XX touchscreen devices") Signed-off-by:Duoming Zhou <duoming@zju.edu.cn> Link: https://lore.kernel.org/r/20230421082919.8471-1-duoming@zju.edu.cnSigned-off-by:
-
Maximilian Weigand authored
The cmd array should be initialized with the proper command size and not with the actual command value that is sent to the touchscreen. Signed-off-by:
-
