linux-stable.git/drivers/input/touchscreen, branch v5.10.142

Input: atmel_mxt_ts - fix up inverted RESET handler

2022-08-21T13:15:32+00:00

[ Upstream commit feedaacdadfc332e1a6e436f3adfbc67e244db47 ]

This driver uses GPIO descriptors to drive the touchscreen RESET line. In
the existing device trees this has in conflict with intution been flagged
as GPIO_ACTIVE_HIGH and the driver then applies the reverse action by
driving the line low (setting to 0) to enter reset state and driving the
line high (setting to 1) to get out of reset state.

The correct way to handle active low GPIO lines is to provide the
GPIO_ACTIVE_LOW in the device tree (thus properly describing the hardware)
and letting the GPIO framework invert the assertion (driving high) to a
low level and vice versa.

This is considered a bug since the device trees are incorrectly
mis-specifying the line as active high.

Fix the driver and all device trees specifying a reset line.

Signed-off-by: Linus Walleij 
Reviewed-by: Philippe Schenker 
Acked-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20201104153032.1387747-1-linus.walleij@linaro.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin

Input: stmfts - do not leave device disabled in stmfts_input_open

2022-06-09T08:21:18+00:00

[ Upstream commit 5f76955ab1e43e5795a9631b22ca4f918a0ae986 ]

The commit 26623eea0da3 attempted to deal with potential leak of runtime
PM counter when opening the touchscreen device, however it ended up
erroneously dropping the counter in the case of successfully enabling the
device.

Let's address this by using pm_runtime_resume_and_get() and then executing
pm_runtime_put_sync() only when we fail to send "sense on" command to the
device.

Fixes: 26623eea0da3 ("Input: stmfts - fix reference leak in stmfts_input_open")
Reported-by: Pavel Machek 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin

Input: ili210x - fix reset timing

2022-05-25T07:18:01+00:00

commit e4920d42ce0e9c8aafb7f64b6d9d4ae02161e51e upstream.

According to Ilitek "231x & ILI251x Programming Guide" Version: 2.30
"2.1. Power Sequence", "T4 Chip Reset and discharge time" is minimum
10ms and "T2 Chip initial time" is maximum 150ms. Adjust the reset
timings such that T4 is 12ms and T2 is 160ms to fit those figures.

This prevents sporadic touch controller start up failures when some
systems with at least ILI251x controller boot, without this patch
the systems sometimes fail to communicate with the touch controller.

Fixes: 201f3c803544c ("Input: ili210x - add reset GPIO support")
Signed-off-by: Marek Vasut 
Link: https://lore.kernel.org/r/20220518204901.93534-1-marex@denx.de
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: stmfts - fix reference leak in stmfts_input_open

2022-05-25T07:17:52+00:00

[ Upstream commit 26623eea0da3476446909af96c980768df07bbd9 ]

pm_runtime_get_sync() will increment pm usage counter even it
failed. Forgetting to call pm_runtime_put_noidle will result
in reference leak in stmfts_input_open, so we should fix it.

Signed-off-by: Zheng Yongjun 
Link: https://lore.kernel.org/r/20220317131604.53538-1-zhengyongjun3@huawei.com
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin

Input: zinitix - do not report shadow fingers

2022-04-08T12:39:48+00:00

[ Upstream commit e941dc13fd3717122207d74539ab95da07ef797f ]

I observed the following problem with the BT404 touch pad
running the Phosh UI:

When e.g. typing on the virtual keyboard pressing "g" would
produce "ggg".

After some analysis it turns out the firmware reports that three
fingers hit that coordinate at the same time, finger 0, 2 and
4 (of the five available 0,1,2,3,4).

DOWN
  Zinitix-TS 3-0020: finger 0 down (246, 395)
  Zinitix-TS 3-0020: finger 1 up (0, 0)
  Zinitix-TS 3-0020: finger 2 down (246, 395)
  Zinitix-TS 3-0020: finger 3 up (0, 0)
  Zinitix-TS 3-0020: finger 4 down (246, 395)
UP
  Zinitix-TS 3-0020: finger 0 up (246, 395)
  Zinitix-TS 3-0020: finger 2 up (246, 395)
  Zinitix-TS 3-0020: finger 4 up (246, 395)

This is one touch and release: i.e. this is all reported on
touch (down) and release.

There is a field in the struct touch_event called finger_cnt
which is actually a bitmask of the fingers active in the
event.

Rename this field finger_mask as this matches the use contents
better, then use for_each_set_bit() to iterate over just the
fingers that are actally active.

Factor out a finger reporting function zinitix_report_fingers()
to handle all fingers.

Also be more careful in reporting finger down/up: we were
reporting every event with input_mt_report_slot_state(..., true);
but this should only be reported on finger down or move,
not on finger up, so also add code to check p->sub_status
to see what is happening and report correctly.

After this my Zinitix BT404 touchscreen report fingers
flawlessly.

The vendor drive I have notably does not use the "finger_cnt"
and contains obviously incorrect code like this:

  if (touch_dev->touch_info.finger_cnt > MAX_SUPPORTED_FINGER_NUM)
      touch_dev->touch_info.finger_cnt = MAX_SUPPORTED_FINGER_NUM;

As MAX_SUPPORTED_FINGER_NUM is an ordinal and the field is
a bitmask this seems quite confused.

Signed-off-by: Linus Walleij 
Link: https://lore.kernel.org/r/20220228233017.2270599-1-linus.walleij@linaro.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin

Input: zinitix - make sure the IRQ is allocated before it gets enabled

2022-01-11T14:25:02+00:00

commit cf73ed894ee939d6706d65e0cd186e4a64e3af6d upstream.

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 
Fixes: 26822652c85e ("Input: add zinitix touchscreen driver")
Signed-off-by: Nikita Travkin 
Link: https://lore.kernel.org/r/20220106072840.36851-2-nikita@trvn.ru
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: goodix - add id->model mapping for the "9111" model

2021-12-29T11:26:06+00:00

commit 81e818869be522bc8fa6f7df1b92d7e76537926c upstream.

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 
Link: https://lore.kernel.org/r/20211206164747.197309-2-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: elants_i2c - do not check Remark ID on eKTH3900/eKTH5312

2021-12-29T11:26:06+00:00

commit 4ebfee2bbc1a9c343dd50565ba5ae249fac32267 upstream.

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 
Link: https://lore.kernel.org/r/1639619603-20616-1-git-send-email-johnny.chuang.emc@gmail.com
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: atmel_mxt_ts - fix double free in mxt_read_info_block

2021-12-29T11:26:01+00:00

commit 12f247ab590a08856441efdbd351cf2cc8f60a2d upstream.

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 
Link: https://lore.kernel.org/r/20211212194257.68879-1-jose.exposito89@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: touchscreen - avoid bitwise vs logical OR warning

2021-12-22T08:30:58+00:00

commit a02dcde595f7cbd240ccd64de96034ad91cffc40 upstream.

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 
Reported-by: Nick Desaulniers 
Reviewed-by: Nick Desaulniers 
Link: https://lore.kernel.org/r/20211014205757.3474635-1-nathan@kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Anders Roxell 
Signed-off-by: Greg Kroah-Hartman