- 29 Nov, 2021 2 commits
-
-
Alistair Francis authored
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.meSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Geert Uytterhoeven authored
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.beSigned-off-by:
-
- 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:
-
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:
Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20211103070019.13374-1-tiwai@suse.deSigned-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 11 commits
-
-
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:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20211002045943.9406-1-rdunlap@infradead.orgSigned-off-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:
-
Dmitry Torokhov authored
This fixes the following warning from sparse: CC [M] drivers/input/misc/adxl34x.o CHECK drivers/input/misc/adxl34x.c drivers/input/misc/adxl34x.c:245:29: warning: cast to restricted __le16 drivers/input/misc/adxl34x.c:248:29: warning: cast to restricted __le16 drivers/input/misc/adxl34x.c:251:29: warning: cast to restricted __le16 Acked-by:
Michael Hennerich <michael.hennerich@analog.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/YWZIjb91d6aAwgss@google.comSigned-off-by:
-
Dmitry Torokhov authored
By using managed resources (devm) we are able to streamline error handling in probe and remove most of the custom remove method. Acked-by:
Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/YWZGKWgdarGtvtYA@google.comSigned-off-by:
-
Dmitry Torokhov authored
Instead of manually toggling interrupt as wakeup source in suspend/resume methods, let's declare keypad interrupt and wakeup interrupt and leave the rest to the PM core. Acked-by:
-
Dmitry Torokhov authored
Also drop parenthesis around macros that do not use expressions as they are not needed. Acked-by:
-
Dmitry Torokhov authored
Instead of guarding suspend/resume methods with #ifdef CONFIG_PM let's mark them as __maybe_unused as this allows better compile coverage. Acked-by:
-
- 13 Oct, 2021 2 commits
-
-
Uwe Kleine-König authored
Up to now tsc200x_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by:
-
Uwe Kleine-König authored
Up to now adxl34x_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by:
-
- 12 Oct, 2021 2 commits
-
-
John Keeping authored
The device may take up to 100ms to become responsive during probe, so prefer asynchronous probing to avoid delaying the rest of the system. Suggested-by:
John Keeping <john@metanate.com> Link: https://lore.kernel.org/r/20211007111217.1935858-1-john@metanate.comSigned-off-by:
-
John Keeping authored
I have a ST1633 touch controller which fails to probe due to a timeout waiting for the controller to become ready. Increasing the minimum delay to 100ms ensures that the probe sequence completes successfully. The ST1633 datasheet says nothing about the maximum delay here and the ST1232 I2C protocol document says "wait until" with no notion of a timeout. Since this only runs once during probe, being generous with the timout seems reasonable and most likely the device will become ready eventually. (It may be worth noting that I saw this issue with a PREEMPT_RT patched kernel which probably has tighter wakeups from usleep_range() than other preemption models.) Fixes: f605be6a ("Input: st1232 - wait until device is ready before reading resolution") Signed-off-by:
-
- 05 Oct, 2021 2 commits
-
-
Lukas Bulwahn authored
Commit 04647773 ("dt-bindings: input: Convert ChipOne ICN8318 binding to a schema") converts chipone_icn8318.txt to chipone,icn8318.yaml, but missed to adjust its reference in MAINTAINERS. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a broken reference. Repair this file reference in CHIPONE ICN8318 I2C TOUCHSCREEN DRIVER. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20211005075451.29691-12-lukas.bulwahn@gmail.comSigned-off-by:
-
Arnd Bergmann authored
Overlapping input and output arguments to snprintf() are undefined behavior in C99: drivers/input/joystick/analog.c: In function 'analog_name': drivers/input/joystick/analog.c:428:3: error: 'snprintf' argument 4 overlaps destination object 'analog' [-Werror=restrict] 428 | snprintf(analog->name, sizeof(analog->name), "%s %d-hat", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 429 | analog->name, hweight16(analog->mask & ANALOG_HATS_ALL)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/input/joystick/analog.c:420:40: note: destination object referenced by 'restrict'-qualified argument 1 was declared here 420 | static void analog_name(struct analog *analog) | ~~~~~~~~~~~~~~~^~~~~~ Change this function to use the simpler seq_buf interface instead. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20210927101416.1569609-1-arnd@kernel.orgSigned-off-by:
-
- 02 Oct, 2021 1 commit
-
-
Mark Brown authored
Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding a SPI device ID table. Fixes: 96c8395e ("spi: Revert modalias changes") Signed-off-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210927134104.38648-1-broonie@kernel.orgSigned-off-by:
-
- 23 Sep, 2021 3 commits
-
-
Cai Huoqing authored
The helper function devm_add_action_or_reset() will internally call devm_add_action(), and if devm_add_action() fails then it will execute the action mentioned and return the error code. So use devm_add_action_or_reset() instead of devm_add_action() to simplify the error handling, reduce the code. Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210922125954.533-1-caihuoqing@baidu.comSigned-off-by:
-
Cai Huoqing authored
The helper function devm_add_action_or_reset() will internally call devm_add_action(), and if devm_add_action() fails then it will execute the action mentioned and return the error code. So use devm_add_action_or_reset() instead of devm_add_action() to simplify the error handling, reduce the code. Signed-off-by:
-
Cai Huoqing authored
The helper function devm_add_action_or_reset() will internally call devm_add_action(), and if devm_add_action() fails then it will execute the action mentioned and return the error code. So use devm_add_action_or_reset() instead of devm_add_action() to simplify the error handling, reduce the code. Signed-off-by:
-
