1. 25 4月, 2014 4 次提交
  2. 07 4月, 2014 2 次提交
    • B
      HID: core: do not scan constant input report · e24d0d39
      Benjamin Tissoires 提交于
      The Microsoft Surface Type/Touch Cover 2 is a fancy device which advertised
      itself as a multitouch device but with constant input reports.
      This way, hid_scan_report() gives the group MULTITOUCH to it, but
      hid-multitouch can not handle it due to the constant collection ignored
      by hid-input.
      
      To prevent such crap in the future, and while we do not fix this particular
      device, make the scan_report coherent with hid-input.c, and ignore constant
      input reports.
      
      CC: stable@vger.kernel.org # 3.12+
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      e24d0d39
    • D
      Revert "HID: microsoft: Add ID's for Surface Type/Touch Cover 2" · f3b0cbce
      Derya 提交于
      This reverts commit 117309c5.
      
      The MS Surface Pro 2 has an USB composite device with 3 interfaces
      - interface 0 - sensor hub
      - interface 1 - wacom digitizer
      - interface 2 - the keyboard cover, if one is attached
      This USB composite device changes it product id dependent on if and which
      keyboard cover is attached. Adding the covers to hid_have_special_driver
      prevents loading the right hid drivers for the other two interfaces, all 3
      get loaded with hid-microsoft. We don't even need hid-microsoft for the
      keyboards. We have to revert this to load the right hid modules for each
      interface.
      
      CC: stable@vger.kernel.org # kernel 3.14 only
      Signed-off-by: NDerya <derya.kiran@yahoo.de>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f3b0cbce
  3. 04 4月, 2014 1 次提交
  4. 03 4月, 2014 1 次提交
  5. 02 4月, 2014 4 次提交
  6. 29 3月, 2014 2 次提交
  7. 25 3月, 2014 1 次提交
    • S
      HID: hid-sensor-hub: fix sleeping function called from invalid context · f74346a0
      Srinivas Pandruvada 提交于
      Fix issue with the sleeping calling hid_hw_request under spinlock.
      When i2c is used as HID transport, this is calling kmalloc, which
      can sleep. So remove call to this function while under spinlock.
       [ 1067.021961] Call Trace:
       [ 1067.021970]  [<ffffffff8192f5f2>] dump_stack+0x4d/0x6f
       [ 1067.021976]  [<ffffffff811109f2>] __might_sleep+0xd2/0xf0
       [ 1067.021981]  [<ffffffff811ea15b>] __kmalloc+0xeb/0x200
       [ 1067.021989]  [<ffffffff816e0cb3>] ? hid_alloc_report_buf+0x23/0x30
       [ 1067.021993]  [<ffffffff816e0cb3>] hid_alloc_report_buf+0x23/0x30
       [ 1067.021997]  [<ffffffff816f4cb7>] i2c_hid_request+0x57/0x110
       [ 1067.022006]  [<ffffffffa02bc61c>] sensor_hub_input_attr_get_raw_value+0xbc/0x100 [hid_sensor_hub]
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f74346a0
  8. 20 3月, 2014 1 次提交
  9. 14 3月, 2014 5 次提交
  10. 12 3月, 2014 1 次提交
  11. 05 3月, 2014 3 次提交
    • B
      HID: multitouch: add support of other generic collections in hid-mt · 6aef704e
      Benjamin Tissoires 提交于
      The ANTON Touch Pad is a device which can switch from a multitouch
      touchpad to a mouse. It thus presents several generic collections which
      are currently ignored by hid-multitouch. Enable them by not ignoring
      them in mt_input_mapping.
      Adding also a suffix for them depending on their application.
      Reported-by: NEdel Maks <edelmaks@gmail.com>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      6aef704e
    • B
      HID: multitouch: remove pen special handling · e55f6200
      Benjamin Tissoires 提交于
      Pens have a special handling in hid-mt as hybrid pen/touch devices
      are quite common now. However, some fancy devices presents also
      useful collections like mouse or keyboard.
      The special case for the pen may not be a special case, and treat it as
      a generic case.
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      e55f6200
    • B
      HID: multitouch: remove registered devices with default behavior · 0fa9c616
      Benjamin Tissoires 提交于
      The default multitouch protocol class in use since the kernel v3.9 is
      working quite well. Since its inclusion, the only devices we had to tweak
      were those who really need quirks (GeneralTouch, FocalTech and Wistron,
      the 3 of them are Win 7 certified ones).
      The flow of new unhandled devices has stopped, which is great and I think
      it's time to reduce the list of registered device.
      
      This commit removes only the registration in the kernel of devices that
      use the class MT_CLS_DEFAULT, or that can use it. By that, I mean that I
      checked all the recordings I have, and the produced input device and
      events are the same before and after applying the patch.
      
      This gives two benefits:
      - remove a bunch of lines of codes
      - prevent bad handling of existing registered devices which are using a
      different protocol while using the same VID/PID (I got the case of a
      Quanta 3008 recently).
      
      I also removed the associated classes (MT_CLS*). I kept their #define in
      case people use the new_id sysfs node with a non standard class (their
      should be really few people now, but we never now). This is why there
      are /* reserved .... */.
      
      Last, I add a comment on top of mt_devices[] definition to remember people
      (and myself) not to include devices for the beauty of it.
      
      To people still trying to add devices with the default class:
      """
      Guys, try out your device under a kernel greater or equal to v3.9. If it
      works, you are all set. Adding your VID/PID to the kernel only brings us
      overload and you won't get anything from it _because_ even a backport of
      this shiny patch will _not_ make the device work under 3.0, 3.2, 3.4 or
      even 3.8.
      So if it works, it works.
      If it does not work, then yes, submit a patch or call for help.
      In any cases, if you want me to do regression tests, I'd be happy to
      get some traces of your device. But I won't patch the kernel if it works.
      """
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      0fa9c616
  12. 26 2月, 2014 1 次提交
    • F
      HID: hidraw: fix warning destroying hidraw device files after parent · 47587fc0
      Fernando Luis Vázquez Cao 提交于
      I noticed that after hot unplugging a Logitech unifying receiver
      (drivers/hid/hid-logitech-dj.c) the kernel would occasionally spew a
      stack trace similar to this:
      
      usb 1-1.1.2: USB disconnect, device number 7
      WARNING: CPU: 0 PID: 2865 at fs/sysfs/group.c:216 device_del+0x40/0x1b0()
      sysfs group ffffffff8187fa20 not found for kobject 'hidraw0'
      [...]
      CPU: 0 PID: 2865 Comm: upowerd Tainted: G        W 3.14.0-rc4 #7
      Hardware name: LENOVO 7783PN4/        , BIOS 9HKT43AUS 07/11/2011
       0000000000000009 ffffffff814cd684 ffff880427ccfdf8 ffffffff810616e7
       ffff88041ec61800 ffff880427ccfe48 ffff88041e444d80 ffff880426fab8e8
       ffff880429359960 ffffffff8106174c ffffffff81714b98 0000000000000028
      Call Trace:
       [<ffffffff814cd684>] ? dump_stack+0x41/0x51
       [<ffffffff810616e7>] ? warn_slowpath_common+0x77/0x90
       [<ffffffff8106174c>] ? warn_slowpath_fmt+0x4c/0x50
       [<ffffffff81374fd0>] ? device_del+0x40/0x1b0
       [<ffffffff8137516f>] ? device_unregister+0x2f/0x50
       [<ffffffff813751fa>] ? device_destroy+0x3a/0x40
       [<ffffffffa03ca245>] ? drop_ref+0x55/0x120 [hid]
       [<ffffffffa03ca3e6>] ? hidraw_release+0x96/0xb0 [hid]
       [<ffffffff811929da>] ? __fput+0xca/0x210
       [<ffffffff8107fe17>] ? task_work_run+0x97/0xd0
       [<ffffffff810139a9>] ? do_notify_resume+0x69/0xa0
       [<ffffffff814dbd22>] ? int_signal+0x12/0x17
      ---[ end trace 63f4a46f6566d737 ]---
      
      During device removal hid_disconnect() is called via hid_hw_stop() to
      stop the device and free all its resources, including the sysfs
      files. The problem is that if a user space process, such as upowerd,
      holds a reference to a hidraw file the corresponding sysfs files will
      be kept around (drop_ref() does not call device_destroy() if the open
      counter is not 0) and it will be usb_disconnect() who, by calling
      device_del() for the USB device, will indirectly remove the sysfs
      files of the hidraw device (sysfs_remove_dir() is recursive these
      days). Because of this, by the time user space releases the last
      reference to the hidraw file and drop_ref() tries to destroy the
      device the sysfs files are already gone and the kernel will print
      the warning above.
      
      Fix this by calling device_destroy() at USB disconnect time.
      Signed-off-by: NFernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Cc: stable@vger.kernel.org	# 3.13
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      47587fc0
  13. 25 2月, 2014 7 次提交
  14. 20 2月, 2014 2 次提交
  15. 18 2月, 2014 5 次提交