1. 22 5月, 2015 1 次提交
  2. 04 5月, 2015 3 次提交
  3. 27 4月, 2015 1 次提交
  4. 23 4月, 2015 2 次提交
  5. 02 4月, 2015 1 次提交
  6. 17 3月, 2015 1 次提交
    • B
      HID: wacom: ask for a in-prox report when it was missed · 5fcad167
      Benjamin Tissoires 提交于
      If noone listens to the input device when a tool comes in proximity,
      the tablet does not send the in-prox event when a client becomes available.
      That means that no events will be sent until the tool is taken out of
      proximity.
      
      In this situation, ask for the report WACOM_REPORT_INTUOSREAD which will
      read the corresponding feature and generate an in-prox event.
      To make some generation of hardware working, we need to unset the
      quirk NO_GET set by hid-core because the interfaces are seen as "boot
      mouse".
      
      We don't schedule this read in a worker while we are in an IO interrupt.
      We know that usbhid will do it asynchronously. If this is triggered by
      uhid, then this is obviously a client side bug :)
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Acked-by: NJason Gerecke <killertofu@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      5fcad167
  7. 14 3月, 2015 2 次提交
    • K
      power_supply: Change ownership from driver to core · 297d716f
      Krzysztof Kozlowski 提交于
      Change the ownership of power_supply structure from each driver
      implementing the class to the power supply core.
      
      The patch changes power_supply_register() function thus all drivers
      implementing power supply class are adjusted.
      
      Each driver provides the implementation of power supply. However it
      should not be the owner of power supply class instance because it is
      exposed by core to other subsystems with power_supply_get_by_name().
      These other subsystems have no knowledge when the driver will unregister
      the power supply. This leads to several issues when driver is unbound -
      mostly because user of power supply accesses freed memory.
      
      Instead let the core own the instance of struct 'power_supply'.  Other
      users of this power supply will still access valid memory because it
      will be freed when device reference count reaches 0. Currently this
      means "it will leak" but power_supply_put() call in next patches will
      solve it.
      
      This solves invalid memory references in following race condition
      scenario:
      
      Thread 1: charger manager
      Thread 2: power supply driver, used by charger manager
      
      THREAD 1 (charger manager)         THREAD 2 (power supply driver)
      ==========================         ==============================
      psy = power_supply_get_by_name()
                                         Driver unbind, .remove
                                           power_supply_unregister()
                                           Device fully removed
      psy->get_property()
      
      The 'get_property' call is executed in invalid context because the driver was
      unbound and struct 'power_supply' memory was freed.
      
      This could be observed easily with charger manager driver (here compiled
      with max17040 fuel gauge):
      
      $ cat /sys/devices/virtual/power_supply/cm-battery/capacity &
      $ echo "1-0036" > /sys/bus/i2c/drivers/max17040/unbind
      [   55.725123] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [   55.732584] pgd = d98d4000
      [   55.734060] [00000000] *pgd=5afa2831, *pte=00000000, *ppte=00000000
      [   55.740318] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
      [   55.746210] Modules linked in:
      [   55.749259] CPU: 1 PID: 2936 Comm: cat Tainted: G        W       3.19.0-rc1-next-20141226-00048-gf79f475f3c44-dirty #1496
      [   55.760190] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      [   55.766270] task: d9b76f00 ti: daf54000 task.ti: daf54000
      [   55.771647] PC is at 0x0
      [   55.774182] LR is at charger_get_property+0x2f4/0x36c
      [   55.779201] pc : [<00000000>]    lr : [<c034b0b4>]    psr: 60000013
      [   55.779201] sp : daf55e90  ip : 00000003  fp : 00000000
      [   55.790657] r10: 00000000  r9 : c06e2878  r8 : d9b26c68
      [   55.795865] r7 : dad81610  r6 : daec7410  r5 : daf55ebc  r4 : 00000000
      [   55.802367] r3 : 00000000  r2 : daf55ebc  r1 : 0000002a  r0 : d9b26c68
      [   55.808879] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      [   55.815994] Control: 10c5387d  Table: 598d406a  DAC: 00000015
      [   55.821723] Process cat (pid: 2936, stack limit = 0xdaf54210)
      [   55.827451] Stack: (0xdaf55e90 to 0xdaf56000)
      [   55.831795] 5e80:                                     60000013 c01459c4 0000002a c06f8ef8
      [   55.839956] 5ea0: db651000 c06f8ef8 daebac00 c04cb668 daebac08 c0346864 00000000 c01459c4
      [   55.848115] 5ec0: d99eaa80 c06f8ef8 00000fff 00001000 db651000 c027f25c c027f240 d99eaa80
      [   55.856274] 5ee0: d9a06c00 c0146218 daf55f18 00001000 d99eaa80 db4c18c0 00000001 00000001
      [   55.864468] 5f00: daf55f80 c0144c78 c0144c54 c0107f90 00015000 d99eaab0 00000000 00000000
      [   55.872603] 5f20: 000051c7 00000000 db4c18c0 c04a9370 00015000 00001000 daf55f80 00001000
      [   55.880763] 5f40: daf54000 00015000 00000000 c00e53dc db4c18c0 c00e548c 0000000d 00008124
      [   55.888937] 5f60: 00000001 00000000 00000000 db4c18c0 db4c18c0 00001000 00015000 c00e5550
      [   55.897099] 5f80: 00000000 00000000 00001000 00001000 00015000 00000003 00000003 c000f364
      [   55.905239] 5fa0: 00000000 c000f1a0 00001000 00015000 00000003 00015000 00001000 0001333c
      [   55.913399] 5fc0: 00001000 00015000 00000003 00000003 00000002 00000000 00000000 00000000
      [   55.921560] 5fe0: 7fffe000 be999850 0000a225 b6f3c19c 60000010 00000003 00000000 00000000
      [   55.929744] [<c034b0b4>] (charger_get_property) from [<c0346864>] (power_supply_show_property+0x48/0x20c)
      [   55.939286] [<c0346864>] (power_supply_show_property) from [<c027f25c>] (dev_attr_show+0x1c/0x48)
      [   55.948130] [<c027f25c>] (dev_attr_show) from [<c0146218>] (sysfs_kf_seq_show+0x84/0x104)
      [   55.956298] [<c0146218>] (sysfs_kf_seq_show) from [<c0144c78>] (kernfs_seq_show+0x24/0x28)
      [   55.964536] [<c0144c78>] (kernfs_seq_show) from [<c0107f90>] (seq_read+0x1b0/0x484)
      [   55.972172] [<c0107f90>] (seq_read) from [<c00e53dc>] (__vfs_read+0x18/0x4c)
      [   55.979188] [<c00e53dc>] (__vfs_read) from [<c00e548c>] (vfs_read+0x7c/0x100)
      [   55.986304] [<c00e548c>] (vfs_read) from [<c00e5550>] (SyS_read+0x40/0x8c)
      [   55.993164] [<c00e5550>] (SyS_read) from [<c000f1a0>] (ret_fast_syscall+0x0/0x48)
      [   56.000626] Code: bad PC value
      [   56.011652] ---[ end trace 7b64343fbdae8ef1 ]---
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      
      [for the nvec part]
      Reviewed-by: NMarc Dietrich <marvin24@gmx.de>
      
      [for compal-laptop.c]
      Acked-by: NDarren Hart <dvhart@linux.intel.com>
      
      [for the mfd part]
      Acked-by: NLee Jones <lee.jones@linaro.org>
      
      [for the hid part]
      Acked-by: NJiri Kosina <jkosina@suse.cz>
      
      [for the acpi part]
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      297d716f
    • K
      power_supply: Move run-time configuration to separate structure · 2dc9215d
      Krzysztof Kozlowski 提交于
      Add new structure 'power_supply_config' for holding run-time
      initialization data like of_node, supplies and private driver data.
      
      The power_supply_register() function is changed so all power supply
      drivers need updating.
      
      When registering the power supply this new 'power_supply_config' should be
      used instead of directly initializing 'struct power_supply'. This allows
      changing the ownership of power_supply structure from driver to the
      power supply core in next patches.
      
      When a driver does not use of_node or supplies then it should use NULL
      as config. If driver uses of_node or supplies then it should allocate
      config on stack and initialize it with proper values.
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      
      [for the nvec part]
      Reviewed-by: NMarc Dietrich <marvin24@gmx.de>
      
      [for drivers/platform/x86/compal-laptop.c]
      Reviewed-by: NDarren Hart <dvhart@linux.intel.com>
      
      [for drivers/hid/*]
      Reviewed-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      2dc9215d
  8. 12 3月, 2015 1 次提交
    • J
      HID: wacom: Add battery presence indicator to wireless tablets · 71fa641e
      Jason Gerecke 提交于
      Declare the POWER_SUPPLY_PROP_PRESENT property to provide userspace
      with a way to determine if the battery on a wireless tablet is plugged
      in. Although current wireless tablets do not explicitly report this
      information, it can be inferred from other state information. In
      particular, a battery is assumed to be present if any of the following
      are true: a non-zero battery level reported, the battery is reported as
      charging, or the tablet is operating wirelessly.
      
      Note: The last condition above may not strictly hold for the Graphire
      Wireless (it charges from a DC barrel jack instead of a USB port), but I
      do not know what is reported in the no-battery condition.
      Signed-off-by: NJason Gerecke <killertofu@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      71fa641e
  9. 11 3月, 2015 2 次提交
  10. 27 2月, 2015 2 次提交
  11. 29 1月, 2015 1 次提交
  12. 06 1月, 2015 1 次提交
  13. 10 12月, 2014 1 次提交
  14. 02 12月, 2014 2 次提交
    • B
      HID: wacom: fix freeze on open when autosuspend is on · dff67416
      Benjamin Tissoires 提交于
      Since the conversion from USB to HID (in v3.17), some people reported a
      freeze on boot with the wacom driver. Hans managed to get a stacktrace:
      
      [  240.272331] Call Trace:
      [  240.272338]  [<ffffffff813de7b9>] ? usb_hcd_submit_urb+0xa9/0xb10
      [  240.272347]  [<ffffffff81555579>] schedule+0x29/0x70
      [  240.272355]  [<ffffffff815559e6>] schedule_preempt_disabled+0x16/0x20
      [  240.272363]  [<ffffffff81557365>] __mutex_lock_slowpath+0xe5/0x230
      [  240.272372]  [<ffffffff815574c7>] mutex_lock+0x17/0x30
      [  240.272380]  [<ffffffffa063c1d2>] wacom_resume+0x22/0x50 [wacom]
      [  240.272396]  [<ffffffffa01aea8a>] hid_resume_common+0xba/0x110 [usbhid]
      [  240.272404]  [<ffffffff813e5890>] ? usb_runtime_suspend+0x80/0x80
      [  240.272417]  [<ffffffffa01aeb1d>] hid_resume+0x3d/0x70 [usbhid]
      [  240.272425]  [<ffffffff813e44a6>] usb_resume_interface.isra.6+0xb6/0x120
      [  240.272432]  [<ffffffff813e4774>] usb_resume_both+0x74/0x140
      [  240.272439]  [<ffffffff813e58aa>] usb_runtime_resume+0x1a/0x20
      [  240.272446]  [<ffffffff813b1912>] __rpm_callback+0x32/0x70
      [  240.272453]  [<ffffffff813b1976>] rpm_callback+0x26/0xa0
      [  240.272460]  [<ffffffff813b2d71>] rpm_resume+0x4b1/0x690
      [  240.272468]  [<ffffffff812ab992>] ? radix_tree_lookup_slot+0x22/0x50
      [  240.272475]  [<ffffffff813b2c1a>] rpm_resume+0x35a/0x690
      [  240.272482]  [<ffffffff8116e9c9>] ? zone_statistics+0x89/0xa0
      [  240.272489]  [<ffffffff813b2f90>] __pm_runtime_resume+0x40/0x60
      [  240.272497]  [<ffffffff813e4272>] usb_autopm_get_interface+0x22/0x60
      [  240.272509]  [<ffffffffa01ae8d9>] usbhid_open+0x59/0xe0 [usbhid]
      [  240.272517]  [<ffffffffa063ac85>] wacom_open+0x35/0x50 [wacom]
      [  240.272525]  [<ffffffff813f37b9>] input_open_device+0x79/0xa0
      [  240.272534]  [<ffffffffa048d1c1>] evdev_open+0x1b1/0x200 [evdev]
      [  240.272543]  [<ffffffff811c899e>] chrdev_open+0xae/0x1f0
      [  240.272549]  [<ffffffff811c88f0>] ? cdev_put+0x30/0x30
      [  240.272556]  [<ffffffff811c17e2>] do_dentry_open+0x1d2/0x320
      [  240.272562]  [<ffffffff811c1cd1>] finish_open+0x31/0x50
      [  240.272571]  [<ffffffff811d2202>] do_last.isra.36+0x652/0xe50
      [  240.272579]  [<ffffffff811d2ac7>] path_openat+0xc7/0x6f0
      [  240.272586]  [<ffffffff811cf012>] ? final_putname+0x22/0x50
      [  240.272594]  [<ffffffff811d42d2>] ? user_path_at_empty+0x72/0xd0
      [  240.272602]  [<ffffffff811d43fd>] do_filp_open+0x4d/0xc0
      [...]
      
      So here, wacom_open is called, and then wacom_resume is called by the
      PM system. However, wacom_open already took the lock when wacom_resume
      tries to get it. Freeze.
      
      A little bit of history shows that this already happened in the past
      - commit f6cd3783 ("Input: wacom - fix runtime PM related deadlock"),
      and the solution was to call first the PM function before taking the lock.
      
      The lock was introduced in commit commit e7224094 ("Input: wacom -
      implement suspend and autosuspend") when the autosuspend feature has
      been added. Given that usbhid already takes care of this very same
      locking between suspend/resume, I think we can simply kill the lock
      in open/close.
      
      The lock is now used also with LEDs, so we can not remove it completely.
      Reported-by: NHans Spath <inbox-546@hans-spath.de>
      Tested-by: NHans Spath <inbox-546@hans-spath.de>
      CC: stable@vger.kernel.org # v3.17+
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      dff67416
    • M
      HID: make hid_report_len as a static inline function in hid.h · dabb05c6
      Mathieu Magnaudet 提交于
      In several hid drivers it is necessary to calculate the length of an
      hid_report. This patch exports the existing static function hid_report_len of
      hid-core.c as an inline function in hid.h
      Signed-off-by: NMathieu Magnaudet <mathieu.magnaudet@enac.fr>
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      dabb05c6
  15. 26 11月, 2014 1 次提交
  16. 21 11月, 2014 1 次提交
  17. 01 10月, 2014 5 次提交
  18. 22 9月, 2014 1 次提交
  19. 12 9月, 2014 1 次提交
    • B
      HID: wacom: make the WL connection friendly for the desktop · 12969e3b
      Benjamin Tissoires 提交于
      Currently, tablets connected to the WL receiver all share the same
      VID/PID. There is no way for the user space to know which one is which
      besides parsing the name. We can force the PID to be set to the
      actual hardware. This way, the input device will have the correct PID
      which can be match in libwacom.
      
      With only this trick, the pad input does not inherit the ID_INPUT_TABLET
      udev property from its parent. We can force udev to accept it by declaring
      a BTN_STYLUS which is never used.
      
      This way, tablets connected through WL can be used from the user point of
      view in the same way they are used while connected through wire.
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Reviewed-by: NPing Cheng <pingc@wacom.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      12969e3b
  20. 11 9月, 2014 4 次提交
  21. 13 8月, 2014 1 次提交
  22. 07 8月, 2014 5 次提交