1. 21 12月, 2011 3 次提交
    • 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
  2. 19 12月, 2011 1 次提交
  3. 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
  4. 15 12月, 2011 1 次提交
    • J
      HID: make parser more verbose about parsing errors by default · 8c3d52fc
      Jiri Kosina 提交于
      Most of the parsing errors (typically resulting in device not being claimed
      by HID subsystem at all) are reported only in debugging mode, which makes
      root-causing problems with buggy devices unnecessarily more difficult.
      
      Convert reporting of important HID report descriptor parsing errors to
      be reported through hid_err() / hid_warn() instead of dbg_hid().
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      8c3d52fc
  5. 30 11月, 2011 1 次提交
  6. 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
  7. 23 11月, 2011 4 次提交
  8. 20 11月, 2011 2 次提交
  9. 19 11月, 2011 1 次提交
  10. 16 11月, 2011 3 次提交
  11. 11 11月, 2011 1 次提交
  12. 03 11月, 2011 18 次提交
  13. 02 11月, 2011 3 次提交