Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 19 1月, 2016 2 次提交
  3. 08 1月, 2016 3 次提交
  5. 31 12月, 2015 1 次提交
    • M
      HID: i2c-hid: Prevent sending reports from racing with device reset · 9a327405
      由 Mika Westerberg 提交于 
      When an i2c-hid device is resumed from system sleep the driver resets
the device to be sure it is in known state. The device is expected to
issue an interrupt when reset is complete.

This reset might take few milliseconds to complete so if the HID driver
on top (hid-rmi) starts to set up the device by sending feature reports
etc. the device might not issue the reset complete interrupt anymore.

Below is what happens to touchpad on Lenovo Yoga 900 during resume from
system sleep:

  [   24.790951] i2c_hid i2c-SYNA2B29:00: i2c_hid_hwreset
  [   24.790973] i2c_hid i2c-SYNA2B29:00: i2c_hid_set_power
  [   24.790982] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=22 00 00 08
  [   24.793011] i2c_hid i2c-SYNA2B29:00: resetting...
  [   24.793016] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=22 00 00 01

Here i2c-hid sends reset command to the touchpad.

  [   24.794012] i2c_hid i2c-SYNA2B29:00: input: 06 00 01 00 00 00
  [   24.794051] i2c_hid i2c-SYNA2B29:00: i2c_hid_set_or_send_report
  [   24.794059] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command:
                 cmd=22 00 3f 03 0f 23 00 04 00 0f 01

Now hid-rmi puts the touchpad to correct mode by sending it a feature
report. This makes the touchpad not to issue reset complete interrupt.

  [   24.796092] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: waiting...

i2c-hid starts to wait for the reset interrupt to trigger which never
happens.

  [   24.798304] i2c_hid i2c-SYNA2B29:00: i2c_hid_set_or_send_report
  [   24.798313] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command:
                 cmd=25 00 17 00 09 01 42 00 2e 00 19 19 00 10 cc 06 74 04 0f
                     19 00 00 00 00 00

Yet another output report from hid-rmi driver.

  [   29.795630] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: finished.
  [   29.795637] i2c_hid i2c-SYNA2B29:00: failed to reset device.

After 5 seconds i2c-hid driver times out.

  [   29.795642] i2c_hid i2c-SYNA2B29:00: i2c_hid_set_power
  [   29.795649] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=22 00 01 08
  [   29.797576] dpm_run_callback(): i2c_hid_resume+0x0/0xb0 returns -61
  [   29.797584] PM: Device i2c-SYNA2B29:00 failed to resume: error -61

After this the touchpad does not work anymore (and also resume itself
gets slowed down because of the timeout).

Prevent sending of feature/output reports while the device is being
reset by adding a mutex which is held during that time.
Reported-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reported-by: NNish Aravamudan <nish.aravamudan@gmail.com>
Suggested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      9a327405
  7. 28 12月, 2015 7 次提交
  9. 18 12月, 2015 6 次提交
  11. 08 12月, 2015 1 次提交
  13. 03 12月, 2015 8 次提交
  15. 02 12月, 2015 4 次提交
    • B
      HID: multitouch: fix input mode switching on some Elan panels · 73e7d63e
      由 Benjamin Tissoires 提交于 
      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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      73e7d63e
    • B
      HID: lg: restrict filtering out of first interface to G29 only · 2078665a
      由 Benjamin Tissoires 提交于 
      Looks like 29fae1c8 ("HID: logitech: Add support for G29") was a little
bit aggressive and broke other devices.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=108121Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      2078665a
    • A
      USB: quirks: Apply ALWAYS_POLL to all ELAN devices · 33bd2dd0
      由 Adrien Vergé 提交于 
      All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use
this quirk for all devices from this vendor, rather than maintaining a
list of all its known product IDs.
Tested-by: NAdrien Vergé <adrienverge@gmail.com>
Signed-off-by: NAdrien Vergé <adrienverge@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33bd2dd0
    • I
      HID: usbhid: fix recursive deadlock · e470127e
      由 Ioan-Adrian Ratiu 提交于 
      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: NIoan-Adrian Ratiu <adi@adirat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      e470127e
  17. 27 11月, 2015 1 次提交
    • R
      HID: debug: improve hid_debug_event() · 92529623
      由 Rasmus Villemoes 提交于 
      The code in hid_debug_event() causes horrible code generation. First,
we do a strlen() call for every byte we copy (we're doing a store to
global memory, so gcc has no way of proving that strlen(buf) doesn't
change). Second, since both i, list->tail and HID_DEBUG_BUFSIZE have
signed type, the modulo computation has to take into account the
possibility that list->tail+i is negative, so it's not just a simple
and.

Fix the former by simply not doing strlen() at all (we have to load
buf[i] anyway, so testing it is almost free) and the latter by
changing i to unsigned. This cuts 29% (69 bytes) of the size of the
function.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      92529623
  19. 26 11月, 2015 1 次提交
  21. 23 11月, 2015 1 次提交
  23. 20 11月, 2015 5 次提交