Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 02 12月, 2014 1 次提交
  3. 20 11月, 2014 1 次提交
  5. 11 11月, 2014 1 次提交
  7. 03 11月, 2014 1 次提交
  9. 29 10月, 2014 1 次提交
    • B
      HID: usbhid: prevent unwanted events to be sent when re-opening the device · b905811a
      由 Benjamin Tissoires 提交于 
      When events occurs while no one is listening to the node (hid->open == 0
and usb_kill_urb() called) some events are still stacked somewhere in
the USB (kernel or device?) stack. When the node gets reopened, these
events are drained, and this results in spurious touch down/up, or mouse
button clicks.

The problem was spotted with touchscreens in fdo bug #81781 [1], but it
actually occurs with any mouse using hid-generic or touchscreen.

A way to reproduce it is to call:

$ xinput disable 9 ; sleep 5 ; xinput enable 9

With 9 being the device ID for the touchscreen/mouse. During the "sleep",
produce some touch events or click events. When "xinput enable" is called,
at least one click is generated.

This patch tries to fix this by draining the queue for 50 msec and
during this time frame, not forwarding these old events to the hid layer.

Hans completed the explanation:
"""
Devices like mice (basically any hid device) will have a fifo
on the device side, when we stop submitting urbs to get hid reports from
it, that fifo will fill up, and when we resume we will get whatever
is there in that fifo.
"""

[1] https://bugs.freedesktop.org/show_bug.cgi?id=81781Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      b905811a
  11. 10 10月, 2014 2 次提交
  13. 01 10月, 2014 1 次提交
  15. 08 9月, 2014 3 次提交
  17. 04 9月, 2014 1 次提交
    • A
      HID: usbhid: improve handling of Clear-Halt and reset · 8f507ef5
      由 Alan Stern 提交于 
      This patch changes the way usbhid carries out Clear-Halt and reset.

Currently, after a Clear-Halt on the interrupt-IN endpoint, the driver
immediately restarts the interrupt URB, even if the Clear-Halt failed.
This doesn't work out well when the reason for the failure was that
the device was disconnected (when a low- or full-speed device is
connected through a hub to an EHCI controller, transfer errors caused
by disconnection are reported as stalls by the hub).  Instead now the
driver will attempt a reset after a failed Clear-Halt.

The way resets are carried out is also changed.  Now the driver will
call usb_queue_reset_device() instead of calling usb_reset_device()
directly.  This avoids a deadlock that would arise when a device is
unplugged: The hid_reset() routine runs as a workqueue item, a reset
attempt after the device has been unplugged will fail, failure will
cause usbhid to be unbound, and the disconnect routine will try to do
cancel_work_sync().  The usb_queue_reset_device() implementation is
carefully written to handle scenarios like this one properly.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      8f507ef5
  19. 29 7月, 2014 3 次提交
    • R
      HID: usbhid: Use flag HID_DISCONNECTED when a usb device is removed · 46df9ded
      由 Reyad Attiyat 提交于 
      Set disconnected flag in struct usbhid when a usb device is removed. Check for
disconnected flag before sending urb requests. This prevents a kernel panic
when a hid driver calls hid_hw_request() after removing a usb device.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
 IP: [<ffffffff8161746f>] hid_submit_ctrl+0x7f/0x290
 PGD 0
 Oops: 0002 [#1] PREEMPT SMP
 CPU: 2 PID: 39 Comm: khubd Tainted: G          IO  3.16.0-rc5+ #112
 Hardware name: Microsoft Corporation Surface Pro 2/Surface Pro 2, BIOS 2.03.0250 09/06/2013
 task: ffff880118aba6e0 ti: ffff8800daf80000 task.ti: ffff8800daf80000
 RIP: 0010:[<ffffffff8161746f>]  [<ffffffff8161746f>] hid_submit_ctrl+0x7f/0x290
 RSP: 0018:ffff8800daf83750  EFLAGS: 00010086
 RAX: 0000000080000300 RBX: ffff88003f60c000 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff880117f78000
 RBP: ffff8800daf83788 R08: 0000000000000001 R09: 0000000000000001
 R10: 0000000000000001 R11: 0000000000000000 R12: ffff880117f78000
 R13: ffff88003f11a290 R14: 000000000000000c R15: ffff880091cb3ab8
 FS:  0000000000000000(0000) GS:ffff88011b000000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000058 CR3: 0000000001c11000 CR4: 00000000001407e0
 Stack:
  ffff880117f3dcd0 ffff880117f78000 ffff88003f60c000 ffff880117f78000
  ffff880117f78000 ffff88003f11a290 0000000000000000 ffff8800daf837b0
  ffffffff81617707 ffff880117f78000 ffff88003f60c000 0000000000000013
 Call Trace:
  [<ffffffff81617707>] usbhid_restart_ctrl_queue+0x87/0x140
  [<ffffffff81617a88>] usbhid_submit_report+0x2c8/0x370
  [<ffffffff81617b4a>] usbhid_request+0x1a/0x30
  [<ffffffffa020edfb>] sensor_hub_set_feature+0x8b/0xd0 [hid_sensor_hub]
  [<ffffffffa02d9084>] hid_sensor_power_state+0x84/0x110 [hid_sensor_trigger]
  [<ffffffffa02d9129>] hid_sensor_data_rdy_trigger_set_state+0x19/0x20 [hid_sensor_trigger]
  [<ffffffffa034d5b7>] iio_triggered_buffer_predisable+0xa7/0xb0 [industrialio]
  [<ffffffffa034cc4a>] iio_disable_all_buffers+0x3a/0xc0 [industrialio]
  [<ffffffffa03487d3>] iio_device_unregister+0x53/0x80 [industrialio]
  [<ffffffffa026c06a>] hid_accel_3d_remove+0x2a/0x50 [hid_sensor_accel_3d]
  [<ffffffff814f433d>] platform_drv_remove+0x1d/0x40
  [<ffffffff814f18bf>] __device_release_driver+0x7f/0xf0
  [<ffffffff814f1955>] device_release_driver+0x25/0x40
  [<ffffffff814f121c>] bus_remove_device+0x11c/0x1a0
  [<ffffffff814ed7d6>] device_del+0x136/0x1e0
  [<ffffffff81512190>] ? mfd_cell_disable+0x80/0x80
  [<ffffffff814f41d1>] platform_device_del+0x21/0xc0
  [<ffffffff814f4282>] platform_device_unregister+0x12/0x30
  [<ffffffff815121d3>] mfd_remove_devices_fn+0x43/0x50
  [<ffffffff814ed3e3>] device_for_each_child+0x43/0x70
  [<ffffffff81512105>] mfd_remove_devices+0x25/0x30
  [<ffffffffa020ebd7>] sensor_hub_remove+0x87/0x140 [hid_sensor_hub]
  [<ffffffff81607c5b>] hid_device_remove+0x6b/0xd0
  [<ffffffff814f18bf>] __device_release_driver+0x7f/0xf0
  [<ffffffff814f1955>] device_release_driver+0x25/0x40
  [<ffffffff814f121c>] bus_remove_device+0x11c/0x1a0
  [<ffffffff814ed7d6>] device_del+0x136/0x1e0
  [<ffffffff81607d47>] hid_destroy_device+0x27/0x60
  [<ffffffff81616972>] usbhid_disconnect+0x22/0x50
  [<ffffffff81568597>] usb_unbind_interface+0x77/0x2b0
  [<ffffffff814f18bf>] __device_release_driver+0x7f/0xf0
  [<ffffffff814f1955>] device_release_driver+0x25/0x40
  [<ffffffff814f121c>] bus_remove_device+0x11c/0x1a0
  [<ffffffff814ed7d6>] device_del+0x136/0x1e0
  [<ffffffff81565cd1>] usb_disable_device+0x91/0x2a0
  [<ffffffff8155b046>] usb_disconnect+0x96/0x2e0
  [<ffffffff8155d74a>] hub_thread+0xb5a/0x1840
Signed-off-by: NReyad Attiyat <reyad.attiyat@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      46df9ded
    • W
      HID: use multi input quirk for 22b9:2968 · d90b1cf0
      由 Wen-chien Jesse Sung 提交于 
      This device generates ABS_Z and ABS_RX events instead of ABS_X and
ABS_Y.
Signed-off-by: NWen-chien Jesse Sung <jesse.sung@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      d90b1cf0
    • W
      HID: add quirk for 0x04d9:0xa096 device · 30c6fd42
      由 Wangzhao Cai 提交于 
      I am using a USB keyborad that give me "usb_submit_urb(ctrl) failed: -1" error
when I plugin it.  and I need to wait for 10s for this device to be ready.

By adding this quirks, the usb keyborad is usable right after plugin
Signed-off-by: NWangzhao Cai <microcaicai@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      30c6fd42
  21. 07 7月, 2014 1 次提交
  23. 01 7月, 2014 1 次提交
  25. 27 6月, 2014 1 次提交
  27. 10 6月, 2014 1 次提交
  29. 02 6月, 2014 1 次提交
  31. 05 5月, 2014 1 次提交
  33. 14 3月, 2014 2 次提交
  35. 17 2月, 2014 3 次提交
  37. 29 1月, 2014 1 次提交
  39. 28 1月, 2014 1 次提交
  41. 13 12月, 2013 1 次提交
  43. 02 12月, 2013 3 次提交
  45. 19 11月, 2013 1 次提交
  47. 25 10月, 2013 1 次提交
  49. 09 10月, 2013 2 次提交
  51. 02 9月, 2013 1 次提交
  53. 27 8月, 2013 1 次提交
  55. 31 7月, 2013 2 次提交
    • D
      HID: usbhid: use generic hidinput_input_event() · bfde79cb
      由 David Herrmann 提交于 
      HID core provides the same functionality as we do, so drop the custom
hidinput_input_event() handler.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      bfde79cb
    • D
      HID: usbhid: update LED fields unlocked · 60682284
      由 David Herrmann 提交于 
      Report fields can be updated from HID drivers unlocked via
hid_set_field(). It is protected by input_lock in HID core so only a
single input event is handled at a time. USBHID can thus update the field
unlocked and doesn't conflict with any HID vendor/device drivers. Note,
many HID drivers make heavy use of hid_set_field() in that way.

But usbhid also schedules a work to gather multiple LED changes in a
single report. Hence, we used to lock the LED field update so the work can
read a consistent state. However, hid_set_field() only writes a single
integer field, which is guaranteed to be allocated all the time. So the
worst possible race-condition is a garbage read on the LED field.

Therefore, there is no need to protect the update. In fact, the only thing
that is prevented by locking hid_set_field(), is an LED update while the
scheduled work currently writes an older LED update out. However, this
means, a new work is scheduled directly when the old one is done writing
the new state to the device. So we actually _win_ by not protecting the
write and allowing the write to be combined with the current write. A new
worker is still scheduled, but will not write any new state. So the LED
will not blink unnecessarily on the device.

Assume we have the LED set to 0. Two request come in which enable the LED
and immediately disable it. The current situation with two CPUs would be:

  usb_hidinput_input_event()       |      hid_led()
  ---------------------------------+----------------------------------
    spin_lock(&usbhid->lock);
    hid_set_field(1);
    spin_unlock(&usbhid->lock);
    schedule_work(...);
                                      spin_lock(&usbhid->lock);
                                      __usbhid_submit_report(..1..);
                                      spin_unlock(&usbhid->lock);
    spin_lock(&usbhid->lock);
    hid_set_field(0);
    spin_unlock(&usbhid->lock);
    schedule_work(...);
                                      spin_lock(&usbhid->lock);
                                      __usbhid_submit_report(..0..);
                                      spin_unlock(&usbhid->lock);

With the locking removed, we _might_ end up with (look at the changed
__usbhid_submit_report() parameters in the first try!):

  usb_hidinput_input_event()       |      hid_led()
  ---------------------------------+----------------------------------
    hid_set_field(1);
    schedule_work(...);
                                      spin_lock(&usbhid->lock);
    hid_set_field(0);
    schedule_work(...);
                                      __usbhid_submit_report(..0..);
                                      spin_unlock(&usbhid->lock);

                                      ... next work ...

                                      spin_lock(&usbhid->lock);
                                      __usbhid_submit_report(..0..);
                                      spin_unlock(&usbhid->lock);

As one can see, we no longer send the "LED ON" signal as it is disabled
immediately afterwards and the following "LED OFF" request overwrites the
pending "LED ON".

It is important to note that hid_set_field() is not atomic, so we might
also end up with any other value. But that doesn't matter either as we
_always_ schedule the next work with a correct value and schedule_work()
acts as memory barrier, anyways. So in the worst case, we run
__usbhid_submit_report(..<garbage>..) in the first case and the following
__usbhid_submit_report() will write the correct value. But LED states are
booleans so any garbage will be converted to either 0 or 1 and the remote
device will never see invalid requests.

Why all this? It avoids any custom locking around hid_set_field() in
usbhid and finally allows us to provide a generic hidinput_input_event()
handler for all HID transport drivers.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      60682284