Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 04 2月, 2012 1 次提交
  3. 13 1月, 2012 1 次提交
  5. 08 1月, 2012 8 次提交
  7. 05 1月, 2012 1 次提交
  9. 04 1月, 2012 1 次提交
  11. 02 1月, 2012 3 次提交
  13. 21 12月, 2011 5 次提交
    • D
      HID: usbhid: defer LED setting to a workqueue · 4371ea82
      由 Daniel Kurtz 提交于 
      Defer LED setting action to a workqueue.
This is more likely to send all LED change events in a single URB.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Acked-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      4371ea82
    • D
      HID: usbhid: hid-core: submit queued urbs before suspend · f0befcd6
      由 Daniel Kurtz 提交于 
      If any userspace program has opened a keyboard device, the input core
de-activates the keyboard's LEDs upon suspend().  It does this by sending
individual EV_LED[LED_X]=0 events to the underlying device driver by
directly calling the driver's registered event() handler.

The usb-hid driver event() handler processes each request by immediately
attempting to submit a CTRL URB to turn off the LED.  USB URB submission
is asynchronous.  First the URB is added to the head of the ctrl queue.
Then, if the CTRL_RUNNING flag is false, the URB is submitted immediately
(and CTRL_RUNNING is set).  If the CTRL_RUNNING flag was already true,
then the newly queued URB is submitted in the ctrl completion handler when
all previously submitted URBs have completed.  When all queued URBs have
been submitted, the completion handler clears the CTRL_RUNNING flag.

In the 2-LED suspend case, at input suspend(), 2 LED event CTRL URBs get
queued, with only the first actually submitted.  Soon after input
suspend() handler finishes, the usb-hid suspend() handler gets called.
Since this is NOT a PM_EVENT_AUTO suspend, the handler sets
REPORTED_IDLE, then waits for io to complete.

Unfortunately, this usually happens while the first LED request is
actually still being processed.  Thus when the completion handler tries
to submit the second LED request it fails, since REPORTED_IDLE is
already set!  This REPORTED_IDLE check failure causes the completion
handler to complete, however without clearing the CTRL_RUNNING flag.
This, in turn, means that the suspend() handler's wait_io() condition
is never satisfied, and instead it times out after 10 seconds, aborting
the original system suspend.

This patch changes the behavior to the following:
  (1) allow completion handler to finish submitting all queued URBs, even if
      REPORTED_IDLE is set.  This guarantees that all URBs queued before the
      hid-core suspend() call will be submitted before the system is
      suspended.
  (2) if REPORTED_IDLE is set and the URB queue is empty, queue, but
      don't submit, new URB submission requests.  These queued requests get
      submitted when resume() flushes the URB queue. This is similar to the
      existing behavior, however, any requests that arrive while the queue is
      not yet empty will still get submitted before suspend.
  (3) set the RUNNING flag when flushing the URB queue in resume().
      This keeps URBs that were queued in (2) from colliding with any new
      URBs that are being submitted during the resume process.  The new URB
      submission requests upon resume get properly queued behind the ones
      being flushed instead of the current situation where they collide,
      causing memory corruption and oopses.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Acked-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f0befcd6
    • D
      HID: usbhid: remove LED_ON · ede6a8b2
      由 Daniel Kurtz 提交于 
      LED_ON was defined in the original version of the hid-core autosuspend patch.
However, during review, the setting and clearing of it was redone
using ledcount.  The test was left in accidentally.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Acked-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ede6a8b2
    • J
      HID: emsff: use symbolic name instead of hardcoded PID constant · 05ee2838
      由 Jiri Kosina 提交于 
      Use macro instead of 0x118 PID in device table.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      05ee2838
    • I
      HID: Enable HID_QUIRK_MULTI_INPUT for Trio Linker Plus II · cd07655e
      由 Ignaz Forster 提交于 
      Add quirk for the Trio Linker Plus II - the adapter supports several
controllers simultaneously, generating a new HID entry for each connected
device.
Signed-off-by: NIgnaz Forster <ignaz.forster@gmx.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      cd07655e
  15. 19 12月, 2011 1 次提交
  17. 17 12月, 2011 1 次提交
    • J
      HID: introduce proper dependency of HID_BATTERY on POWER_SUPPLY · 7e69ba7c
      由 Jiri Kosina 提交于 
      ppc6xx_defconfig reveals this:

drivers/built-in.o: In function `hidinput_cleanup_battery': drivers/hid/hid-input.c:351: undefined reference to`power_supply_unregister'
drivers/built-in.o: In function `hidinput_setup_battery': drivers/hid/hid-input.c:338: undefined reference to `power_supply_register'
make[1]: *** [.tmp_vmlinux1] Error 1

The defconfig in question doens't mention either option and kbuild is
genertaing

	CONFIG_HID_BATTERY_STRENGTH=y
	CONFIG_POWER_SUPPLY=m

which is wrong. Put a proper dependency in place.
Reported-by: NTony Breeds <tony@bakeyournoodle.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      7e69ba7c
  19. 15 12月, 2011 2 次提交
  21. 12 12月, 2011 1 次提交
  23. 10 12月, 2011 2 次提交
  25. 06 12月, 2011 1 次提交
  27. 02 12月, 2011 1 次提交
  29. 30 11月, 2011 3 次提交
  31. 28 11月, 2011 1 次提交
    • J
      HID: hid-input: add support for HID devices reporting Battery Strength · 4f5ca836
      由 Jeremy Fitzhardinge 提交于 
      Some HID devices, such as my Bluetooth mouse, report their battery
strength as an event.  Rather than passing it through as a strange
absolute input event, this patch registers it with the power_supply
subsystem as a battery, so that the device's Battery Strength can be
reported to usermode.

The battery appears in sysfs names
/sys/class/power_supply/hid-<UNIQ>-battery, and it is a child of the
battery-containing device, so it should be clear what it's the battery of.

Unfortunately on my current Fedora 16 system, while the battery does
appear in the UI, it is listed as a Laptop Battery with 0% charge (since
it ignores the "capacity" property of the battery and instead computes
it from the "energy*" fields, which we can't supply given the limited
information contained within the HID Report).

Still, this patch is the first step.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      4f5ca836
  33. 23 11月, 2011 7 次提交