1. 11 7月, 2016 1 次提交
  2. 08 7月, 2016 1 次提交
  3. 07 7月, 2016 3 次提交
  4. 28 6月, 2016 2 次提交
  5. 24 6月, 2016 1 次提交
  6. 23 6月, 2016 5 次提交
  7. 21 6月, 2016 1 次提交
    • G
      HID: i2c-hid: set power sleep before shutdown · d9f448e3
      Guohua Zhong 提交于
      Add i2c_hid_shutdown for i2c-hid driver to send suspend cmd & free
      irq before device shutdown.
      
      Some HW design (i.e. Umaro, a chromebook model) is that the power to
      i2c hid device won't down after device shutdown. Also the i2c-hid driver
      do not send suspend cmd to the hid i2c device and free its irq before
      shutdown.So if We touch the touchscreen or some other i2c hid device,
      the power consumtion will be go up even when the device is in shutdown
      state.
      
      Though the root cause maybe a HW issue. But it seems that it is a
      good pratice to set power sleep for i2c-hid device before shutdown.
      Signed-off-by: NGuohua Zhong <ghzhong@yifangdigital.com>
      Acked-By: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      d9f448e3
  8. 20 6月, 2016 3 次提交
  9. 18 6月, 2016 4 次提交
  10. 06 6月, 2016 1 次提交
  11. 01 6月, 2016 3 次提交
    • R
      HID: uhid: fix timeout when probe races with IO · 67f8ecc5
      Roderick Colenbrander 提交于
      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: NRoderick Colenbrander <roderick.colenbrander@sony.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      67f8ecc5
    • B
      HID: multitouch: Add MT_QUIRK_NOT_SEEN_MEANS_UP to Surface Pro 3 · a80e803a
      Benjamin Tissoires 提交于
      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 <consume.noise@gmail.com>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      a80e803a
    • O
      HID: elo: kill not flush the work · ed596a4a
      Oliver Neukum 提交于
      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: NOliver Neukum <ONeukum@suse.com>
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ed596a4a
  12. 03 5月, 2016 2 次提交
  13. 27 4月, 2016 1 次提交
    • T
      HID: usbhid: quirks for Corsair RGB keyboard & mice (K70R, K95RGB, M65RGB, K70RGB, K65RGB) · 282bf1fe
      Trent Lloyd 提交于
      These devices feature multiple interfaces/endpoints: a legacy BIOS/boot
      interface (endpoint 0x81), as well as 2 corsair-specific keyboard interfaces
      (endpoint 0x82, 0x83 IN/0x03 OUT) and an RGB LED control interface (endpoint
      0x84 IN/0x04 OUT)
      
      Because the extra 3 interfaces are not of subclass USB_INTERFACE_SUBCLASS_BOOT,
      HID_QUIRK_NOGET is not automatically set on them and a 10s timeout per-endpoint
      (30s per device) occurs initialising reports on boot.  We configure
      HID_QUIRK_NO_INIT_REPORTS for these devices.
      
      Additionally the left-side G1-G18 macro keys on the K95RGB generate output on
      the un-opened 0x82/0x83 endpoints which causes the keyboard to stop responding
      waiting for this event to be collected.  We enable HID_QUIRK_ALWAYS_POLL to
      prevent this situation from occurring.
      Signed-off-by: NTrent Lloyd <trent@lloyd.id.au>
      Tested-by: NSUGNIAUX Wilfried <wsu@ppharm2k20.net>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      282bf1fe
  14. 25 4月, 2016 2 次提交
  15. 18 4月, 2016 2 次提交
  16. 13 4月, 2016 1 次提交
  17. 07 4月, 2016 1 次提交
  18. 05 4月, 2016 2 次提交
  19. 04 4月, 2016 4 次提交