<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/input, branch linux-4.12.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>Input: trackpoint - assume 3 buttons when buttons detection fails</title>
<updated>2017-09-09T15:39:31+00:00</updated>
<author>
<name>Oscar Campos</name>
<email>oscar.campos@member.fsf.org</email>
</author>
<published>2017-07-19T00:20:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a47814b210eb6a5dbbb8f9525742e9099d0ee64c'/>
<id>a47814b210eb6a5dbbb8f9525742e9099d0ee64c</id>
<content type='text'>
commit 293b915fd9bebf33cdc906516fb28d54649a25ac upstream.

Trackpoint buttons detection fails on ThinkPad 570 and 470 series,
this makes the middle button of the trackpoint to not being recogized.
As I don't believe there is any trackpoint with less than 3 buttons this
patch just assumes three buttons when the extended button information
read fails.

Signed-off-by: Oscar Campos &lt;oscar.campos@member.fsf.org&gt;
Acked-by: Peter Hutterer &lt;peter.hutterer@who-t.net&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Aaron Ma &lt;aaron.ma@canonical.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 293b915fd9bebf33cdc906516fb28d54649a25ac upstream.

Trackpoint buttons detection fails on ThinkPad 570 and 470 series,
this makes the middle button of the trackpoint to not being recogized.
As I don't believe there is any trackpoint with less than 3 buttons this
patch just assumes three buttons when the extended button information
read fails.

Signed-off-by: Oscar Campos &lt;oscar.campos@member.fsf.org&gt;
Acked-by: Peter Hutterer &lt;peter.hutterer@who-t.net&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Aaron Ma &lt;aaron.ma@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Input: xpad - fix PowerA init quirk for some gamepad models</title>
<updated>2017-09-07T06:37:14+00:00</updated>
<author>
<name>Cameron Gutman</name>
<email>aicommander@gmail.com</email>
</author>
<published>2017-08-31T18:52:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6b31ae8707a7b988ad9d56059b57cb361041bdbc'/>
<id>6b31ae8707a7b988ad9d56059b57cb361041bdbc</id>
<content type='text'>
commit f5308d1b83eba20e69df5e0926ba7257c8dd9074 upstream.

The PowerA gamepad initialization quirk worked with the PowerA
wired gamepad I had around (0x24c6:0x543a), but a user reported [0]
that it didn't work for him, even though our gamepads shared the
same vendor and product IDs.

When I initially implemented the PowerA quirk, I wanted to avoid
actually triggering the rumble action during init. My tests showed
that my gamepad would work correctly even if it received a rumble
of 0 intensity, so that's what I went with.

Unfortunately, this apparently isn't true for all models (perhaps
a firmware difference?). This non-working gamepad seems to require
the real magic rumble packet that the Microsoft driver sends, which
actually vibrates the gamepad. To counteract this effect, I still
send the old zero-rumble PowerA quirk packet which cancels the
rumble effect before the motors can spin up enough to vibrate.

[0]: https://github.com/paroj/xpad/issues/48#issuecomment-313904867

Reported-by: Kyle Beauchamp &lt;kyleabeauchamp@gmail.com&gt;
Tested-by: Kyle Beauchamp &lt;kyleabeauchamp@gmail.com&gt;
Fixes: 81093c9848a7 ("Input: xpad - support some quirky Xbox One pads")
Signed-off-by: Cameron Gutman &lt;aicommander@gmail.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 f5308d1b83eba20e69df5e0926ba7257c8dd9074 upstream.

The PowerA gamepad initialization quirk worked with the PowerA
wired gamepad I had around (0x24c6:0x543a), but a user reported [0]
that it didn't work for him, even though our gamepads shared the
same vendor and product IDs.

When I initially implemented the PowerA quirk, I wanted to avoid
actually triggering the rumble action during init. My tests showed
that my gamepad would work correctly even if it received a rumble
of 0 intensity, so that's what I went with.

Unfortunately, this apparently isn't true for all models (perhaps
a firmware difference?). This non-working gamepad seems to require
the real magic rumble packet that the Microsoft driver sends, which
actually vibrates the gamepad. To counteract this effect, I still
send the old zero-rumble PowerA quirk packet which cancels the
rumble effect before the motors can spin up enough to vibrate.

[0]: https://github.com/paroj/xpad/issues/48#issuecomment-313904867

Reported-by: Kyle Beauchamp &lt;kyleabeauchamp@gmail.com&gt;
Tested-by: Kyle Beauchamp &lt;kyleabeauchamp@gmail.com&gt;
Fixes: 81093c9848a7 ("Input: xpad - support some quirky Xbox One pads")
Signed-off-by: Cameron Gutman &lt;aicommander@gmail.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: synaptics - fix device info appearing different on reconnect</title>
<updated>2017-09-07T06:37:14+00:00</updated>
<author>
<name>Anthony Martin</name>
<email>ality@pbrane.org</email>
</author>
<published>2017-08-28T17:26:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2ed56448f555a1ceb8f3568d0bc49eb0a37f09ec'/>
<id>2ed56448f555a1ceb8f3568d0bc49eb0a37f09ec</id>
<content type='text'>
commit 3f9db52dc87b003a1732f3e03f7f5fc8701ef4ad upstream.

User-modified input settings no longer survive a suspend/resume cycle.
Starting with 4.12, the touchpad is reinitialized on every reconnect
because the hardware appears to be different. This can be reproduced
by running the following as root:

    echo -n reconnect &gt;/sys/devices/platform/i8042/serio1/drvctl

A line like the following will show up in dmesg:

    [30378.295794] psmouse serio1: synaptics: hardware appears to be
                   different: id(149271-149271), model(114865-114865),
                   caps(d047b3-d047b1), ext(b40000-b40000).

Note the single bit difference in caps: bit 1 (SYN_CAP_MULTIFINGER).

This happens because we modify our stored copy of the device info
capabilities when we enable advanced gesture mode but this change is
not reflected in the actual hardware capabilities.

It worked in the past because synaptics_query_hardware used to modify
the stored synaptics_device_info struct instead of filling in a new
one, as it does now.

Fix it by no longer faking the SYN_CAP_MULTIFINGER bit when setting
advanced gesture mode. This necessitated a small refactoring.

Fixes: 6c53694fb222 ("Input: synaptics - split device info into a separate structure")
Signed-off-by: Anthony Martin &lt;ality@pbrane.org&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 3f9db52dc87b003a1732f3e03f7f5fc8701ef4ad upstream.

User-modified input settings no longer survive a suspend/resume cycle.
Starting with 4.12, the touchpad is reinitialized on every reconnect
because the hardware appears to be different. This can be reproduced
by running the following as root:

    echo -n reconnect &gt;/sys/devices/platform/i8042/serio1/drvctl

A line like the following will show up in dmesg:

    [30378.295794] psmouse serio1: synaptics: hardware appears to be
                   different: id(149271-149271), model(114865-114865),
                   caps(d047b3-d047b1), ext(b40000-b40000).

Note the single bit difference in caps: bit 1 (SYN_CAP_MULTIFINGER).

This happens because we modify our stored copy of the device info
capabilities when we enable advanced gesture mode but this change is
not reflected in the actual hardware capabilities.

It worked in the past because synaptics_query_hardware used to modify
the stored synaptics_device_info struct instead of filling in a new
one, as it does now.

Fix it by no longer faking the SYN_CAP_MULTIFINGER bit when setting
advanced gesture mode. This necessitated a small refactoring.

Fixes: 6c53694fb222 ("Input: synaptics - split device info into a separate structure")
Signed-off-by: Anthony Martin &lt;ality@pbrane.org&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: ALPS - fix two-finger scroll breakage in right side on ALPS touchpad</title>
<updated>2017-08-30T08:26:29+00:00</updated>
<author>
<name>Masaki Ota</name>
<email>masaki.ota@jp.alps.com</email>
</author>
<published>2017-08-24T22:44:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ddae9e6ec5d57397aa2d0225c62c58794f0e12e2'/>
<id>ddae9e6ec5d57397aa2d0225c62c58794f0e12e2</id>
<content type='text'>
commit 4a646580f793d19717f7e034c8d473b509c27d49 upstream.

Fixed the issue that two finger scroll does not work correctly
on V8 protocol. The cause is that V8 protocol X-coordinate decode
is wrong at SS4 PLUS device. I added SS4 PLUS X decode definition.

Mote notes:
the problem manifests itself by the commit e7348396c6d5 ("Input: ALPS
- fix V8+ protocol handling (73 03 28)"), where a fix for the V8+
protocol was applied.  Although the culprit must have been present
beforehand, the two-finger scroll worked casually even with the
wrongly reported values by some reason.  It got broken by the commit
above just because it changed x_max value, and this made libinput
correctly figuring the MT events.  Since the X coord is reported as
falsely doubled, the events on the right-half side go outside the
boundary, thus they are no longer handled.  This resulted as a broken
two-finger scroll.

One finger event is decoded differently, and it didn't suffer from
this problem.  The problem was only about MT events. --tiwai

Fixes: e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")
Signed-off-by: Masaki Ota &lt;masaki.ota@jp.alps.com&gt;
Tested-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Tested-by: Paul Donohue &lt;linux-kernel@PaulSD.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&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 4a646580f793d19717f7e034c8d473b509c27d49 upstream.

Fixed the issue that two finger scroll does not work correctly
on V8 protocol. The cause is that V8 protocol X-coordinate decode
is wrong at SS4 PLUS device. I added SS4 PLUS X decode definition.

Mote notes:
the problem manifests itself by the commit e7348396c6d5 ("Input: ALPS
- fix V8+ protocol handling (73 03 28)"), where a fix for the V8+
protocol was applied.  Although the culprit must have been present
beforehand, the two-finger scroll worked casually even with the
wrongly reported values by some reason.  It got broken by the commit
above just because it changed x_max value, and this made libinput
correctly figuring the MT events.  Since the X coord is reported as
falsely doubled, the events on the right-half side go outside the
boundary, thus they are no longer handled.  This resulted as a broken
two-finger scroll.

One finger event is decoded differently, and it didn't suffer from
this problem.  The problem was only about MT events. --tiwai

Fixes: e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")
Signed-off-by: Masaki Ota &lt;masaki.ota@jp.alps.com&gt;
Tested-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Tested-by: Paul Donohue &lt;linux-kernel@PaulSD.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&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: elan_i2c - add ELAN0602 ACPI ID to support Lenovo Yoga310</title>
<updated>2017-08-30T08:26:29+00:00</updated>
<author>
<name>KT Liao</name>
<email>kt.liao@emc.com.tw</email>
</author>
<published>2017-08-18T23:58:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8dcee8e81a0e8ad502b7e09e4e3dd39ced09f4c8'/>
<id>8dcee8e81a0e8ad502b7e09e4e3dd39ced09f4c8</id>
<content type='text'>
commit 1d2226e45040ed4aee95b633cbd64702bf7fc2a1 upstream.

Add ELAN0602 to the list of known ACPI IDs to enable support for ELAN
touchpads found in Lenovo Yoga310.

Signed-off-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 1d2226e45040ed4aee95b633cbd64702bf7fc2a1 upstream.

Add ELAN0602 to the list of known ACPI IDs to enable support for ELAN
touchpads found in Lenovo Yoga310.

Signed-off-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: trackpoint - add new trackpoint firmware ID</title>
<updated>2017-08-30T08:26:29+00:00</updated>
<author>
<name>Aaron Ma</name>
<email>aaron.ma@canonical.com</email>
</author>
<published>2017-08-18T19:17:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=38c36f9d1fca5b5e6d2d1be13ab82d1ce714e4b1'/>
<id>38c36f9d1fca5b5e6d2d1be13ab82d1ce714e4b1</id>
<content type='text'>
commit ec667683c532c93fb41e100e5d61a518971060e2 upstream.

Synaptics add new TP firmware ID: 0x2 and 0x3, for now both lower 2 bits
are indicated as TP. Change the constant to bitwise values.

This makes trackpoint to be recognized on Lenovo Carbon X1 Gen5 instead
of it being identified as "PS/2 Generic Mouse".

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

Synaptics add new TP firmware ID: 0x2 and 0x3, for now both lower 2 bits
are indicated as TP. Change the constant to bitwise values.

This makes trackpoint to be recognized on Lenovo Carbon X1 Gen5 instead
of it being identified as "PS/2 Generic Mouse".

Signed-off-by: Aaron Ma &lt;aaron.ma@canonical.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: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB</title>
<updated>2017-08-25T00:15:01+00:00</updated>
<author>
<name>KT Liao</name>
<email>kt.liao@emc.com.tw</email>
</author>
<published>2017-08-15T03:11:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5f46f337bdeb3e461d14b8119d12d0d109ab42f4'/>
<id>5f46f337bdeb3e461d14b8119d12d0d109ab42f4</id>
<content type='text'>
commit 76988690402dde2880bfe06ecccf381d48ba8e1c upstream.

Add 2 new IDs (ELAN0609 and ELAN060B) to the list of ACPI IDs that should
be handled by the driver.

Signed-off-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 76988690402dde2880bfe06ecccf381d48ba8e1c upstream.

Add 2 new IDs (ELAN0609 and ELAN060B) to the list of ACPI IDs that should
be handled by the driver.

Signed-off-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: elan_i2c - add ELAN0608 to the ACPI table</title>
<updated>2017-08-25T00:15:01+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2017-08-15T03:11:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=04d0645d62a5b220d4920813ae32ce61a8712fbd'/>
<id>04d0645d62a5b220d4920813ae32ce61a8712fbd</id>
<content type='text'>
commit 1874064eed0502bd9bef7be8023757b0c4f26883 upstream.

Similar to commit 722c5ac708b4f ("Input: elan_i2c - add ELAN0605 to the
ACPI table"), ELAN0608 should be handled by elan_i2c.

This touchpad can be found in Lenovo ideapad 320-14IKB.

BugLink: https://bugs.launchpad.net/bugs/1708852

Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.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 1874064eed0502bd9bef7be8023757b0c4f26883 upstream.

Similar to commit 722c5ac708b4f ("Input: elan_i2c - add ELAN0605 to the
ACPI table"), ELAN0608 should be handled by elan_i2c.

This touchpad can be found in Lenovo ideapad 320-14IKB.

BugLink: https://bugs.launchpad.net/bugs/1708852

Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.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: i8042 - fix crash at boot time</title>
<updated>2017-07-27T22:10:19+00:00</updated>
<author>
<name>Chen Hong</name>
<email>chenhong3@huawei.com</email>
</author>
<published>2017-07-02T22:11:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6c0d8c2a408402f2d83a41b141efc2e5e8e604c4'/>
<id>6c0d8c2a408402f2d83a41b141efc2e5e8e604c4</id>
<content type='text'>
commit 340d394a789518018f834ff70f7534fc463d3226 upstream.

The driver checks port-&gt;exists twice in i8042_interrupt(), first when
trying to assign temporary "serio" variable, and second time when deciding
whether it should call serio_interrupt(). The value of port-&gt;exists may
change between the 2 checks, and we may end up calling serio_interrupt()
with a NULL pointer:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
IP: [&lt;ffffffff8150feaf&gt;] _spin_lock_irqsave+0x1f/0x40
PGD 0
Oops: 0002 [#1] SMP
last sysfs file:
CPU 0
Modules linked in:

Pid: 1, comm: swapper Not tainted 2.6.32-358.el6.x86_64 #1 QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:[&lt;ffffffff8150feaf&gt;]  [&lt;ffffffff8150feaf&gt;] _spin_lock_irqsave+0x1f/0x40
RSP: 0018:ffff880028203cc0  EFLAGS: 00010082
RAX: 0000000000010000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000282 RSI: 0000000000000098 RDI: 0000000000000050
RBP: ffff880028203cc0 R08: ffff88013e79c000 R09: ffff880028203ee0
R10: 0000000000000298 R11: 0000000000000282 R12: 0000000000000050
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000098
FS:  0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000050 CR3: 0000000001a85000 CR4: 00000000001407f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff88013e79c000, task ffff88013e79b500)
Stack:
ffff880028203d00 ffffffff813de186 ffffffffffffff02 0000000000000000
&lt;d&gt; 0000000000000000 0000000000000000 0000000000000000 0000000000000098
&lt;d&gt; ffff880028203d70 ffffffff813e0162 ffff880028203d20 ffffffff8103b8ac
Call Trace:
&lt;IRQ&gt;
 [&lt;ffffffff813de186&gt;] serio_interrupt+0x36/0xa0
[&lt;ffffffff813e0162&gt;] i8042_interrupt+0x132/0x3a0
[&lt;ffffffff8103b8ac&gt;] ? kvm_clock_read+0x1c/0x20
[&lt;ffffffff8103b8b9&gt;] ? kvm_clock_get_cycles+0x9/0x10
[&lt;ffffffff810e1640&gt;] handle_IRQ_event+0x60/0x170
[&lt;ffffffff8103b154&gt;] ? kvm_guest_apic_eoi_write+0x44/0x50
[&lt;ffffffff810e3d8e&gt;] handle_edge_irq+0xde/0x180
[&lt;ffffffff8100de89&gt;] handle_irq+0x49/0xa0
[&lt;ffffffff81516c8c&gt;] do_IRQ+0x6c/0xf0
[&lt;ffffffff8100b9d3&gt;] ret_from_intr+0x0/0x11
[&lt;ffffffff81076f63&gt;] ? __do_softirq+0x73/0x1e0
[&lt;ffffffff8109b75b&gt;] ? hrtimer_interrupt+0x14b/0x260
[&lt;ffffffff8100c1cc&gt;] ? call_softirq+0x1c/0x30
[&lt;ffffffff8100de05&gt;] ? do_softirq+0x65/0xa0
[&lt;ffffffff81076d95&gt;] ? irq_exit+0x85/0x90
[&lt;ffffffff81516d80&gt;] ? smp_apic_timer_interrupt+0x70/0x9b
[&lt;ffffffff8100bb93&gt;] ? apic_timer_interrupt+0x13/0x20

To avoid the issue let's change the second check to test whether serio is
NULL or not.

Also, let's take i8042_lock in i8042_start() and i8042_stop() instead of
trying to be overly smart and using memory barriers.

Signed-off-by: Chen Hong &lt;chenhong3@huawei.com&gt;
[dtor: take lock in i8042_start()/i8042_stop()]
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 340d394a789518018f834ff70f7534fc463d3226 upstream.

The driver checks port-&gt;exists twice in i8042_interrupt(), first when
trying to assign temporary "serio" variable, and second time when deciding
whether it should call serio_interrupt(). The value of port-&gt;exists may
change between the 2 checks, and we may end up calling serio_interrupt()
with a NULL pointer:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
IP: [&lt;ffffffff8150feaf&gt;] _spin_lock_irqsave+0x1f/0x40
PGD 0
Oops: 0002 [#1] SMP
last sysfs file:
CPU 0
Modules linked in:

Pid: 1, comm: swapper Not tainted 2.6.32-358.el6.x86_64 #1 QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:[&lt;ffffffff8150feaf&gt;]  [&lt;ffffffff8150feaf&gt;] _spin_lock_irqsave+0x1f/0x40
RSP: 0018:ffff880028203cc0  EFLAGS: 00010082
RAX: 0000000000010000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000282 RSI: 0000000000000098 RDI: 0000000000000050
RBP: ffff880028203cc0 R08: ffff88013e79c000 R09: ffff880028203ee0
R10: 0000000000000298 R11: 0000000000000282 R12: 0000000000000050
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000098
FS:  0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000050 CR3: 0000000001a85000 CR4: 00000000001407f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff88013e79c000, task ffff88013e79b500)
Stack:
ffff880028203d00 ffffffff813de186 ffffffffffffff02 0000000000000000
&lt;d&gt; 0000000000000000 0000000000000000 0000000000000000 0000000000000098
&lt;d&gt; ffff880028203d70 ffffffff813e0162 ffff880028203d20 ffffffff8103b8ac
Call Trace:
&lt;IRQ&gt;
 [&lt;ffffffff813de186&gt;] serio_interrupt+0x36/0xa0
[&lt;ffffffff813e0162&gt;] i8042_interrupt+0x132/0x3a0
[&lt;ffffffff8103b8ac&gt;] ? kvm_clock_read+0x1c/0x20
[&lt;ffffffff8103b8b9&gt;] ? kvm_clock_get_cycles+0x9/0x10
[&lt;ffffffff810e1640&gt;] handle_IRQ_event+0x60/0x170
[&lt;ffffffff8103b154&gt;] ? kvm_guest_apic_eoi_write+0x44/0x50
[&lt;ffffffff810e3d8e&gt;] handle_edge_irq+0xde/0x180
[&lt;ffffffff8100de89&gt;] handle_irq+0x49/0xa0
[&lt;ffffffff81516c8c&gt;] do_IRQ+0x6c/0xf0
[&lt;ffffffff8100b9d3&gt;] ret_from_intr+0x0/0x11
[&lt;ffffffff81076f63&gt;] ? __do_softirq+0x73/0x1e0
[&lt;ffffffff8109b75b&gt;] ? hrtimer_interrupt+0x14b/0x260
[&lt;ffffffff8100c1cc&gt;] ? call_softirq+0x1c/0x30
[&lt;ffffffff8100de05&gt;] ? do_softirq+0x65/0xa0
[&lt;ffffffff81076d95&gt;] ? irq_exit+0x85/0x90
[&lt;ffffffff81516d80&gt;] ? smp_apic_timer_interrupt+0x70/0x9b
[&lt;ffffffff8100bb93&gt;] ? apic_timer_interrupt+0x13/0x20

To avoid the issue let's change the second check to test whether serio is
NULL or not.

Also, let's take i8042_lock in i8042_start() and i8042_stop() instead of
trying to be overly smart and using memory barriers.

Signed-off-by: Chen Hong &lt;chenhong3@huawei.com&gt;
[dtor: take lock in i8042_start()/i8042_stop()]
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-rmi4 - only read the F54 query registers which are used</title>
<updated>2017-06-23T07:08:48+00:00</updated>
<author>
<name>Andrew Duggan</name>
<email>aduggan@synaptics.com</email>
</author>
<published>2017-06-23T07:04:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9768935264c4f0e4afd788a185d8e8d89c28e41d'/>
<id>9768935264c4f0e4afd788a185d8e8d89c28e41d</id>
<content type='text'>
The F54 driver is currently only using the first 6 bytes of F54 so there is
no need to read all 27 bytes. Some Dell systems (Dell XP13 9333 and
similar) have an issue with the touchpad or I2C bus when reading reports
larger then 16 bytes. Reads larger then 16 bytes are reported in two HID
reports. Something about the back to back reports seems to cause the next
read to report incorrect data. This results in F30 failing to load and the
click button failing to work.

Previous issues with the I2C controller or touchpad were addressed in:
commit 5b65c2a02966 ("HID: rmi: check sanity of the incoming report")

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=195949
Signed-off-by: Andrew Duggan &lt;aduggan@synaptics.com&gt;
Reviewed-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Reviewed-by: Nick Dyer &lt;nick@shmanahar.org&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The F54 driver is currently only using the first 6 bytes of F54 so there is
no need to read all 27 bytes. Some Dell systems (Dell XP13 9333 and
similar) have an issue with the touchpad or I2C bus when reading reports
larger then 16 bytes. Reads larger then 16 bytes are reported in two HID
reports. Something about the back to back reports seems to cause the next
read to report incorrect data. This results in F30 failing to load and the
click button failing to work.

Previous issues with the I2C controller or touchpad were addressed in:
commit 5b65c2a02966 ("HID: rmi: check sanity of the incoming report")

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=195949
Signed-off-by: Andrew Duggan &lt;aduggan@synaptics.com&gt;
Reviewed-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Reviewed-by: Nick Dyer &lt;nick@shmanahar.org&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;</pre>
</div>
</content>
</entry>
</feed>
