1. 27 1月, 2017 7 次提交
  2. 23 1月, 2017 3 次提交
  3. 19 1月, 2017 1 次提交
    • J
      HID: wacom: Fix sibling detection regression · a9ce7856
      Jason Gerecke 提交于
      Commit 345857bb ("HID: wacom: generic: Add support for sensor offsets") included
      a change to the operation and location of the call to 'wacom_add_shared_data'
      in 'wacom_parse_and_register'. The modifications included moving it higher up
      so that it would occur before the call to 'wacom_retrieve_hid_descriptor'. This
      was done to prevent a crash that would have occured when the report containing
      tablet offsets was fed into the driver with 'wacom_hid_report_raw_event'
      (specifically: the various 'wacom_wac_*_report' functions were written with the
      assumption that they would only be called once tablet setup had completed;
      'wacom_wac_pen_report' in particular dereferences 'shared' which wasn't yet
      allocated).
      
      Moving the call to 'wacom_add_shared_data' effectively prevented the crash but
      also broke the sibiling detection code which assumes that the HID descriptor
      has been read and the various device_type flags set.
      
      To fix this situation, we restore the original 'wacom_add_shared_data'
      operation and location and instead implement an alternative change that can
      also prevent the crash. Specifically, we notice that the report functions
      mentioned above expect to be called only for input reports.  By adding a check,
      we can prevent feature reports (such as the offset report) from
      causing trouble.
      
      Fixes: 345857bb ("HID: wacom: generic: Add support for sensor offsets")
      Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
      Tested-by: NPing Cheng <pingc@wacom.com>
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      a9ce7856
  4. 13 1月, 2017 2 次提交
  5. 12 1月, 2017 1 次提交
  6. 06 1月, 2017 1 次提交
  7. 05 1月, 2017 1 次提交
  8. 02 1月, 2017 3 次提交
  9. 19 12月, 2016 4 次提交
  10. 12 12月, 2016 3 次提交
    • B
      HID: fix missing irq field · 8cd16166
      Benjamin Tissoires 提交于
      commit ba18a931 ("Revert "HID: i2c-hid: Add support for ACPI GPIO
      interrupts"") removed the need for storing the irq in struct i2c_hid.
      
      But then commit de3c99488609 ("HID: i2c-hid: Disable IRQ before freeing
      buffers") forgot to update the location of the irq.
      
      Fix this by using the actual I2C client irq.
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      8cd16166
    • J
      HID: i2c-hid: fix build · ba1660f1
      Jiri Kosina 提交于
      Add a forgotten include that I've by mistake omitted when resolving
      merge conflict in ead0687fe30 ("HID: i2c-hid: support regulator power
      on/off").
      
      Fixes: ead0687fe30 ("HID: i2c-hid: support regulator power on/off")
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ba1660f1
    • J
      HID: i2c-hid: Disable IRQ before freeing buffers · d46ddc59
      João Paulo Rechi Vita 提交于
      The HID report buffers that are initially allocated on i2c_hid_probe()
      might not be big enough to hold the HID reports from a specific device,
      in which case they will be freed and new ones will be allocated in
      i2c_hid_start(), at point which the device's report size is known. But
      at this point ihid->irq is already running, and may call
      i2c_hid_get_input() which passes ihid->inbuf to i2c_master_recv(). Since
      this handler runs in a separate thread, ihid->inbuf may be freed at this
      very moment, and i2c_master_recv() will write on memory which may be
      already owned by a different part of the kernel, corrupting its data.
      
      This problem has been observed on an Asus UX360UA laptop which has an
      I2C touchpad, and results in a complete system freeze or an unusable
      slowness with a lof of "BUG: unable to handle kernel paging request at
      <address>" warnings. Enabling SLUB debugging shows a use-after-free
      warning on memory allocated in i2c_hid_alloc_buffers() and freed in
      i2c_hid_free_buffers():
      
      =============================================================================
      BUG kmalloc-64 (Not tainted): Poison overwritten
      -----------------------------------------------------------------------------
      Disabling lock debugging due to kernel taint
      INFO: 0xffff880264083273-0xffff88026408329e. first byte 0x0 instead of 0x6b
      INFO: Allocated in i2c_hid_alloc_buffers+0x25/0xa0 [i2c_hid] age=35793 cpu=2 pid=430
      	___slab_alloc+0x41e/0x460
      	__slab_alloc+0x20/0x40
      	__kmalloc+0x210/0x280
      	i2c_hid_alloc_buffers+0x25/0xa0 [i2c_hid]
      	i2c_hid_probe+0x12f/0x5e0 [i2c_hid]
      	i2c_device_probe+0x10a/0x1b0
      	driver_probe_device+0x220/0x4a0
      	__device_attach_driver+0x71/0xa0
      	bus_for_each_drv+0x67/0xb0
      	__device_attach+0xdc/0x170
      	device_initial_probe+0x13/0x20
      	bus_probe_device+0x92/0xa0
      	device_add+0x4aa/0x670
      	device_register+0x1a/0x20
      	i2c_new_device+0x18e/0x230
      	acpi_i2c_add_device+0x1a0/0x210
      INFO: Freed in i2c_hid_free_buffers+0x16/0x60 [i2c_hid] age=7552 cpu=1 pid=1473
      	__slab_free+0x221/0x330
      	kfree+0x139/0x160
      	i2c_hid_free_buffers+0x16/0x60 [i2c_hid]
      	i2c_hid_start+0x2a9/0x2df [i2c_hid]
      	mt_probe+0x160/0x22e [hid_multitouch]
      	hid_device_probe+0xd7/0x150 [hid]
      	driver_probe_device+0x220/0x4a0
      	__driver_attach+0x84/0x90
      	bus_for_each_dev+0x6c/0xc0
      	driver_attach+0x1e/0x20
      	bus_add_driver+0x1c3/0x280
      	driver_register+0x60/0xe0
      	__hid_register_driver+0x53/0x90 [hid]
      	0xffffffffc004f01e
      	do_one_initcall+0xb3/0x1f0
      	do_init_module+0x5f/0x1d0
      INFO: Slab 0xffffea0009902080 objects=20 used=20 fp=0x          (null) flags=0x17fff8000004080
      INFO: Object 0xffff880264083260 @offset=4704 fp=0x          (null)
      Bytes b4 ffff880264083250: 8d e6 fe ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a  ........ZZZZZZZZ
      Object ffff880264083260: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      Object ffff880264083270: 6b 6b 6b 00 00 00 00 00 00 00 00 00 00 00 00 00  kkk.............
      Object ffff880264083280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880264083290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Redzone ffff8802640832a0: bb bb bb bb bb bb bb bb                          ........
      Padding ffff8802640833e0: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ
      CPU: 1 PID: 1503 Comm: python3 Tainted: G    B           4.4.21+ #10
      Hardware name: ASUSTeK COMPUTER INC. UX360UA/UX360UA, BIOS UX360UA.200 05/05/2016
       0000000000000086 00000000622d48a2 ffff88026061ba38 ffffffff813f6044
       ffff880264082010 ffff880264083260 ffff88026061ba78 ffffffff811e8eab
       0000000000000008 ffff880200000001 ffff88026408329f ffff88026a007700
      Call Trace:
       [<ffffffff813f6044>] dump_stack+0x63/0x8f
       [<ffffffff811e8eab>] print_trailer+0x14b/0x1f0
       [<ffffffff811e94c1>] check_bytes_and_report+0xc1/0x100
       [<ffffffff811e96c4>] check_object+0x1c4/0x240
       [<ffffffff81293fde>] ? ext4_htree_store_dirent+0x3e/0x120
       [<ffffffff811e9b44>] alloc_debug_processing+0x104/0x180
       [<ffffffff811eb7be>] ___slab_alloc+0x41e/0x460
       [<ffffffff81293fde>] ? ext4_htree_store_dirent+0x3e/0x120
       [<ffffffff8124590b>] ? __getblk_gfp+0x2b/0x60
       [<ffffffff8129b969>] ? ext4_getblk+0xa9/0x190
       [<ffffffff811eb820>] __slab_alloc+0x20/0x40
       [<ffffffff811ed320>] __kmalloc+0x210/0x280
       [<ffffffff81293fde>] ? ext4_htree_store_dirent+0x3e/0x120
       [<ffffffff812c1602>] ? ext4fs_dirhash+0xc2/0x2a0
       [<ffffffff81293fde>] ext4_htree_store_dirent+0x3e/0x120
       [<ffffffff812a4f47>] htree_dirblock_to_tree+0x187/0x1b0
       [<ffffffff812a5fd2>] ext4_htree_fill_tree+0xb2/0x2e0
       [<ffffffff811ebb7a>] ? kmem_cache_alloc_trace+0x1fa/0x220
       [<ffffffff81293e45>] ? ext4_readdir+0x775/0x8b0
       [<ffffffff81293cb1>] ext4_readdir+0x5e1/0x8b0
       [<ffffffff81221c82>] iterate_dir+0x92/0x120
       [<ffffffff81222118>] SyS_getdents+0x98/0x110
       [<ffffffff81221d10>] ? iterate_dir+0x120/0x120
       [<ffffffff818157f2>] entry_SYSCALL_64_fastpath+0x16/0x71
      FIX kmalloc-64: Restoring 0xffff880264083273-0xffff88026408329e=0x6b
      FIX kmalloc-64: Marking all objects used
      Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      d46ddc59
  11. 09 12月, 2016 5 次提交
  12. 02 12月, 2016 1 次提交
  13. 30 11月, 2016 1 次提交
  14. 29 11月, 2016 3 次提交
  15. 28 11月, 2016 4 次提交
    • R
      HID: sony: Comply to Linux gamepad spec for DS4 · 9131f8cc
      Roderick Colenbrander 提交于
      The DS4 side of hid-sony used the hid-core layer to assign buttons
      and axes based on the HID report descriptors. The default mapping
      was strange e.g. right stick using ABS_Z/ABS_RZ or the physical
      'south button' being reported as BTN_EAST etcetera.
      
      This patch makes the DS4 side ofi the hid-sony driver comply to
      the Linux game controller spec as suggested in a discussion with
      Dmitry on the linux-input list.
      
      Currently the main user of the DS4 is the SDL2 library, which has
      a mapping table using vendor/device/version as a key. In order to
      not break SDL2 we discussed adjusting the version number, so it
      can have both mappings. This was discust on linux-input and we
      discussed privately with SDL2 developers.
      Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      9131f8cc
    • R
      HID: sony: Make the DS4 touchpad a separate device · ac797b95
      Roderick Colenbrander 提交于
      The dualshock 4 supports both analog sticks of which one uses
      ABS_X/_Y and a touchpad. In a recent discussion with Dmitry about
      some input-mt changes we proposed for disabling pointer emulation from
      input_mt_sync_frame, Dmitry mentioned ABS_X/_Y should report the
      same data as ABS_MT_POSITION_X/_Y. The current driver is mixing axes
      for different subdevices. It was suggested to make the touchpad
      its own sub-device.
      
      This patch turns the touchpad into its own device. In addition
      this patch also moves the button underneath the touchpad into
      the new device. It felt like this button should be part of the
      device. No known user space application (not even SDL2) seems to
      be using it.
      Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ac797b95
    • R
      HID: sony: Fix memory issue when connecting device using both Bluetooth and USB · 4f967f6d
      Roderick Colenbrander 提交于
      A previous patch moved most input initialization from sony_probe to
      sony_input_configured to avoid some race conditions. The driver has some
      special logic to prevent the device to get registered twice in case the
      user connects it both over Bluetooth and USB. When this condition
      happens sony_input_configured returns a failure, but sony_probe continues
      as hid_hw_start doesn't fail. As was discussed on linux-input, it is
      acceptable for this function to fail.
      
      This patch adds a check for the HID_CLAIMED_INPUT flag within sony_probe
      to determine whether initialization succeeded correctly. The flag is
      not set by the HID layer when sony_input_configured fails.
      Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      4f967f6d
    • B
      HID: cp2112: add IRQ chip handling · 13de9cca
      Benjamin Tissoires 提交于
      The GPIO part doesn't provide interrupts when GPIO are toggled.
      So use a polling mechanism if someone requests a GPIO as an IRQ.
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      13de9cca