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

HID: multitouch: fix input mode switching on some Elan panels

2016-02-19T22:28:38+00:00

commit 73e7d63efb4d774883a338997943bfa59e127085 upstream.

as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481

This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature
reports on demand for Win8 devices") as the origin of the problem but this
commit actually masked 2 firmware bugs that are annihilating each other:

The report descriptor declares two features in reports 3 and 5:

0x05, 0x0d,                    // Usage Page (Digitizers)             318
0x09, 0x0e,                    // Usage (Device Configuration)        320
0xa1, 0x01,                    // Collection (Application)            322
0x85, 0x03,                    //  Report ID (3)                      324
0x09, 0x22,                    //  Usage (Finger)                     326
0xa1, 0x00,                    //  Collection (Physical)              328
0x09, 0x52,                    //   Usage (Inputmode)                 330
0x15, 0x00,                    //   Logical Minimum (0)               332
0x25, 0x0a,                    //   Logical Maximum (10)              334
0x75, 0x08,                    //   Report Size (8)                   336
0x95, 0x02,                    //   Report Count (2)                  338
0xb1, 0x02,                    //   Feature (Data,Var,Abs)            340
0xc0,                          //  End Collection                     342
0x09, 0x22,                    //  Usage (Finger)                     343
0xa1, 0x00,                    //  Collection (Physical)              345
0x85, 0x05,                    //   Report ID (5)                     347
0x09, 0x57,                    //   Usage (Surface Switch)            349
0x09, 0x58,                    //   Usage (Button Switch)             351
0x15, 0x00,                    //   Logical Minimum (0)               353
0x75, 0x01,                    //   Report Size (1)                   355
0x95, 0x02,                    //   Report Count (2)                  357
0x25, 0x03,                    //   Logical Maximum (3)               359
0xb1, 0x02,                    //   Feature (Data,Var,Abs)            361
0x95, 0x0e,                    //   Report Count (14)                 363
0xb1, 0x03,                    //   Feature (Cnst,Var,Abs)            365
0xc0,                          //  End Collection                     367

The report ID 3 presents 2 input mode features, while only the first one
is handled by the device. Given that we did not checked if one was
previously assigned, we were dealing with the ignored featured and we
should never have been able to switch this panel into the multitouch mode.

However, the firmware presents an other bugs which allowed 6d4f5440
to counteract the faulty report descriptor. When we request the values
of the feature 5, the firmware answers "03 03 00". The fields are correct
but the report id is wrong. Before 6d4f5440, we retrieved all the features
and injected them in the system. So when we called report 5, we injected
in the system the report 3 with the values "03 00".
Setting the second input mode to 03 in this report changed it to "03 03"
and the touchpad switched to the mt mode. We could have set anything
in the second field because the actual value (the first 03 in this report)
was given by the query of report ID 5.

To sum up: 2 bugs in the firmware were hiding that we were accessing the
wrong feature.

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: multitouch: Fetch feature reports on demand for Win8 devices

2016-02-19T22:28:38+00:00

commit 6d4f5440a3a2bb2e9d0d582bbf98234e9e9bb095 upstream.

Some newer Intel Skylake based Dell laptops with Win8 precision touchpad
fail when initial feature reports are fetched from it. Below is an example
output with some additional debug included:

 i2c_hid i2c-DLL0704:01: Fetching the HID descriptor
 i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=20 00
 i2c_hid i2c-DLL0704:01: HID Descriptor: 1e 00 00 01 99 02 21 00 24 ...
 ...
 i2c_hid i2c-DLL0704:01: i2c_hid_get_report
 i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 38 02 23 00
 i2c_hid i2c-DLL0704:01: report (len=4): 04 00 08 05
 i2c_hid i2c-DLL0704:01: report id 13
 i2c_hid i2c-DLL0704:01: i2c_hid_get_report
 i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 3d 02 23 00
 i2c_hid i2c-DLL0704:01: failed to retrieve report from device.
 i2c_hid i2c-DLL0704:01: report id 7
 i2c_hid i2c-DLL0704:01: i2c_hid_get_report
 i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 37 02 23 00
 i2c_hid i2c-DLL0704:01: report (len=259): 03 01 07 fc 28 fe 84 40 ...
 i2c_hid i2c-DLL0704:01: report id 4
 i2c_hid i2c-DLL0704:01: i2c_hid_get_report
 i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 34 02 23 00

We manage to fetch few reports but then the touchpad dies:

 i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration
 i2c_hid i2c-DLL0704:01: failed to retrieve report from device.

it eventually pulls the whole I2C bus low:

 i2c_designware i2c_designware.1: controller timed out
 i2c_hid i2c-DLL0704:01: failed to set a report to device.

Fix this by preventing initial feature report retrieval for Win8 devices.
Instead we fetch reports as needed in mt_feature_mapping(). This prevents
fetching reports which might cause problems with the device in question.

Suggested-by: Benjamin Tissoires 
Signed-off-by: Mika Westerberg 
Reviewed-by: Benjamin Tissoires 
Tested-by: Seth Forshee 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: usbhid: fix recursive deadlock

2016-02-19T22:28:23+00:00

commit e470127e9606b1fa151c4184243e61296d1e0c0f upstream.

The critical section protected by usbhid->lock in hid_ctrl() is too
big and because of this it causes a recursive deadlock. "Too big" means
the case statement and the call to hid_input_report() do not need to be
protected by the spinlock (no URB operations are done inside them).

The deadlock happens because in certain rare cases drivers try to grab
the lock while handling the ctrl irq which grabs the lock before them
as described above. For example newer wacom tablets like 056a:033c try
to reschedule proximity reads from wacom_intuos_schedule_prox_event()
calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report()
which tries to grab the usbhid lock already held by hid_ctrl().

There are two ways to get out of this deadlock:
    1. Make the drivers work "around" the ctrl critical region, in the
    wacom case for ex. by delaying the scheduling of the proximity read
    request itself to a workqueue.
    2. Shrink the critical region so the usbhid lock protects only the
    instructions which modify usbhid state, calling hid_input_report()
    with the spinlock unlocked, allowing the device driver to grab the
    lock first, finish and then grab the lock afterwards in hid_ctrl().

This patch implements the 2nd solution.

Signed-off-by: Ioan-Adrian Ratiu 
Signed-off-by: Jiri Kosina 
Signed-off-by: Jason Gerecke 
Signed-off-by: Greg Kroah-Hartman

HID: core: Avoid uninitialized buffer access

2016-01-31T19:25:54+00:00

commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream.

hid_connect adds various strings to the buffer but they're all
conditional. You can find circumstances where nothing would be written
to it but the kernel will still print the supposedly empty buffer with
printk. This leads to corruption on the console/in the logs.

Ensure buf is initialized to an empty string.

Signed-off-by: Richard Purdie 
[dvhart: Initialize string to "" rather than assign buf[0] = NULL;]
Cc: Jiri Kosina 
Cc: linux-input@vger.kernel.org
Signed-off-by: Darren Hart 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: wacom: Expect 'touch_max' touches if HID_DG_CONTACTCOUNT not present

2016-01-31T19:25:54+00:00

commit df7079380554e6e8e13a0812c7e6c72f669aba5c upstream.

When introduced in commit 1b5d514, the check 'if (hid_data->cc_index >= 0)'
in 'wacom_wac_finger_pre_report' was intended to switch where the driver
got the expected number of contacts from: HID_DG_CONTACTCOUNT if the usage
was present, or 'touch_max' otherwise. Unfortunately, an oversight worthy
of a brown paper bag (specifically, that 'cc_index' could never be negative)
meant that the latter 'else' clause would never be entered.

The patch prior to this one introduced a way for 'cc_index' to be negative,
but only if HID_DG_CONTACTCOUNT is present in some report _other_ than the
one being processed. To ensure the 'else' clause is also entered for devices
which don't have HID_DG_CONTACTCOUNT on _any_ report, we add the additional
constraint that 'cc_report' be non-zero (which is true only if the usage is
present in some report).

Signed-off-by: Jason Gerecke 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: wacom: Tie cached HID_DG_CONTACTCOUNT indices to report ID

2016-01-31T19:25:54+00:00

commit 499522c8c015de995aabce3d0f0bf4b9b17f44c3 upstream.

The cached indicies 'cc_index' and 'cc_value_index' introduced in 1b5d514
are only valid for a single report ID. If a touchscreen has multiple
reports with a HID_DG_CONTACTCOUNT usage, its possible that the values
will not be correct for the report we're handling, resulting in an
incorrect value for 'num_expected'. This has been observed with the Cintiq
Companion 2.

To address this, we store the ID of the report those indicies are valid
for in a new  'cc_report' variable. Before using them to get the expected
contact count, we first check if the ID of the report we're processing
matches 'cc_report'. If it doesn't, we update the indicies to point to
the HID_DG_CONTACTCOUNT usage of the current report (if it has one).

Signed-off-by: Jason Gerecke 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input

2015-09-04T19:02:11+00:00

Pull input subsystem updates from Dmitry Torokhov:
 "Drivers, drivers, drivers...  No interesting input core changes this
  time"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (74 commits)
  Input: elan_i2c - use iap_version to get firmware information
  Input: max8997_haptic - fix module alias
  Input: elan_i2c - fix typos for validpage_count
  Input: psmouse - add small delay for IBM trackpoint pass-through mode
  Input: synaptics - fix handling of disabling gesture mode
  Input: elan_i2c - enable ELAN0100 acpi panels
  Input: gpio-keys - report error when disabling unsupported key
  Input: sur40 - fix error return code
  Input: sentelic - silence some underflow warnings
  Input: zhenhua - switch to using bitrev8()
  Input: cros_ec_keyb - replace KEYBOARD_CROS_EC dependency
  Input: cap11xx - add LED support
  Input: elants_i2c - fix for devm_gpiod_get API change
  Input: elan_i2c - enable asynchronous probing
  Input: elants_i2c - enable asynchronous probing
  Input: elants_i2c - wire up regulator support
  Input: do not emit unneeded EV_SYN when suspending
  Input: elants_i2c - disable idle mode before updating firmware
  MAINTAINERS: Add maintainer for atmel_mxt_ts
  Input: atmel_mxt_ts - remove warning on zero T44 count
  ...

Merge branch 'next' into for-linus

2015-09-03T17:01:44+00:00

Prepare first round of input updates for 4.3 merge window.

Merge branch 'for-4.3/microsoft' into for-linus

2015-09-01T13:38:33+00:00

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

Merge branches 'for-4.3/chicony', 'for-4.3/cp2112', 'for-4.3/i2c-hid', 'for-4.3/lenovo', 'for-4.3/logitech', 'for-4.3/multitouch', 'for-4.3/picolcd', 'for-4.3/rmi', 'for-4.3/sensor-hub', 'for-4.3/sony' and 'for-4.3/wacom' into for-linus

2015-09-01T13:37:30+00:00