<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/input, branch v5.4.201</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.201</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.201'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-06-14T16:12:03+00:00</updated>
<entry>
<title>Input: bcm5974 - set missing URB_NO_TRANSFER_DMA_MAP urb flag</title>
<updated>2022-06-14T16:12:03+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2022-06-07T19:11:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3c953d47eb1e6ecfa69fbffc1e5f6321a1e2075a'/>
<id>urn:sha1:3c953d47eb1e6ecfa69fbffc1e5f6321a1e2075a</id>
<content type='text'>
commit c42e65664390be7c1ef3838cd84956d3a2739d60 upstream.

The bcm5974 driver does the allocation and dma mapping of the usb urb
data buffer, but driver does not set the URB_NO_TRANSFER_DMA_MAP flag
to let usb core know the buffer is already mapped.

usb core tries to map the already mapped buffer, causing a warning:
"xhci_hcd 0000:00:14.0: rejecting DMA map of vmalloc memory"

Fix this by setting the URB_NO_TRANSFER_DMA_MAP, letting usb core
know buffer is already mapped by bcm5974 driver

Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215890
Link: https://lore.kernel.org/r/20220606113636.588955-1-mathias.nyman@linux.intel.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: stmfts - do not leave device disabled in stmfts_input_open</title>
<updated>2022-06-14T16:11:42+00:00</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2022-05-25T16:51:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c8735252f93fdb7a68b9cd5332dbc52ebd2fd25b'/>
<id>urn:sha1:c8735252f93fdb7a68b9cd5332dbc52ebd2fd25b</id>
<content type='text'>
[ 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 &lt;pavel@denx.de&gt;
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: sparcspkr - fix refcount leak in bbc_beep_probe</title>
<updated>2022-06-14T16:11:42+00:00</updated>
<author>
<name>Miaoqian Lin</name>
<email>linmq006@gmail.com</email>
</author>
<published>2022-05-16T21:55:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bbc2b0ce6042dd3117827f10ea8cb67e0ab786da'/>
<id>urn:sha1:bbc2b0ce6042dd3117827f10ea8cb67e0ab786da</id>
<content type='text'>
[ Upstream commit c8994b30d71d64d5dcc9bc0edbfdf367171aa96f ]

of_find_node_by_path() calls of_find_node_opts_by_path(),
which returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.

Fixes: 9c1a5077fdca ("input: Rewrite sparcspkr device probing.")
Signed-off-by: Miaoqian Lin &lt;linmq006@gmail.com&gt;
Link: https://lore.kernel.org/r/20220516081018.42728-1-linmq006@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: goodix - fix spurious key release events</title>
<updated>2022-06-06T06:33:48+00:00</updated>
<author>
<name>Dmitry Mastykin</name>
<email>dmastykin@astralinux.ru</email>
</author>
<published>2020-03-24T18:38:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9ce35dad5a1ac262559c0d296de049dcb5b05799'/>
<id>urn:sha1:9ce35dad5a1ac262559c0d296de049dcb5b05799</id>
<content type='text'>
commit 24ef83f6e31d20fc121a7cd732b04b498475fca3 upstream.

The goodix panel sends spurious interrupts after a 'finger up' event,
which always cause a timeout.
We were exiting the interrupt handler by reporting touch_num == 0, but
this was still processed as valid and caused the code to use the
uninitialised point_data, creating spurious key release events.

Report an error from the interrupt handler so as to avoid processing
invalid point_data further.

Signed-off-by: Dmitry Mastykin &lt;dmastykin@astralinux.ru&gt;
Reviewed-by: Bastien Nocera &lt;hadess@hadess.net&gt;
Link: https://lore.kernel.org/r/20200316075302.3759-2-dmastykin@astralinux.ru
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Cc: Fabio Estevam &lt;festevam@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Input: ili210x - fix reset timing</title>
<updated>2022-05-25T07:14:38+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2022-05-18T21:28:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=36ac6caf742d9597a1ce3f2eeeb5de895fa75fd2'/>
<id>urn:sha1:36ac6caf742d9597a1ce3f2eeeb5de895fa75fd2</id>
<content type='text'>
commit e4920d42ce0e9c8aafb7f64b6d9d4ae02161e51e upstream.

According to Ilitek "231x &amp; 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 &lt;marex@denx.de&gt;
Link: https://lore.kernel.org/r/20220518204901.93534-1-marex@denx.de
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: stmfts - fix reference leak in stmfts_input_open</title>
<updated>2022-05-25T07:14:32+00:00</updated>
<author>
<name>Zheng Yongjun</name>
<email>zhengyongjun3@huawei.com</email>
</author>
<published>2022-03-21T04:56:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8c015cd524424e79b31270bd3dbdac9612c6f7db'/>
<id>urn:sha1:8c015cd524424e79b31270bd3dbdac9612c6f7db</id>
<content type='text'>
[ 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 &lt;zhengyongjun3@huawei.com&gt;
Link: https://lore.kernel.org/r/20220317131604.53538-1-zhengyongjun3@huawei.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: add bounds checking to input_set_capability()</title>
<updated>2022-05-25T07:14:32+00:00</updated>
<author>
<name>Jeff LaBundy</name>
<email>jeff@labundy.com</email>
</author>
<published>2022-03-21T04:55:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bb83a744bc671804016e23861a892e9db2aee73f'/>
<id>urn:sha1:bb83a744bc671804016e23861a892e9db2aee73f</id>
<content type='text'>
[ Upstream commit 409353cbe9fe48f6bc196114c442b1cff05a39bc ]

Update input_set_capability() to prevent kernel panic in case the
event code exceeds the bitmap for the given event type.

Suggested-by: Tomasz Moń &lt;tomasz.mon@camlingroup.com&gt;
Signed-off-by: Jeff LaBundy &lt;jeff@labundy.com&gt;
Reviewed-by: Tomasz Moń &lt;tomasz.mon@camlingroup.com&gt;
Link: https://lore.kernel.org/r/20220320032537.545250-1-jeff@labundy.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>Revert "Input: clear BTN_RIGHT/MIDDLE on buttonpads"</title>
<updated>2022-04-15T12:18:00+00:00</updated>
<author>
<name>José Expósito</name>
<email>jose.exposito89@gmail.com</email>
</author>
<published>2022-04-01T04:15:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=848977412065d310780af4dfe07360c41b373f06'/>
<id>urn:sha1:848977412065d310780af4dfe07360c41b373f06</id>
<content type='text'>
commit 8b188fba75195745026e11d408e4a7e94e01d701 upstream.

This reverts commit 37ef4c19b4c659926ce65a7ac709ceaefb211c40.

The touchpad present in the Dell Precision 7550 and 7750 laptops
reports a HID_DG_BUTTONTYPE of type MT_BUTTONTYPE_CLICKPAD. However,
the device is not a clickpad, it is a touchpad with physical buttons.

In order to fix this issue, a quirk for the device was introduced in
libinput [1] [2] to disable the INPUT_PROP_BUTTONPAD property:

	[Precision 7x50 Touchpad]
	MatchBus=i2c
	MatchUdevType=touchpad
	MatchDMIModalias=dmi:*svnDellInc.:pnPrecision7?50*
	AttrInputPropDisable=INPUT_PROP_BUTTONPAD

However, because of the change introduced in 37ef4c19b4 ("Input: clear
BTN_RIGHT/MIDDLE on buttonpads") the BTN_RIGHT key bit is not mapped
anymore breaking the device right click button and making impossible to
workaround it in user space.

In order to avoid breakage on other present or future devices, revert
the patch causing the issue.

Signed-off-by: José Expósito &lt;jose.exposito89@gmail.com&gt;
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Acked-by: Peter Hutterer &lt;peter.hutterer@who-t.net&gt;
Acked-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220321184404.20025-1-jose.exposito89@gmail.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: aiptek - properly check endpoint type</title>
<updated>2022-03-23T08:12:07+00:00</updated>
<author>
<name>Pavel Skripkin</name>
<email>paskripkin@gmail.com</email>
</author>
<published>2022-03-14T05:56:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e732b0412f8c603d1e998f3bff41b5e7d5c3914c'/>
<id>urn:sha1:e732b0412f8c603d1e998f3bff41b5e7d5c3914c</id>
<content type='text'>
commit 5600f6986628dde8881734090588474f54a540a8 upstream.

Syzbot reported warning in usb_submit_urb() which is caused by wrong
endpoint type. There was a check for the number of endpoints, but not
for the type of endpoint.

Fix it by replacing old desc.bNumEndpoints check with
usb_find_common_endpoints() helper for finding endpoints

Fail log:

usb 5-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
Modules linked in:
CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Workqueue: usb_hub_wq hub_event
...
Call Trace:
 &lt;TASK&gt;
 aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830
 input_open_device+0x1bb/0x320 drivers/input/input.c:629
 kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593

Fixes: 8e20cf2bce12 ("Input: aiptek - fix crash on detecting device without endpoints")
Reported-and-tested-by: syzbot+75cccf2b7da87fb6f84b@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin &lt;paskripkin@gmail.com&gt;
Link: https://lore.kernel.org/r/20220308194328.26220-1-paskripkin@gmail.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:07:50+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2022-03-01T07:39:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=52b984b17df9c93d419b8beba6d219da0ded3f49'/>
<id>urn:sha1:52b984b17df9c93d419b8beba6d219da0ded3f49</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>
</feed>
