Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  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
  3. 19 12月, 2011 1 次提交
  5. 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
  7. 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
  9. 30 11月, 2011 1 次提交
  11. 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
  13. 23 11月, 2011 4 次提交
  15. 20 11月, 2011 2 次提交
  17. 19 11月, 2011 1 次提交
  19. 16 11月, 2011 3 次提交
  21. 11 11月, 2011 1 次提交
  23. 01 11月, 2011 2 次提交
  25. 29 10月, 2011 1 次提交
  27. 28 10月, 2011 1 次提交
  29. 21 10月, 2011 2 次提交
  31. 17 10月, 2011 2 次提交
    • J
      HID: primax: remove spurious dependency · dfe9a312
      由 Jiri Kosina 提交于 
      Remove Kconfig dependency for hid-primax driver on CONFIG_EXPERT.
Please see changelog of 73d5e8f7 ("HID: fix up 'EMBEDDED' mess in
Kconfig") for reasoning behind this.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      dfe9a312
    • T
      HID: support primax keyboards violating USB HID spec · f6a04605
      由 Terry Lambert 提交于 
      Primax keyboards with the issue this driver addresses report modifier
keys as in band key events instead of as out of band modifier bits,
resulting in the modifier keys generating key up events immediately
before the keys they are intended to modify.  This driver rewrites
the raw report data from such keyboards into USB HID 1.11 compliant
report data.  It only matches the USB vendor and product IDs for the
keyboard it has been tested on. Since there are several keyboards,
notably a number of laptops and folding USB keyboards known to have
similar unresolved problem reports, the list is expected to grow.
Signed-off-by: NTerry Lambert <tlambert@chromium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f6a04605
  33. 14 10月, 2011 1 次提交
  35. 09 10月, 2011 1 次提交
  37. 05 10月, 2011 1 次提交
  39. 04 10月, 2011 1 次提交
  41. 03 10月, 2011 1 次提交
  43. 28 9月, 2011 1 次提交
  45. 27 9月, 2011 1 次提交
    • D
      HID: hiddev: potential info leak in hiddev_ioctl() · 9561f7fa
      由 Dan Carpenter 提交于 
      Smatch has a new check for Rosenberg type information leaks where
structs are copied to the user with uninitialized stack data in them.

In this case, the hiddev_devinfo struct has a two byte hole.

struct hiddev_devinfo {
        __u32                      bustype;              /*     0     4 */
        __u32                      busnum;               /*     4     4 */
        __u32                      devnum;               /*     8     4 */
        __u32                      ifnum;                /*    12     4 */
        __s16                      vendor;               /*    16     2 */
        __s16                      product;              /*    18     2 */
        __s16                      version;              /*    20     2 */

        /* XXX 2 bytes hole, try to pack */

        __u32                      num_applications;     /*    24     4 */
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      9561f7fa
  47. 26 9月, 2011 2 次提交
  49. 22 9月, 2011 1 次提交
  51. 20 9月, 2011 3 次提交