<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/input, branch v5.15.27</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.15.27</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.15.27'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2022-03-08T18:12:53Z</updated>
<entry>
<title>Input: samsung-keypad - properly state IOMEM dependency</title>
<updated>2022-03-08T18:12:53Z</updated>
<author>
<name>David Gow</name>
<email>davidgow@google.com</email>
</author>
<published>2022-02-28T05:00:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=74e9545d9e25e0f5dbca0fac733b8132730cc2dc'/>
<id>urn:sha1:74e9545d9e25e0f5dbca0fac733b8132730cc2dc</id>
<content type='text'>
commit ba115adf61b36b8c167126425a62b0efc23f72c0 upstream.

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 &lt;davidgow@google.com&gt;
Acked-by: anton ivanov &lt;anton.ivanov@cambridgegreys.com&gt;
Link: https://lore.kernel.org/r/20220225041727.1902850-1-davidgow@google.com
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Input: elan_i2c - fix regulator enable count imbalance after suspend/resume</title>
<updated>2022-03-08T18:12:53Z</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2022-03-01T07:39:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cb19f03e5f6555e5c84217ed0e1c1eda9041f138'/>
<id>urn:sha1:cb19f03e5f6555e5c84217ed0e1c1eda9041f138</id>
<content type='text'>
commit 04b7762e37c95d9b965d16bb0e18dbd1fa2e2861 upstream.

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-&gt;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 &lt;hdegoede@redhat.com&gt;
Link: https://lore.kernel.org/r/20220131135436.29638-2-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Input: elan_i2c - move regulator_[en|dis]able() out of elan_[en|dis]able_power()</title>
<updated>2022-03-08T18:12:53Z</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2022-03-01T07:39:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f74fc94691f05e624e16acb7eb45c775a616f99f'/>
<id>urn:sha1:f74fc94691f05e624e16acb7eb45c775a616f99f</id>
<content type='text'>
commit 81a36d8ce554b82b0a08e2b95d0bd44fcbff339b upstream.

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 &lt;hdegoede@redhat.com&gt;
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 &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Input: ti_am335x_tsc - fix STEPCONFIG setup for Z2</title>
<updated>2022-03-08T18:12:35Z</updated>
<author>
<name>Dario Binacchi</name>
<email>dariobin@libero.it</email>
</author>
<published>2021-12-13T05:14:48Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7c93c809e00a4713f556e1e45af9b3d872504d1f'/>
<id>urn:sha1:7c93c809e00a4713f556e1e45af9b3d872504d1f</id>
<content type='text'>
[ Upstream commit 6bfeb6c21e1bdc11c328b7d996d20f0f73c6b9b0 ]

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 &lt;dariobin@libero.it&gt;
Link: https://lore.kernel.org/r/20211212125358.14416-3-dariobin@libero.it
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Input: ti_am335x_tsc - set ADCREFM for X configuration</title>
<updated>2022-03-08T18:12:35Z</updated>
<author>
<name>Dario Binacchi</name>
<email>dariobin@libero.it</email>
</author>
<published>2021-12-13T05:14:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=16ff93557d1e65ca02e40227dcfb121ca0320e6e'/>
<id>urn:sha1:16ff93557d1e65ca02e40227dcfb121ca0320e6e</id>
<content type='text'>
[ Upstream commit 73cca71a903202cddc8279fc76b2da4995da5bea ]

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 &lt;dariobin@libero.it&gt;
Link: https://lore.kernel.org/r/20211212125358.14416-2-dariobin@libero.it
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Input: clear BTN_RIGHT/MIDDLE on buttonpads</title>
<updated>2022-03-08T18:12:29Z</updated>
<author>
<name>José Expósito</name>
<email>jose.exposito89@gmail.com</email>
</author>
<published>2022-02-08T17:59:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6279c5263dedc6af67c194ec8e0f91bc2849cdf8'/>
<id>urn:sha1:6279c5263dedc6af67c194ec8e0f91bc2849cdf8</id>
<content type='text'>
[ Upstream commit 37ef4c19b4c659926ce65a7ac709ceaefb211c40 ]

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 &lt;peter.hutterer@who-t.net&gt;
Acked-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Acked-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: José Expósito &lt;jose.exposito89@gmail.com&gt;
Link: https://lore.kernel.org/r/20220208174806.17183-1-jose.exposito89@gmail.com
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Input: zinitix - make sure the IRQ is allocated before it gets enabled</title>
<updated>2022-01-11T14:35:19Z</updated>
<author>
<name>Nikita Travkin</name>
<email>nikita@trvn.ru</email>
</author>
<published>2022-01-09T07:19:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b228924bb6191ce20cf66c0859e5a41c53709ab9'/>
<id>urn:sha1:b228924bb6191ce20cf66c0859e5a41c53709ab9</id>
<content type='text'>
[ Upstream commit cf73ed894ee939d6706d65e0cd186e4a64e3af6d ]

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 &lt;linus.walleij@linaro.org&gt;
Fixes: 26822652c85e ("Input: add zinitix touchscreen driver")
Signed-off-by: Nikita Travkin &lt;nikita@trvn.ru&gt;
Link: https://lore.kernel.org/r/20220106072840.36851-2-nikita@trvn.ru
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Input: spaceball - fix parsing of movement data packets</title>
<updated>2022-01-05T11:42:39Z</updated>
<author>
<name>Leo L. Schwab</name>
<email>ewhac@ewhac.org</email>
</author>
<published>2021-12-31T05:05:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=466267ced87dd514fc0f64e477c3ef5bb881d4f3'/>
<id>urn:sha1:466267ced87dd514fc0f64e477c3ef5bb881d4f3</id>
<content type='text'>
commit bc7ec91718c49d938849697cfad98fcd9877cc26 upstream.

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 &lt;ewhac@ewhac.org&gt;
Link: https://lore.kernel.org/r/20211221101630.1146385-1-ewhac@ewhac.org
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Input: appletouch - initialize work before device registration</title>
<updated>2022-01-05T11:42:39Z</updated>
<author>
<name>Pavel Skripkin</name>
<email>paskripkin@gmail.com</email>
</author>
<published>2021-12-31T04:57:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e79ff8c68acb1eddf709d3ac84716868f2a91012'/>
<id>urn:sha1:e79ff8c68acb1eddf709d3ac84716868f2a91012</id>
<content type='text'>
commit 9f3ccdc3f6ef10084ceb3a47df0961bec6196fd0 upstream.

Syzbot has reported warning in __flush_work(). This warning is caused by
work-&gt;func == NULL, which means missing work initialization.

This may happen, since input_dev-&gt;close() calls
cancel_work_sync(&amp;dev-&gt;work), but dev-&gt;work initalization happens _after_
input_register_device() call.

So this patch moves dev-&gt;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 &lt;paskripkin@gmail.com&gt;
Link: https://lore.kernel.org/r/20211230141151.17300-1-paskripkin@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Input: i8042 - enable deferred probe quirk for ASUS UM325UA</title>
<updated>2022-01-05T11:42:32Z</updated>
<author>
<name>Samuel Čavoj</name>
<email>samuel@cavoj.net</email>
</author>
<published>2021-12-04T21:17:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e97d5549f842dafb7d212e4269574efddc596d1a'/>
<id>urn:sha1:e97d5549f842dafb7d212e4269574efddc596d1a</id>
<content type='text'>
[ Upstream commit 44ee250aeeabb28b52a10397ac17ffb8bfe94839 ]

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 &lt;samuel@cavoj.net&gt;
Link: https://lore.kernel.org/r/20211204015615.232948-1-samuel@cavoj.net
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
