<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/input, branch v4.14.49</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>Input: elan_i2c_smbus - fix corrupted stack</title>
<updated>2018-06-05T09:41:56+00:00</updated>
<author>
<name>Benjamin Tissoires</name>
<email>benjamin.tissoires@redhat.com</email>
</author>
<published>2018-05-23T00:19:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2be683020be4bd8032ae07f6974656daa66f378d'/>
<id>2be683020be4bd8032ae07f6974656daa66f378d</id>
<content type='text'>
commit 40f7090bb1b4ec327ea1e1402ff5783af5b35195 upstream.

New ICs (like the one on the Lenovo T480s) answer to
ETP_SMBUS_IAP_VERSION_CMD 4 bytes instead of 3. This corrupts the stack
as i2c_smbus_read_block_data() uses the values returned by the i2c
device to know how many data it need to return.

i2c_smbus_read_block_data() can read up to 32 bytes (I2C_SMBUS_BLOCK_MAX)
and there is no safeguard on how many bytes are provided in the return
value. Ensure we always have enough space for any future firmware.
Also 0-initialize the values to prevent any access to uninitialized memory.

Cc: &lt;stable@vger.kernel.org&gt; # v4.4.x, v4.9.x, v4.14.x, v4.15.x, v4.16.x
Signed-off-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Acked-by: KT Liao &lt;kt.liao@emc.com.tw&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 40f7090bb1b4ec327ea1e1402ff5783af5b35195 upstream.

New ICs (like the one on the Lenovo T480s) answer to
ETP_SMBUS_IAP_VERSION_CMD 4 bytes instead of 3. This corrupts the stack
as i2c_smbus_read_block_data() uses the values returned by the i2c
device to know how many data it need to return.

i2c_smbus_read_block_data() can read up to 32 bytes (I2C_SMBUS_BLOCK_MAX)
and there is no safeguard on how many bytes are provided in the return
value. Ensure we always have enough space for any future firmware.
Also 0-initialize the values to prevent any access to uninitialized memory.

Cc: &lt;stable@vger.kernel.org&gt; # v4.4.x, v4.9.x, v4.14.x, v4.15.x, v4.16.x
Signed-off-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Acked-by: KT Liao &lt;kt.liao@emc.com.tw&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Input: synaptics - add Lenovo 80 series ids to SMBus</title>
<updated>2018-06-05T09:41:56+00:00</updated>
<author>
<name>Benjamin Tissoires</name>
<email>benjamin.tissoires@redhat.com</email>
</author>
<published>2018-05-23T00:16:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=9a85abc794831bc550de3e616588efff14d2c60a'/>
<id>9a85abc794831bc550de3e616588efff14d2c60a</id>
<content type='text'>
commit ad8fb554f04e38f155c9bc34bbf521fc592ceee7 upstream.

This time, Lenovo decided to go with different pieces in its latest
series of Thinkpads.

For those we have been able to test:
- the T480 is using Synaptics with an IBM trackpoint
   -&gt; it behaves properly with or without intertouch, there is no point
      not using RMI4
- the X1 Carbon 6th gen is using Synaptics with an IBM trackpoint
   -&gt; the touchpad doesn't behave properly under PS/2 so we have to
      switch it to RMI4 if we do not want to have disappointed users
- the X280 is using Synaptics with an ALPS trackpoint
   -&gt; the recent fixes in the trackpoint handling fixed it so upstream
      now works fine with or without RMI4, and there is no point not
      using RMI4
- the T480s is using an Elan touchpad, so that's a different story

Cc: &lt;stable@vger.kernel.org&gt; # v4.14.x, v4.15.x, v4.16.x
Signed-off-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Acked-by: KT Liao &lt;kt.liao@emc.com.tw&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ad8fb554f04e38f155c9bc34bbf521fc592ceee7 upstream.

This time, Lenovo decided to go with different pieces in its latest
series of Thinkpads.

For those we have been able to test:
- the T480 is using Synaptics with an IBM trackpoint
   -&gt; it behaves properly with or without intertouch, there is no point
      not using RMI4
- the X1 Carbon 6th gen is using Synaptics with an IBM trackpoint
   -&gt; the touchpad doesn't behave properly under PS/2 so we have to
      switch it to RMI4 if we do not want to have disappointed users
- the X280 is using Synaptics with an ALPS trackpoint
   -&gt; the recent fixes in the trackpoint handling fixed it so upstream
      now works fine with or without RMI4, and there is no point not
      using RMI4
- the T480s is using an Elan touchpad, so that's a different story

Cc: &lt;stable@vger.kernel.org&gt; # v4.14.x, v4.15.x, v4.16.x
Signed-off-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Acked-by: KT Liao &lt;kt.liao@emc.com.tw&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Input: synaptics - add Intertouch support on X1 Carbon 6th and X280</title>
<updated>2018-06-05T09:41:56+00:00</updated>
<author>
<name>Aaron Ma</name>
<email>aaron.ma@canonical.com</email>
</author>
<published>2018-02-03T19:49:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=9c707c93e179ca03b593d4f1c3789dbfe94d5157'/>
<id>9c707c93e179ca03b593d4f1c3789dbfe94d5157</id>
<content type='text'>
commit 5717a09aeaf62d197deba1fc7ccd6bc45f3a9dcc upstream.

Synaptics devices reported it has Intertouch support,
and it fails via PS/2 as following logs:

psmouse serio2: Failed to reset mouse on synaptics-pt/serio0
psmouse serio2: Failed to enable mouse on synaptics-pt/serio0

Set these new devices to use SMBus to fix this issue, then they report
SMBus version 3 is using, patch:
https://patchwork.kernel.org/patch/9989547/ enabled SMBus ver 3 and
makes synaptics devices work fine on SMBus mode.

Signed-off-by: Aaron Ma &lt;aaron.ma@canonical.com&gt;
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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5717a09aeaf62d197deba1fc7ccd6bc45f3a9dcc upstream.

Synaptics devices reported it has Intertouch support,
and it fails via PS/2 as following logs:

psmouse serio2: Failed to reset mouse on synaptics-pt/serio0
psmouse serio2: Failed to enable mouse on synaptics-pt/serio0

Set these new devices to use SMBus to fix this issue, then they report
SMBus version 3 is using, patch:
https://patchwork.kernel.org/patch/9989547/ enabled SMBus ver 3 and
makes synaptics devices work fine on SMBus mode.

Signed-off-by: Aaron Ma &lt;aaron.ma@canonical.com&gt;
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;

</pre>
</div>
</content>
</entry>
<entry>
<title>Input: synaptics - Lenovo Thinkpad X1 Carbon G5 (2017) with Elantech trackpoints should use RMI</title>
<updated>2018-06-05T09:41:56+00:00</updated>
<author>
<name>Edvard Holst</name>
<email>edvard.holst@gmail.com</email>
</author>
<published>2018-02-03T19:46:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=af504c5a88b3fca04855dd0868d33b7ec3025261'/>
<id>af504c5a88b3fca04855dd0868d33b7ec3025261</id>
<content type='text'>
commit 15e2cffec3aa0d47a8d75ae80e1b136bfb5dff30 upstream.

Lenovo use two different trackpoints in the fifth generation Thinkpad X1
Carbon. Both are accessible over SMBUS/RMI but the pnpIDs are missing.
This patch is for the Elantech trackpoint specifically which also
reports SMB version 3 so rmi_smbus needs to be updated in order to
handle it.

For the record, I was not the first one to come up with this patch as it
has been floating around the internet for a while now. However, I have
spent significant time with testing and my efforts to find the original
author of the patch have been unsuccessful.

Signed-off-by: Edvard Holst &lt;edvard.holst@gmail.com&gt;
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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 15e2cffec3aa0d47a8d75ae80e1b136bfb5dff30 upstream.

Lenovo use two different trackpoints in the fifth generation Thinkpad X1
Carbon. Both are accessible over SMBUS/RMI but the pnpIDs are missing.
This patch is for the Elantech trackpoint specifically which also
reports SMB version 3 so rmi_smbus needs to be updated in order to
handle it.

For the record, I was not the first one to come up with this patch as it
has been floating around the internet for a while now. However, I have
spent significant time with testing and my efforts to find the original
author of the patch have been unsuccessful.

Signed-off-by: Edvard Holst &lt;edvard.holst@gmail.com&gt;
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;

</pre>
</div>
</content>
</entry>
<entry>
<title>Input: synaptics - Lenovo Carbon X1 Gen5 (2017) devices should use RMI</title>
<updated>2018-06-05T09:41:55+00:00</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2017-08-18T19:08:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=88859f6cc5c41ec8235a9eb36f6c3f2a13f3ee26'/>
<id>88859f6cc5c41ec8235a9eb36f6c3f2a13f3ee26</id>
<content type='text'>
commit 9b2071028f8def49971a3b213ab6efd02a7e56e8 upstream.

The touchpad on Lenovo Carbon X1 Gen 5 (2017 - Kabylake) is accessible over
SMBUS/RMI, so let's activate it by default.

Cc: stable@vger.kernel.org
Reviewed-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9b2071028f8def49971a3b213ab6efd02a7e56e8 upstream.

The touchpad on Lenovo Carbon X1 Gen 5 (2017 - Kabylake) is accessible over
SMBUS/RMI, so let's activate it by default.

Cc: stable@vger.kernel.org
Reviewed-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Input: atmel_mxt_ts - add touchpad button mapping for Samsung Chromebook Pro</title>
<updated>2018-05-09T07:51:51+00:00</updated>
<author>
<name>Vittorio Gambaletta (VittGam)</name>
<email>linuxbugs@vittgam.net</email>
</author>
<published>2018-04-25T22:22:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=10579ed39e20ed896347711640122e54e33455b5'/>
<id>10579ed39e20ed896347711640122e54e33455b5</id>
<content type='text'>
commit f372b81101e6895252298e563d634d5e44ae81e7 upstream.

This patch adds the correct platform data information for the Caroline
Chromebook, so that the mouse button does not get stuck in pressed state
after the first click.

The Samus button keymap and platform data definition are the correct
ones for Caroline, so they have been reused here.

Signed-off-by: Vittorio Gambaletta &lt;linuxbugs@vittgam.net&gt;
Signed-off-by: Salvatore Bellizzi &lt;lkml@seppia.net&gt;
Tested-by: Guenter Roeck &lt;groeck@chromium.org&gt;
Cc: stable@vger.kernel.org
[dtor: adjusted vendor spelling to match shipping firmware]
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f372b81101e6895252298e563d634d5e44ae81e7 upstream.

This patch adds the correct platform data information for the Caroline
Chromebook, so that the mouse button does not get stuck in pressed state
after the first click.

The Samus button keymap and platform data definition are the correct
ones for Caroline, so they have been reused here.

Signed-off-by: Vittorio Gambaletta &lt;linuxbugs@vittgam.net&gt;
Signed-off-by: Salvatore Bellizzi &lt;lkml@seppia.net&gt;
Tested-by: Guenter Roeck &lt;groeck@chromium.org&gt;
Cc: stable@vger.kernel.org
[dtor: adjusted vendor spelling to match shipping firmware]
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Input: leds - fix out of bound access</title>
<updated>2018-05-09T07:51:51+00:00</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2018-04-06T17:23:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=894937021946214de310ebafef6462a19c6dfaba'/>
<id>894937021946214de310ebafef6462a19c6dfaba</id>
<content type='text'>
commit 6bd6ae639683c0b41f46990d5c64ff9fbfa019dc upstream.

UI_SET_LEDBIT ioctl() causes the following KASAN splat when used with
led &gt; LED_CHARGING:

[ 1274.663418] BUG: KASAN: slab-out-of-bounds in input_leds_connect+0x611/0x730 [input_leds]
[ 1274.663426] Write of size 8 at addr ffff88003377b2c0 by task ckb-next-daemon/5128

This happens because we were writing to the led structure before making
sure that it exists.

Reported-by: Tasos Sahanidis &lt;tasos@tasossah.com&gt;
Tested-by: Tasos Sahanidis &lt;tasos@tasossah.com&gt;
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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6bd6ae639683c0b41f46990d5c64ff9fbfa019dc upstream.

UI_SET_LEDBIT ioctl() causes the following KASAN splat when used with
led &gt; LED_CHARGING:

[ 1274.663418] BUG: KASAN: slab-out-of-bounds in input_leds_connect+0x611/0x730 [input_leds]
[ 1274.663426] Write of size 8 at addr ffff88003377b2c0 by task ckb-next-daemon/5128

This happens because we were writing to the led structure before making
sure that it exists.

Reported-by: Tasos Sahanidis &lt;tasos@tasossah.com&gt;
Tested-by: Tasos Sahanidis &lt;tasos@tasossah.com&gt;
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;

</pre>
</div>
</content>
</entry>
<entry>
<title>Input: stmfts - set IRQ_NOAUTOEN to the irq flag</title>
<updated>2018-04-26T09:02:10+00:00</updated>
<author>
<name>Andi Shyti</name>
<email>andi.shyti@samsung.com</email>
</author>
<published>2018-01-23T01:32:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=6a5505da41faa98555526ba50ca9865a2bd0ef99'/>
<id>6a5505da41faa98555526ba50ca9865a2bd0ef99</id>
<content type='text'>
[ Upstream commit cba04cdf437d745fac85220d1d692a9ae23d7004 ]

The interrupt is requested before the device is powered on and
it's value in some cases cannot be reliable. It happens on some
devices that an interrupt is generated as soon as requested
before having the chance to disable the irq.

Set the irq flag as IRQ_NOAUTOEN before requesting it.

This patch mutes the error:

  stmfts 2-0049: failed to read events: -11

received sometimes during boot time.

Signed-off-by: Andi Shyti &lt;andi.shyti@samsung.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit cba04cdf437d745fac85220d1d692a9ae23d7004 ]

The interrupt is requested before the device is powered on and
it's value in some cases cannot be reliable. It happens on some
devices that an interrupt is generated as soon as requested
before having the chance to disable the irq.

Set the irq flag as IRQ_NOAUTOEN before requesting it.

This patch mutes the error:

  stmfts 2-0049: failed to read events: -11

received sometimes during boot time.

Signed-off-by: Andi Shyti &lt;andi.shyti@samsung.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Input: synaptics - reset the ABS_X/Y fuzz after initializing MT axes</title>
<updated>2018-04-26T09:02:05+00:00</updated>
<author>
<name>Peter Hutterer</name>
<email>peter.hutterer@who-t.net</email>
</author>
<published>2018-01-16T23:20:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=0d5ef8956c84a4d6667d41085755b09ac54266c6'/>
<id>0d5ef8956c84a4d6667d41085755b09ac54266c6</id>
<content type='text'>
[ Upstream commit 19eb4ed1141bd1096b9bc84ba9c4d03d5830c143 ]

input_mt_init_slots() resets the ABS_X/Y fuzz to 0 and expects the driver
to call input_mt_report_pointer_emulation(). That is based on the MT
position bits which are already defuzzed - hence a fuzz of 0.

In the case of synaptics semi-mt devices, we report the ABS_X/Y axes
manually.  This results in the MT position being defuzzed but the
single-touch emulation missing that defuzzing.

Work around this by re-initializing the ABS_X/Y axes after the MT axis to
get the same fuzz value back.

https://bugs.freedesktop.org/show_bug.cgi?id=104533

Signed-off-by: Peter Hutterer &lt;peter.hutterer@who-t.net&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 19eb4ed1141bd1096b9bc84ba9c4d03d5830c143 ]

input_mt_init_slots() resets the ABS_X/Y fuzz to 0 and expects the driver
to call input_mt_report_pointer_emulation(). That is based on the MT
position bits which are already defuzzed - hence a fuzz of 0.

In the case of synaptics semi-mt devices, we report the ABS_X/Y axes
manually.  This results in the MT position being defuzzed but the
single-touch emulation missing that defuzzing.

Work around this by re-initializing the ABS_X/Y axes after the MT axis to
get the same fuzz value back.

https://bugs.freedesktop.org/show_bug.cgi?id=104533

Signed-off-by: Peter Hutterer &lt;peter.hutterer@who-t.net&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Input: psmouse - fix Synaptics detection when protocol is disabled</title>
<updated>2018-04-26T09:02:05+00:00</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2018-01-09T21:44:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=d925c308742284e508c984bc820b47a3d5c88397'/>
<id>d925c308742284e508c984bc820b47a3d5c88397</id>
<content type='text'>
[ Upstream commit 2bc4298f59d2f15175bb568e2d356b5912d0cdd9 ]

When Synaptics protocol is disabled, we still need to try and detect the
hardware, so we can switch to SMBus device if SMbus is detected, or we know
that it is Synaptics device and reset it properly for the bare PS/2
protocol.

Fixes: c378b5119eb0 ("Input: psmouse - factor out common protocol probing code")
Reported-by: Matteo Croce &lt;mcroce@redhat.com&gt;
Tested-by: Matteo Croce &lt;mcroce@redhat.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2bc4298f59d2f15175bb568e2d356b5912d0cdd9 ]

When Synaptics protocol is disabled, we still need to try and detect the
hardware, so we can switch to SMBus device if SMbus is detected, or we know
that it is Synaptics device and reset it properly for the bare PS/2
protocol.

Fixes: c378b5119eb0 ("Input: psmouse - factor out common protocol probing code")
Reported-by: Matteo Croce &lt;mcroce@redhat.com&gt;
Tested-by: Matteo Croce &lt;mcroce@redhat.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
