<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/input/mouse, branch v5.17</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v5.17</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v5.17'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2022-03-02T04:41:22Z</updated>
<entry>
<title>Input: elan_i2c - fix regulator enable count imbalance after suspend/resume</title>
<updated>2022-03-02T04:41:22Z</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.shady.money/linux/commit/?id=04b7762e37c95d9b965d16bb0e18dbd1fa2e2861'/>
<id>urn:sha1:04b7762e37c95d9b965d16bb0e18dbd1fa2e2861</id>
<content type='text'>
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;
</content>
</entry>
<entry>
<title>Input: elan_i2c - move regulator_[en|dis]able() out of elan_[en|dis]able_power()</title>
<updated>2022-03-02T04:41:20Z</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.shady.money/linux/commit/?id=81a36d8ce554b82b0a08e2b95d0bd44fcbff339b'/>
<id>urn:sha1:81a36d8ce554b82b0a08e2b95d0bd44fcbff339b</id>
<content type='text'>
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;
</content>
</entry>
<entry>
<title>Input: psmouse - set up dependency between PS/2 and SMBus companions</title>
<updated>2022-02-18T21:29:26Z</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2022-02-15T21:32:26Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7b1f781f2d2460693f43d5f764198df558e3494b'/>
<id>urn:sha1:7b1f781f2d2460693f43d5f764198df558e3494b</id>
<content type='text'>
When we switch from emulated PS/2 to native (RMI4 or Elan) protocols, we
create SMBus companion devices that are attached to I2C/SMBus controllers.
However, when suspending and resuming, we also need to make sure that we
take into account the PS/2 device they are associated with, so that PS/2
device is suspended after the companion and resumed before it, otherwise
companions will not work properly. Before I2C devices were marked for
asynchronous suspend/resume, this ordering happened naturally, but now we
need to enforce it by establishing device links, with PS/2 devices being
suppliers and SMBus companions being consumers.

Fixes: 172d931910e1 ("i2c: enable async suspend/resume on i2c client devices")
Reported-and-tested-by: Hugh Dickins &lt;hughd@google.com&gt;
Tested-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Link: https://lore.kernel.org/r/89456fcd-a113-4c82-4b10-a9bcaefac68f@google.com
Link: https://lore.kernel.org/r/YgwQN8ynO88CPMju@google.com
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'next' into for-linus</title>
<updated>2022-01-15T20:09:44Z</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2022-01-15T20:09:44Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=762f99f4f3cb41a775b5157dd761217beba65873'/>
<id>urn:sha1:762f99f4f3cb41a775b5157dd761217beba65873</id>
<content type='text'>
Prepare input updates for 5.17 merge window.
</content>
</entry>
<entry>
<title>Input: appletouch - initialize work before device registration</title>
<updated>2021-12-31T05:04:04Z</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.shady.money/linux/commit/?id=9f3ccdc3f6ef10084ceb3a47df0961bec6196fd0'/>
<id>urn:sha1:9f3ccdc3f6ef10084ceb3a47df0961bec6196fd0</id>
<content type='text'>
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;
</content>
</entry>
<entry>
<title>Input: byd - fix typo in a comment</title>
<updated>2021-12-20T08:59:50Z</updated>
<author>
<name>Xiang wangx</name>
<email>wangxiang@cdjrlc.com</email>
</author>
<published>2021-12-20T02:06:45Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=652c0441de588dafb68516eccd4a89662830d23b'/>
<id>urn:sha1:652c0441de588dafb68516eccd4a89662830d23b</id>
<content type='text'>
The double `the' in a comment is repeated, thus it should be removed.

Signed-off-by: Xiang wangx &lt;wangxiang@cdjrlc.com&gt;
Link: https://lore.kernel.org/r/20211216082735.11948-1-wangxiang@cdjrlc.com
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'v5.15' into next</title>
<updated>2021-12-09T07:43:50Z</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2021-12-09T07:43:50Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5d8dfaa71d87f742c53309b95cb6a8b274119027'/>
<id>urn:sha1:5d8dfaa71d87f742c53309b95cb6a8b274119027</id>
<content type='text'>
Sync up with the mainline to get the latest APIs and DT bindings.
</content>
</entry>
<entry>
<title>Input: elantech - fix stack out of bound access in elantech_change_report_id()</title>
<updated>2021-11-29T08:11:15Z</updated>
<author>
<name>Andrea Righi</name>
<email>andrea.righi@canonical.com</email>
</author>
<published>2021-11-29T08:08:13Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1d72d9f960ccf1052a0630a68c3d358791dbdaaa'/>
<id>urn:sha1:1d72d9f960ccf1052a0630a68c3d358791dbdaaa</id>
<content type='text'>
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] &gt;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: e4c9062717fe ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode")
BugLink: https://bugs.launchpad.net/bugs/1945590
Signed-off-by: Andrea Righi &lt;andrea.righi@canonical.com&gt;
Reviewed-by: Wolfram Sang &lt;wsa@kernel.org&gt;
Link: https://lore.kernel.org/r/20211116095559.24395-1-andrea.righi@canonical.com
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'next' into for-linus</title>
<updated>2021-11-12T05:58:54Z</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2021-11-12T05:58:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=efe6f16c6faf724882ddaba2eda8830a87bcc2b2'/>
<id>urn:sha1:efe6f16c6faf724882ddaba2eda8830a87bcc2b2</id>
<content type='text'>
Prepare input updates for 5.16 merge window.
</content>
</entry>
<entry>
<title>Input: elantench - fix misreporting trackpoint coordinates</title>
<updated>2021-11-10T06:22:43Z</updated>
<author>
<name>Phoenix Huang</name>
<email>phoenix@emc.com.tw</email>
</author>
<published>2021-11-08T06:00:03Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=be896bd3b72b44126c55768f14c22a8729b0992e'/>
<id>urn:sha1:be896bd3b72b44126c55768f14c22a8729b0992e</id>
<content type='text'>
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 &lt;phoenix@emc.com.tw&gt;
Tested-by: Yufei Du &lt;yufeidu@cs.unc.edu&gt;
Link: https://lore.kernel.org/r/20210729010940.5752-1-phoenix@emc.com.tw
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
</content>
</entry>
</feed>
