<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/hid, branch v4.19.39</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.39</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.39'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-04-27T07:36:41+00:00</updated>
<entry>
<title>i2c-hid: properly terminate i2c_hid_dmi_desc_override_table[] array</title>
<updated>2019-04-27T07:36:41+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-10-27T16:10:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9c1862566176250bae343a5cee617a5ce41efa54'/>
<id>urn:sha1:9c1862566176250bae343a5cee617a5ce41efa54</id>
<content type='text'>
commit b59dfdaef173677b0b7e10f375226c0a1114fd20 upstream.

Commit 9ee3e06610fd ("HID: i2c-hid: override HID descriptors for certain
devices") added a new dmi_system_id quirk table to override certain HID
report descriptors for some systems that lack them.

But the table wasn't properly terminated, causing the dmi matching to
walk off into la-la-land, and starting to treat random data as dmi
descriptor pointers, causing boot-time oopses if you were at all
unlucky.

Terminate the array.

We really should have some way to just statically check that arrays that
should be terminated by an empty entry actually are so.  But the HID
people really should have caught this themselves, rather than have me
deal with an oops during the merge window.  Tssk, tssk.

Cc: Julian Sax &lt;jsbc@gmx.de&gt;
Cc: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Ambrož Bizjak &lt;abizjak.pro@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>HID: usbhid: Add quirk for Redragon/Dragonrise Seymur 2</title>
<updated>2019-04-20T07:16:01+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2018-10-11T07:56:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3d11fc93aa2813ec82883638425b8d6c82b132ad'/>
<id>urn:sha1:3d11fc93aa2813ec82883638425b8d6c82b132ad</id>
<content type='text'>
[ Upstream commit ce9d58d3eafcb2d452a69bdcc1c5f8b8ff640de5 ]

Redragon Seymur 2 stops working since commit 190d7f02ce8e ("HID: input:
do not increment usages when a duplicate is found").

Use quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE suggested by the commit
can solve the issue.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200995
BugLink: https://bugs.launchpad.net/bugs/1793846
Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Reviewed-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: i2c-hid: override HID descriptors for certain devices</title>
<updated>2019-04-20T07:16:01+00:00</updated>
<author>
<name>Julian Sax</name>
<email>jsbc@gmx.de</email>
</author>
<published>2018-09-19T09:46:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8e271100efa63ef6dc13c22e68c91260d4c83614'/>
<id>urn:sha1:8e271100efa63ef6dc13c22e68c91260d4c83614</id>
<content type='text'>
[ Upstream commit 9ee3e06610fdb8a601cde59c92089fb6c1deb4aa ]

A particular touchpad (SIPODEV SP1064) refuses to supply the HID
descriptors. This patch provides the framework for overriding these
descriptors based on DMI data. It also includes the descriptors for
said touchpad, which were extracted by listening to the traffic of the
windows filter driver, as well as the DMI data for the laptops known
to use this device.

Relevant Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1526312

Cc: Hans de Goede &lt;hdegoede@redhat.com&gt;
Reported-and-tested-by: ahormann@gmx.net
Reported-and-tested-by: Bruno Jesus &lt;bruno.fl.jesus@gmail.com&gt;
Reported-and-tested-by: Dietrich &lt;enaut.w@googlemail.com&gt;
Reported-and-tested-by: kloxdami@yahoo.com
Signed-off-by: Julian Sax &lt;jsbc@gmx.de&gt;
Reviewed-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: intel-ish: ipc: handle PIMR before ish_wakeup also clear PISR busy_clear bit</title>
<updated>2019-04-05T20:33:14+00:00</updated>
<author>
<name>Song Hongyan</name>
<email>hongyan.song@intel.com</email>
</author>
<published>2019-01-22T01:06:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=16b06b15dd53a33d9d289069429cf8d877303d9c'/>
<id>urn:sha1:16b06b15dd53a33d9d289069429cf8d877303d9c</id>
<content type='text'>
[ Upstream commit 2edefc056e4f0e6ec9508dd1aca2c18fa320efef ]

Host driver should handle interrupt mask register earlier than wake up ish FW
else there will be conditions when FW interrupt comes, host PIMR register still
not set ready, so move the interrupt mask setting before ish_wakeup.

Clear PISR busy_clear bit in ish_irq_handler. If not clear, there will be
conditions host driver received a busy_clear interrupt (before the busy_clear
mask bit is ready), it will return IRQ_NONE after check_generated_interrupt,
the interrupt will never be cleared, causing the DEVICE not sending following
IRQ.

Since PISR clear should not be called for the CHV device we do this change.
After the change, both ISH2HOST interrupt and busy_clear interrupt will be
considered as interrupt from ISH, busy_clear interrupt will return IRQ_HANDLED
from IPC_IS_BUSY check.

Signed-off-by: Song Hongyan &lt;hongyan.song@intel.com&gt;
Acked-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: intel-ish-hid: avoid binding wrong ishtp_cl_device</title>
<updated>2019-04-05T20:33:06+00:00</updated>
<author>
<name>Hong Liu</name>
<email>hong.liu@intel.com</email>
</author>
<published>2019-02-12T12:05:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b13eb5245f9f730e79ab17593c4e3c8a62fee3b4'/>
<id>urn:sha1:b13eb5245f9f730e79ab17593c4e3c8a62fee3b4</id>
<content type='text'>
[ Upstream commit 0d28f49412405d87d3aae83da255070a46e67627 ]

When performing a warm reset in ishtp bus driver, the ishtp_cl_device
will not be removed, its fw_client still points to the already freed
ishtp_device.fw_clients array.

Later after driver finishing ishtp client enumeration, this dangling
pointer may cause driver to bind the wrong ishtp_cl_device to the new
client, causing wrong callback to be called for messages intended for
the new client.

This helps in development of firmware where frequent switching of
firmwares is required without Linux reboot.

Signed-off-by: Hong Liu &lt;hong.liu@intel.com&gt;
Tested-by: Hongyan Song &lt;hongyan.song@intel.com&gt;
Acked-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: debug: fix the ring buffer implementation</title>
<updated>2019-02-12T18:47:24+00:00</updated>
<author>
<name>Vladis Dronov</name>
<email>vdronov@redhat.com</email>
</author>
<published>2019-01-29T10:58:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c70374ce418e7ae9276d3dc26aed0301e4da5e35'/>
<id>urn:sha1:c70374ce418e7ae9276d3dc26aed0301e4da5e35</id>
<content type='text'>
commit 13054abbaa4f1fd4e6f3b4b63439ec033b4c8035 upstream.

Ring buffer implementation in hid_debug_event() and hid_debug_events_read()
is strange allowing lost or corrupted data. After commit 717adfdaf147
("HID: debug: check length before copy_to_user()") it is possible to enter
an infinite loop in hid_debug_events_read() by providing 0 as count, this
locks up a system. Fix this by rewriting the ring buffer implementation
with kfifo and simplify the code.

This fixes CVE-2019-3819.

v2: fix an execution logic and add a comment
v3: use __set_current_state() instead of set_current_state()

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187
Cc: stable@vger.kernel.org # v4.18+
Fixes: cd667ce24796 ("HID: use debugfs for events/reports dumping")
Fixes: 717adfdaf147 ("HID: debug: check length before copy_to_user()")
Signed-off-by: Vladis Dronov &lt;vdronov@redhat.com&gt;
Reviewed-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>HID: lenovo: Add checks to fix of_led_classdev_register</title>
<updated>2019-02-12T18:47:19+00:00</updated>
<author>
<name>Aditya Pakki</name>
<email>pakki001@umn.edu</email>
</author>
<published>2018-12-24T21:39:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d921bb16259e7aace00fb96ed757d2683358fd26'/>
<id>urn:sha1:d921bb16259e7aace00fb96ed757d2683358fd26</id>
<content type='text'>
[ Upstream commit 6ae16dfb61bce538d48b7fe98160fada446056c5 ]

In lenovo_probe_tpkbd(), the function of_led_classdev_register() could
return an error value that is unchecked. The fix adds these checks.

Signed-off-by: Aditya Pakki &lt;pakki001@umn.edu&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: ite: Add USB id match for another ITE based keyboard rfkill key quirk</title>
<updated>2019-01-13T08:50:56+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2018-11-26T10:52:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=270a08ffa1b96f366cf5c9dc42c56d42d2e4d9f1'/>
<id>urn:sha1:270a08ffa1b96f366cf5c9dc42c56d42d2e4d9f1</id>
<content type='text'>
[ Upstream commit 4050207485e47e00353e87f2fe2166083e282688 ]

The 258a:6a88 keyboard-dock shipped with the Prowise PT301 tablet is
likely another ITE based design. The controller die is directly bonded
to the PCB with a blob of black glue on top so there are no markings and
the 258a vendor-id used is unknown anywhere. But the keyboard has the
exact same hotkeys mapped to Fn+F1 - F10 as the other ITE8595 keyboard
I have *and* it has the same quirky behavior wrt the rfkill hotkey.

Either way as said this keyboard has the same quirk for its rfkill /
airplane mode hotkey as the ITE 8595 chip, it only sends a single release
event when pressed and released, it never sends a press event.

This commit adds the 258a:6a88 USB id to the hid-ite id-table, fixing
the rfkill key not working on this keyboard.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Input: hyper-v - fix wakeup from suspend-to-idle</title>
<updated>2018-12-21T13:15:12+00:00</updated>
<author>
<name>Vitaly Kuznetsov</name>
<email>vkuznets@redhat.com</email>
</author>
<published>2018-11-15T19:05:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=53e0d8ecc83f00612f18d9071e9e15d6ac252205'/>
<id>urn:sha1:53e0d8ecc83f00612f18d9071e9e15d6ac252205</id>
<content type='text'>
[ Upstream commit 10f91c73cc41ceead210a905dbd196398e99c7d2 ]

It makes little sense but still possible to put Hyper-V guests into
suspend-to-idle state. To wake them up two wakeup sources were registered
in the past: hyperv-keyboard and hid-hyperv. However, since
commit eed4d47efe95 ("ACPI / sleep: Ignore spurious SCI wakeups from
suspend-to-idle") pm_wakeup_event() from these devices is ignored. Switch
to pm_wakeup_hard_event() API as these devices are actually the only
possible way to wakeup Hyper-V guests.

Fixes: eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle)
Reviewed-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Acked-by: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
Acked-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&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>HID: quirks: fix RetroUSB.com devices</title>
<updated>2018-12-13T08:16:23+00:00</updated>
<author>
<name>Nic Soudée</name>
<email>nsoudee@gmail.com</email>
</author>
<published>2018-12-06T16:59:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0fc19a8881e68ccbd252e2916756c7b6a7bec65c'/>
<id>urn:sha1:0fc19a8881e68ccbd252e2916756c7b6a7bec65c</id>
<content type='text'>
commit 868613f1c0ccf7b832f38b48b18cca31cdeb3d26 upstream.

SNES RetroPort and RetroPad register only 4 gamepad buttons
when they should register all 8 buttons. This is described here:

https://ask.fedoraproject.org/en/question/128102

This is happening because of:

Commit 190d7f02ce8e ("HID: input: do not increment usages when
    duplicate is found")

Here, I add the quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE
(created for backward compatibility with the change in 190d7f02ce8e)
for the two products.

Tested with both RetroPort and RetroPad.

Cc: stable@vger.kernel.org  # v4.18+

Signed-off-by: Nic Soudée &lt;nsoudee@gmail.com&gt;
Signed-off-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
