- 09 Jan, 2022 1 commit
-
-
Nikita Travkin authored
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: 26822652 ("Input: add zinitix touchscreen driver") Signed-off-by:
Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20220106072840.36851-2-nikita@trvn.ruSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 31 Dec, 2021 2 commits
-
-
Leo L. Schwab authored
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:
-
Pavel Skripkin authored
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: 5a6eb676 ("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:
-
- 20 Dec, 2021 1 commit
-
-
Johnny Chuang authored
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.comSigned-off-by:
-
- 13 Dec, 2021 1 commit
-
-
José Expósito authored
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: 068bdb67 ("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:
-
- 10 Dec, 2021 1 commit
-
-
José Expósito authored
Addresses-Coverity-ID: 1493934 ("Resource leak") Signed-off-by:
-
- 07 Dec, 2021 3 commits
-
-
Hans de Goede authored
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.comSigned-off-by:
-
Hans de Goede authored
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 921daeec ("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: a7d4b171 ("Input: goodix - add support for getting IRQ + reset GPIOs on Cherry Trail devices") Cc: stable@vger.kernel.org Signed-off-by:
-
Samuel Čavoj authored
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=1190256Signed-off-by:
Samuel Čavoj <samuel@cavoj.net> Link: https://lore.kernel.org/r/20211204015615.232948-1-samuel@cavoj.netSigned-off-by:
-
- 29 Nov, 2021 3 commits
-
-
Andrea Righi authored
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: e4c90627 ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode") BugLink: https://bugs.launchpad.net/bugs/1945590Signed-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.comSigned-off-by:
-
Jeff LaBundy authored
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.comSigned-off-by:
-
Takashi Iwai authored
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=1190256Signed-off-by:
Takashi Iwai <tiwai@suse.de> Tested-by:
-
- 12 Nov, 2021 1 commit
-
-
Dmitry Torokhov authored
Prepare input updates for 5.16 merge window.
-
- 10 Nov, 2021 6 commits
-
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 48735862 ("Input: iforce - use DMA-safe buffer when getting IDs from USB") Signed-off-by:
Johan Hovold <johan@kernel.org> Cc: stable@vger.kernel.org # 5.3 Link: https://lore.kernel.org/r/20211025115501.5190-1-johan@kernel.orgSigned-off-by:
-
Alistair Francis authored
To make the code easier to read use macros for the bit masks. Signed-off-by:
Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20211009113707.17568-2-alistair@alistair23.meSigned-off-by:
-
Marek Vasut authored
Modern devices may redraw display at 60 Hz, make sure we have one input sample per one frame. Reduce sample period to 15ms, so we would get up to 66.6 samples per second, although realistically with all the jitter and extra scheduling wiggle room, we would end up just above 60 samples per second. This should be a good compromise between sampling too often and sampling too seldom. Signed-off-by:
Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20211108114145.84118-1-marex@denx.deSigned-off-by:
-
Marek Vasut authored
Currently the ili210x driver implements a threaded interrupt handler which starts upon edge on the interrupt line, and then polls the touch controller for samples. Every time a sample is obtained from the controller, the thread function checks whether further polling is required, and if so, waits fixed amount of time before polling for next sample. The delay between consecutive samples can thus vary greatly, because the I2C transfer required to retrieve the sample from the controller takes different amount of time on different platforms. Furthermore, different models of the touch controllers supported by this driver require different delays during retrieval of samples too. Instead of waiting fixed amount of time before polling for next sample, determine how much time passed since the beginning of sampling cycle and then wait only the remaining amount of time within the sampling cycle. This makes the driver deliver samples with equal spacing between them. Signed-off-by:
-
Marek Vasut authored
The ili251x touch controller needs 5ms delay between sending I2C device address and register address, and, writing or reading register data. According to downstream ili251x example code, this 5ms delay is not required when reading touch samples out of the controller. Implement such a special case. Signed-off-by:
-
Phoenix Huang authored
Some firmwares occasionally report bogus data from trackpoint, with X or Y displacement being too large (outside of [-127, 127] range). Let's drop such packets so that we do not generate jumps. Signed-off-by:
Phoenix Huang <phoenix@emc.com.tw> Tested-by:
Yufei Du <yufeidu@cs.unc.edu> Link: https://lore.kernel.org/r/20210729010940.5752-1-phoenix@emc.com.tw Cc: stable@vger.kernel.org Signed-off-by:
-
- 06 Nov, 2021 1 commit
-
-
Loic Poulain authored
The created rmi device is orphan, which breaks the real device hierarchy, and can cause some trouble, especially during suspend and resume sequences. E.g. in case of I2C, rmi dev should be child of the I2C client device. Fix this, assigning the transport device as parent of the rmi device. Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Link: https://lore.kernel.org/r/1635514971-18415-1-git-send-email-loic.poulain@linaro.orgSigned-off-by:
-
- 05 Nov, 2021 1 commit
-
-
Takashi Iwai authored
Fujitsu Lifebook T725 laptop requires, like a few other similar models, the nomux and notimeout options to probe the touchpad properly. This patch adds the corresponding quirk entries. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1191980Tested-by:
Neal Gompa <ngompa13@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 03 Nov, 2021 1 commit
-
-
Jesse Taube authored
According to the datasheet "The CAP1206 is pin- and register-compatible with the CAP1106, with the exception of the GAIN[1:0] bits and ALT_POL bit"(57). So, this patch aims to disable them as they are no longer used. Signed-off-by:
Jesse Taube <mr.bossman075@gmail.com> Signed-off-by:
-
- 02 Nov, 2021 1 commit
-
-
Jonathan Corbet authored
Commit 83b41248 ("Input: cy8ctmg110_ts - switch to using gpiod API") remove the last use of <linux/input/cy8ctmg110_pdata.h> but left the header file behind. Nothing uses it now, delete it. Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20211102220203.940290-6-corbet@lwn.netSigned-off-by:
-
- 17 Oct, 2021 7 commits
-
-
Marek Vasut authored
The ili251x firmware can be updated, this is used when switching between different modes of operation of the touch surface, e.g. glove operation. This patch implements the firmware update mechanism triggered by a write into an sysfs attribute. The firmware itself is distributed as an intel hex file with non-standard types. The first two lines are of type 0xad, which indicates the start of DataFlash payload, that is always at address 0xf000 on the ili251x, so it can be dropped, and 0xac which indicates the position of firmware info in the Application payload, that is always at address 0x2020 on the ili251x and we do not care. The rest of the firmware is data of type 0x00, and we care about that. To convert the firmware hex file into something usable by the kernel, remove the first two lines and then use ihex2fw: $ tail -n +3 input.hex > temp.hex $ ./tools/firmware/ihex2fw temp.hex firmware/ilitek/ili251x.bin To trigger the firmware update, place firmware file ilitek/ili251x.bin into /lib/firmware/, write into firmware_update sysfs attribute and wait about 30-40 seconds. The firmware update is slow. Afterward, verify the firmware_version and mode sysfs attributes to check whether the firmware got updated and the controller switched back to application (AP) mode by reading out 'mode' attribute in sysfs. Note that the content of firmware_version, e.g. 0600.0005.abcd.aa04 can be matched to the content of the firmware hex file. The first four bytes, 0x06 0x00 0x00 0x05 can be found at ^:102030 00 05000006, the next four bytes 0xab 0xcd 0xaa 0x04 at ^:10F000 00 nnnnnnnn ABCDAA04. Note that the protocol differs considerably between the ili2xxx devices, this patch therefore implements this functionality only for ili251x that I can test. Signed-off-by:
-
Marek Vasut authored
The ili251x firmware protocol permits readout of firmware version, protocol version, mcu version and current mode (application, boot loader, forced update). These information are useful when updating the firmware on the il251x, e.g. to avoid updating the same firmware into the device multiple times. The locking is now necessary to avoid races between interrupt handler and the sysfs readouts. Note that the protocol differs considerably between the ili2xxx devices, this patch therefore implements this functionality only for ili251x that I can test. Signed-off-by:
-
Marek Vasut authored
The ili251x firmware protocol permits readout of panel resolution, implement this, but make it possible to override this value using DT bindings. This way, older DTs which contain touchscreen-size-x and touchscreen-size-y properties will behave just like before and new DTs may avoid specifying these for ILI251x. Note that the command format is different on other controllers, so this functionality is isolated to ILI251x. Signed-off-by:
-
Shawn Guo authored
On some devices, e.g. Sony Xperia M4 Aqua, warm reset is used to reboot device into bootloader and recovery mode. Instead of always doing hard reset, add a check on reboot_mode for possible warm reset. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Tested-by:
Luca Weiss <luca@z3ntu.xyz> Link: https://lore.kernel.org/r/20210714095850.27185-3-shawn.guo@linaro.orgSigned-off-by:
-
Shawn Guo authored
Some drivers like Qualcomm pm8941-pwrkey need to access 'reboot_mode' for triggering reboot between cold and warm mode. Export the symbol, so that drivers built as module can still access the symbol. Signed-off-by:
-
Krzysztof Kozlowski authored
The MODULE_DEVICE_TABLE already creates proper alias for platform driver. Having another MODULE_ALIAS causes the alias to be duplicated. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210916170514.137977-1-krzysztof.kozlowski@canonical.comSigned-off-by:
-
Dmitry Torokhov authored
We are using devm_input_allocate_device() that already sets parent of the input device, there is no need to do that again. Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/YWpiZqrfC9+GQsM4@google.comSigned-off-by:
-
- 16 Oct, 2021 10 commits
-
-
Nathan Chancellor authored
A new warning in clang points out a few places in this driver where a bitwise OR is being used with boolean types: drivers/input/touchscreen.c:81:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This use of a bitwise OR is intentional, as bitwise operations do not short circuit, which allows all the calls to touchscreen_get_prop_u32() to happen so that the last parameter is initialized while coalescing the results of the calls to make a decision after they are all evaluated. To make this clearer to the compiler, use the '|=' operator to assign the result of each touchscreen_get_prop_u32() call to data_present, which keeps the meaning of the code the same but makes it obvious that every one of these calls is expected to happen. Signed-off-by:Nathan Chancellor <nathan@kernel.org> Reported-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
-
Michael Cullen authored
The Nacon GX100XF is already mapped, but it seems there is a Nacon GC-100 (identified as NC5136Wht PCGC-100WHITE though I believe other colours exist) with a different USB ID when in XInput mode. Signed-off-by:
Michael Cullen <michael@michaelcullen.name> Link: https://lore.kernel.org/r/20211015192051.5196-1-michael@michaelcullen.nameSigned-off-by:
-
Oleksij Rempel authored
For proper pressure calculation we need at least x and z1 to be non zero. Even worse, in case z1 we may run in to division by zero error. Fixes: 60b7db91 ("Input: resistive-adc-touch - rework mapping of channels") Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20211007095727.29579-1-o.rempel@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
On i.MX7S and i.MX8M* (but not i.MX6*) the pwrkey device has an associated clock. Accessing the registers requires that this clock is enabled. Binding the driver on at least i.MX7S and i.MX8MP while not having the clock enabled results in a complete hang of the machine. (This usually only happens if snvs_pwrkey is built as a module and the rtc-snvs driver isn't already bound because at bootup the required clk is on and only gets disabled when the clk framework disables unused clks late during boot.) This completes the fix in commit 135be16d ("ARM: dts: imx7s: add snvs clock to pwrkey"). Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20211013062848.2667192-1-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Randy Dunlap authored
Change the comment to a normal (non-kernel-doc) comment to avoid these kernel-doc warnings: max8925_onkey.c:2: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * MAX8925 ONKEY driver max8925_onkey.c:2: warning: missing initial short description on line: * MAX8925 ONKEY driver Fixes: 3734574c ("Input: enable onkey driver of max8925") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
-
Dmitry Torokhov authored
When request_irq() returns -EPORBE_DEFER we should abort probe and try again later instead of trying to engage IRQ trigger workaround. Link: https://lore.kernel.org/r/20210910045039.4020199-3-dmitry.torokhov@gmail.comSigned-off-by:
-
Dmitry Torokhov authored
Instead of manipulating capability bits directly use input_set_capability(). Also stop setting EV_ABS explicitly as input_set_abs_params() does it for us. Link: https://lore.kernel.org/r/20210910045039.4020199-2-dmitry.torokhov@gmail.comSigned-off-by:
-
Dmitry Torokhov authored
Set input device's bus type as BUS_SPI and use model as product ID. Link: https://lore.kernel.org/r/20210910045039.4020199-1-dmitry.torokhov@gmail.comSigned-off-by:
-
Stephan Gerhold authored
At the moment the touch keys have key codes assigned from the device tree. In some cases, users might want to change the key code from userspace. There is existing functionality for this in the input core using the EVIOCSKEYCODE ioctl, which is integrated for example into udev. Make it possible to use this functionality for tm2-touchkey by simply making the input core aware of the array that holds the keycodes. Similar code also exists in mcs_touchkey and mpr121_touchkey. Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20211013112305.41574-2-stephan@gerhold.netSigned-off-by:
-
Stephan Gerhold authored
Report the index of pressed touch key as MSC_SCAN code to userspace so it is possible to identify which of the keys was pressed (not just the function that is currently assigned to the key). This is done similarly also in mcs_touchkey and mpr121_touchkey. Signed-off-by:
-
