linux-stable.git/drivers/hid, branch v4.7.2

HID: uhid: fix timeout when probe races with IO

2016-08-20T16:10:54+00:00

commit 67f8ecc550b5bda03335f845dc869b8501d25fd0 upstream.

Many devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination
with uhid. If any of these stacks is used with a HID device for which the driver
performs a HID request as part .probe (or technically another HID operation),
this results in a deadlock situation. The deadlock results in a 5 second timeout
for I/O operations in HID drivers, so isn't fatal, but none of the I/O operations
have a chance of succeeding.

The root cause for the problem is that uhid only allows for one request to be
processed at a time per uhid instance and locks out other operations. This means
that if a user space is creating a new HID device through 'UHID_CREATE', which
ultimately triggers '.probe' through the HID layer. Then any HID request e.g. a
read for calibration data would trigger a HID operation on uhid again, but it
won't go out to userspace, because it is still stuck in UHID_CREATE.
In addition bluetooth stacks are typically single threaded, so they wouldn't be
able to handle any requests while waiting on uhid.

Lucikly the UHID spec is somewhat flexible and allows for fixing the issue,
without breaking user space. The idea which the patch implements as discussed
with David Herrmann is to decouple adding of a hid device (which triggers .probe)
from UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or
else will wait a tiny bit of time in .probe for a lock). A HID driver has to call
HID to call 'hid_hw_start()' as part of .probe once it is ready for I/O, which
triggers UHID_START to user space. Any HID operations should function now within
.probe and won't deadlock because userspace is stuck on UHID_CREATE.

We verified this patch on Bluedroid with Android 6.0 and on desktop Linux with
BlueZ stacks. Prior to the patch they had the deadlock issue.

[jkosina@suse.cz: reword subject]
Signed-off-by: Roderick Colenbrander 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: multitouch: enable palm rejection for Windows Precision Touchpad

2016-06-28T11:24:14+00:00

The usage Confidence is mandary to Windows Precision Touchpad devices. If
it is examined in input_mapping on a WIndows Precision Touchpad, a new add
quirk MT_QUIRK_CONFIDENCE desgned for such devices will be applied to the
device. A touch with the confidence bit is not set is determined as
invalid.

Tested on Dell XPS13 9343

Cc: stable@vger.kernel.org # v4.5+
Reviewed-by: Benjamin Tissoires 
Tested-by: Andy Lutomirski  # XPS 13 9350, BIOS 1.4.3
Signed-off-by: Allen Hung 
Signed-off-by: Jiri Kosina

Revert "HID: multitouch: enable palm rejection if device implements confidence usage"

2016-06-28T11:24:14+00:00

This reverts commit 25a84db15b3f ("HID: multitouch: enable palm rejection
if device implements confidence usage")

The commit enables palm rejection for Win8 Precision Touchpad devices but
the quirk MT_QUIRK_VALID_IS_CONFIDENCE it is using is not working very
properly. This quirk is originally designed for some WIn7 touchscreens. Use
of this for a Win8 Precision Touchpad will cause unexpected pointer jumping
problem.

Cc: stable@vger.kernel.org # v4.5+
Reviewed-by: Benjamin Tissoires 
Tested-by: Andy Lutomirski  # XPS 13 9350, BIOS 1.4.3
Signed-off-by: Allen Hung 
Signed-off-by: Jiri Kosina

HID: hiddev: validate num_values for HIDIOCGUSAGES, HIDIOCSUSAGES commands

2016-06-24T08:21:39+00:00

This patch validates the num_values parameter from userland during the
HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the report id was set
to HID_REPORT_ID_UNKNOWN, we would fail to validate the num_values parameter
leading to a heap overflow.

Cc: stable@vger.kernel.org
Signed-off-by: Scott Bauer 
Signed-off-by: Jiri Kosina

HID: multitouch: Add MT_QUIRK_NOT_SEEN_MEANS_UP to Surface Pro 3

2016-06-01T14:03:28+00:00

The firmware found in the touch screen of an SP3 is buggy and may miss
to send lift off reports for contacts. Try to work around that issue by
using MT_QUIRK_NOT_SEEN_MEANS_UP.

based on a patch from: Daniel Martin 

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: elo: kill not flush the work

2016-06-01T12:08:17+00:00

Flushing a work that reschedules itself is not a sensible operation. It needs
to be killed. Failure to do so leads to a kernel panic in the timer code.

CC: stable@vger.kernel.org
Signed-off-by: Oliver Neukum 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

Merge branch 'for-4.7/wacom' into for-linus

2016-05-17T10:42:27+00:00

Merge branch 'for-4.7/upstream' into for-linus

2016-05-17T10:41:22+00:00

Conflicts:
	drivers/hid/usbhid/hid-quirks.c

Merge branches 'for-4.6/upstream-fixes', 'for-4.7/asus', 'for-4.7/hidraw' and 'for-4.7/thingm' into for-linus

2016-05-17T10:38:03+00:00

HID: wacom: add missed stylus_in_proximity line back

2016-05-03T10:03:44+00:00

Commit 7e12978 ("HID: wacom: break out wacom_intuos_get_tool_type") by accident
removed stylus_in_proximity flag for Intuos series while shuffling the code
around.

Fix that by reintroducing that flag setting in wacom_intuos_inout(), where
it originally was.

Fixes: 7e12978 ("HID: wacom: break out wacom_intuos_get_tool_type")
Signed-off-by: Ping Cheng 
Signed-off-by: Jiri Kosina