If there is no urbout when sending a output report, ENOSYS (Function
not implemented) is a better error than EIO (I/O error).
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

dev->hid_get_raw_report(X) and hid_hw_raw_request(X, HID_REQ_GET_REPORT)
are strictly equivalent. Switch the hid subsystem to the hid_hw notation
and remove the field .hid_get_raw_report in struct hid_device.
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Well, no use to keep twice the same code.
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add raw_request, set_raw_report and output_report transport-driver functions to
the USB HID driver.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Acked-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Some multitouch screens do not like to be polled for input reports.
However, the Win8 spec says that all touches should be sent during
each report, making the initialization of reports unnecessary.
The Win7 spec is less precise, so do not use this for those devices.

Add the quirk HID_QUIRK_NO_INIT_INPUT_REPORTS so that we do not have to
introduce a quirk for each problematic device. This quirk makes the driver
behave the same way the Win 8 does. It actually retrieves the features,
but not the inputs.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NHenrik Rydberg <rydberg@euromail.se>
Tested-by: Srinivas Pandruvada<srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

HID core provides the same functionality as we do, so drop the custom
hidinput_input_event() handler.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Report fields can be updated from HID drivers unlocked via
hid_set_field(). It is protected by input_lock in HID core so only a
single input event is handled at a time. USBHID can thus update the field
unlocked and doesn't conflict with any HID vendor/device drivers. Note,
many HID drivers make heavy use of hid_set_field() in that way.

But usbhid also schedules a work to gather multiple LED changes in a
single report. Hence, we used to lock the LED field update so the work can
read a consistent state. However, hid_set_field() only writes a single
integer field, which is guaranteed to be allocated all the time. So the
worst possible race-condition is a garbage read on the LED field.

Therefore, there is no need to protect the update. In fact, the only thing
that is prevented by locking hid_set_field(), is an LED update while the
scheduled work currently writes an older LED update out. However, this
means, a new work is scheduled directly when the old one is done writing
the new state to the device. So we actually _win_ by not protecting the
write and allowing the write to be combined with the current write. A new
worker is still scheduled, but will not write any new state. So the LED
will not blink unnecessarily on the device.

Assume we have the LED set to 0. Two request come in which enable the LED
and immediately disable it. The current situation with two CPUs would be:

  usb_hidinput_input_event()       |      hid_led()
  ---------------------------------+----------------------------------
    spin_lock(&usbhid->lock);
    hid_set_field(1);
    spin_unlock(&usbhid->lock);
    schedule_work(...);
                                      spin_lock(&usbhid->lock);
                                      __usbhid_submit_report(..1..);
                                      spin_unlock(&usbhid->lock);
    spin_lock(&usbhid->lock);
    hid_set_field(0);
    spin_unlock(&usbhid->lock);
    schedule_work(...);
                                      spin_lock(&usbhid->lock);
                                      __usbhid_submit_report(..0..);
                                      spin_unlock(&usbhid->lock);

With the locking removed, we _might_ end up with (look at the changed
__usbhid_submit_report() parameters in the first try!):

  usb_hidinput_input_event()       |      hid_led()
  ---------------------------------+----------------------------------
    hid_set_field(1);
    schedule_work(...);
                                      spin_lock(&usbhid->lock);
    hid_set_field(0);
    schedule_work(...);
                                      __usbhid_submit_report(..0..);
                                      spin_unlock(&usbhid->lock);

                                      ... next work ...

                                      spin_lock(&usbhid->lock);
                                      __usbhid_submit_report(..0..);
                                      spin_unlock(&usbhid->lock);

As one can see, we no longer send the "LED ON" signal as it is disabled
immediately afterwards and the following "LED OFF" request overwrites the
pending "LED ON".

It is important to note that hid_set_field() is not atomic, so we might
also end up with any other value. But that doesn't matter either as we
_always_ schedule the next work with a correct value and schedule_work()
acts as memory barrier, anyways. So in the worst case, we run
__usbhid_submit_report(..<garbage>..) in the first case and the following
__usbhid_submit_report() will write the correct value. But LED states are
booleans so any garbage will be converted to either 0 or 1 and the remote
device will never see invalid requests.

Why all this? It avoids any custom locking around hid_set_field() in
usbhid and finally allows us to provide a generic hidinput_input_event()
handler for all HID transport drivers.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

usbhid_set_leds() is only used inside of usbhid/hid-core.c so no need to
export it.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

implement() is setting bytes in LE data stream. In case the data is not
aligned to 64bits, it reads past the allocated buffer. It doesn't really
change any value there (it's properly bitmasked), but in case that this
read past the boundary hits a page boundary, pagefault happens when
accessing 64bits of 'x' in implement(), and kernel oopses.

This happens much more often when numbered reports are in use, as the
initial 8bit skip in the buffer makes the whole process work on values
which are not aligned to 64bits.

This problem dates back to attempts in 2005 and 2006 to make implement()
and extract() as generic as possible, and even back then the problem
was realized by Adam Kroperlin, but falsely assumed to be impossible
to cause any harm:

  http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html

I have made several attempts at fixing it "on the spot" directly in
implement(), but the results were horrible; the special casing for processing
last 64bit chunk and switching to different math makes it unreadable mess.

I therefore took a path to allocate a few bytes more which will never make
it into final report, but are there as a cushion for all the 64bit math
operations happening in implement() and extract().

All callers of hid_output_report() are converted at the same time to allocate
the buffer by newly introduced hid_alloc_report_buf() helper.

Bruno noticed that the whole raw_size test can be dropped as well, as
hid_alloc_report_buf() makes sure that the buffer is always of a proper
size.
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

If suspend callback fails in system sleep context, usb core will
ignore the failure and let the system sleep go ahead further, so this
patch doesn't recover device under this situation, otherwise
may cause resume() confused.
Acked-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some drivers send the idle command directly to underlying device,
creating an unwanted dependency on the underlying transport layer.
This patch adds hid_hw_idle() to the interface, thereby removing
usbhid from the lion share of the drivers.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This removes most of the dependencies between hid drivers and usbhid.

The patch was constructed by replacing all occurences of
usbhid_wait_io() by its hid_hw_wait() counterpart.
Then, drivers not requiring USB_HID anymore have their USB_HID
dependency cleaned in the Kconfig file.

As of today, few drivers are still requiring an explicit USB layer
dependency:
* ntrig (a patch is on its way)
* multitouch (one patch following and another on its way)
* lenovo tpkbd
* roccat
* sony

The last three are two deeply using direct calls to the usb subsystem
to be able to be cleaned right now.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This allows the hid drivers to be independent from the transport layer.

The patch was constructed by replacing all occurences of
usbhid_submit_report() by its hid_hw_request() counterpart.
Then, drivers not requiring USB_HID anymore have their USB_HID
dependency cleaned in the Kconfig file.

Finally, few drivers still depends on USB_HID. Many of them
are requiring the io wait callback. They are found in the next patch.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

For the sensor-hub part:
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Some drivers need to wait for an io from the underlying device, creating
an unwanted dependency on the underlying transport layer. This patch adds
wait() to the interface, thereby removing usbhid from the lion share of
the drivers.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Some drivers send reports directly to underlying device, creating an
unwanted dependency on the underlying transport layer. This patch adds
hid_hw_request() to the interface, thereby removing usbhid from the
lion share of the drivers.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The dev_rdesc member of the hid_device structure is meant to store the original
report descriptor received from the device, but it is currently passed to any
report_fixup method before it is copied to the rdesc member. This patch uses a
temporary buffer to shield dev_rdesc from the side effects of many HID drivers'
report_fixup implementations.

usbhid's hid_post_reset checks the report descriptor currently returned by the
device against a descriptor that may have been modified by a driver's
report_fixup method. That leaves some devices nonfunctional after a resume, with
a "reset_resume error 1" reported. This patch checks the new descriptor against
the unmodified dev_rdesc instead and uses the original, instead of modified,
report size.

BugLink: http://bugs.launchpad.net/bugs/1049623Signed-off-by: NKevin Daughtridge <kevin@kdau.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch (as1597) fixes some of the error paths in usbhid's suspend
routine.  The driver was not careful to restart everything that might
have been stopped, in cases where a suspend failed.

For example, once the HID_SUSPENDED flag is set, an output report
submission would not restart the corresponding URB queue.  If a
suspend fails, it's therefore necessary to check whether the queues
need to be restarted.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch (as1596) improves the queue-restart logic in usbhid by
checking to see if the device is suspended or a reset is about to
occur.  There's no point submitting an URB if either of those is
true.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch (as1595) improves the usbhid driver by using the
HID_SUSPENDED bitflag to indicate that the device is suspended rather
than using HID_REPORTED_IDLE, which the patch removes.

Since HID_SUSPENDED was not being used for anything, and since the
name "HID_REPORTED_IDLE" doesn't convey much meaning, the end result
is easier to read and understand.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch (as1594) simplifies the usbhid driver by inlining a couple
of routines.  As a result of an earlier patch, irq_out_pump_restart()
and ctrl_pump_restart() are each used in only one place.  Since they
don't really do what their names say, and since they each involve only
about two lines of actual code, there's no reason to keep them as
separate functions.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch (as1593) fixes some logic errors in the usbhid driver
relating to runtime PM.  The driver does not balance its calls to
usb_autopm_get_interface_async() and usb_autopm_put_interface_async().

For example, when the control queue is restarted the driver does a
_get.  But the resume won't happen immediately, so the driver leaves
the queue stopped.  When the resume does occur, the queue is restarted
and a second _get occurs, with no balancing _put.

The patch fixes the problem by rearranging the logic for restarting
the queues.  All the _get/_put calls and bitflag settings in
__usbhid_submit_report() are moved into the queue-restart routines.  A
balancing _put call is added for the case where the queue is still
suspended.  A call to irq_out_pump_restart(), which doesn't take all
the right actions for restarting the irq-OUT queue, is replaced by a
call to usbhid_restart_out_queue(), which does.  Similarly for
ctrl_pump_restart().

Finally, new code is added to prevent an autosuspend from happening
every time an URB is cancelled, and the comments explaining what
happens when an URB needs to be cancelled are expanded and clarified.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch (as1592) fixes an obscure problem in the usbhid driver.
Under some circumstances, a control or interrupt-OUT URB can be
submitted twice.  This will happen if the first submission fails; the
queue pointers aren't updated, so the next time the queue is restarted
the same URB will be submitted again.

The problem is that raw_report gets deallocated during the first
submission.  The second submission will then dereference and try to
free an already-freed region of memory.  The patch fixes the problem
by setting raw_report to NULL when it is deallocated and checking for
NULL before dereferencing it.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

dbg() was a very old USB-specific macro that should no longer
be used. This patch removes it from being used in the driver
and uses dev_dbg() instead.

CC: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On some HCDs usb_unlink_urb() can directly call the
completion handler. That limits the spinlocks that can
be taken in the handler to locks not held while calling
usb_unlink_urb()
To prevent a race with resubmission, this patch exposes
usbcore's infrastructure for blocking submission, uses it
and so drops the lock without causing a race in usbhid.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move the hid drivers of the bus drivers to a common generic hid
driver, and make it a proper module. This ought to simplify device
handling moving forward.

Cc: Gustavo Padovan <gustavo@padovan.org>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Devices that do not have a special driver are handled by the generic
driver. This patch does the same thing using device groups; Instead of
forcing a particular driver, the appropriate driver is picked up by
udev. As a consequence, one can now move a device from generic to
specific handling by a simple rebind. By adding a new device id to the
generic driver, the same thing can be done in reverse.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When a USB device reset occurs, usbcore will refetch the device and configuration
descriptors and compare them with those retrieved before the reset to ensure
that they have not changed. For USB HID devices, this implicitly includes the
HID class descriptor (as this is fetched with the configuration descriptor).
However, the HID report descriptor is not checked again.

Whilst a change in the size of the HID report descriptor will be detected (as
this is held in the class descriptor), content changes to the report descriptor
which do not result in a change in its size will be missed. If a firmware update
were applied to a USB HID device which resulted in such a change to the report
descriptor after device reset, then this would not be picked up by usbhid.

This patch fixes this issue by allowing usbhid to check the contents of the
report descriptor after the device reset, and trigger a rebind of the device
if there is a mismatch.
Reviewed-by: NToby Gray <toby.gray@realvnc.com>
Signed-off-by: NSimon Haggett <simon.haggett@realvnc.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In case IO cannot be started because there is a lack of bandwidth
on the bus, it makes no sense to reset the device. If IO is requested
because the device is opened, user space should be notified with
an error right away. If the lack of bandwidth arises later, for
example after resume, there's no other choice but to retry in the
hope that bandwidth will be freed.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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>

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>

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>

This makes sure IO is never restarted while a reset is going on

In particular there seems to be no protection from hid_retry_timeout() calling
hid_start_in() which would start IO after hid_pre_reset() has already called
hid_cease_io() because that uses del_timer(), not del_timer_sync()
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch (as1482) adds a macro for testing whether or not a
pm_message value represents an autosuspend or autoresume (i.e., a
runtime PM) event.  Encapsulating this notion seems preferable to
open-coding the test all over the place.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Unfortunately, the device seems to have the same Vendor ID and Product ID
as YUREX leg-shakes sensors, and the commit 6bc235a2 ("USB: add driver
for Meywa-Denki & Kayac YUREX") added the ID to hid_ignore_list.

I believe that we can distinguish YUREX and the Wireless Presenter by
device type.  The patch below makes the driver ignore only YUREX
(bInterfaceProtocol==0), and recognize Wireless Presenter
(bInterfaceProtocol is keyboard or mouse) as generic HID.  (I don't have
the Wireless Presenter, so not yet ested.)

** YUREX lsusb information:
Bus 002 Device 007: ID 0c45:1010 Microdia
Device Descriptor:
   bLength                18
   bDescriptorType         1
   bcdUSB               1.10
   bDeviceClass            0 (Defined at Interface level)
   bDeviceSubClass         0
   bDeviceProtocol         0
   bMaxPacketSize0         8
   idVendor           0x0c45 Microdia
   idProduct          0x1010
   bcdDevice            0.03
   iManufacturer           1 JESS
   iProduct                2 YUREX
   iSerial                 3 10000269
   bNumConfigurations      1
   Configuration Descriptor:
     bLength                 9
     bDescriptorType         2
     wTotalLength           34
     bNumInterfaces          1
     bConfigurationValue     1
     iConfiguration          0
     bmAttributes         0xa0
       (Bus Powered)
       Remote Wakeup
     MaxPower              100mA
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       0
       bNumEndpoints           1
       bInterfaceClass         3 Human Interface Device
       bInterfaceSubClass      1 Boot Interface Subclass
       bInterfaceProtocol      0 None
       iInterface              0
         HID Device Descriptor:
           bLength                 9
           bDescriptorType        33
           bcdHID               1.10
           bCountryCode            0 Not supported
           bNumDescriptors         1
           bDescriptorType        34 Report
           wDescriptorLength      31
          Report Descriptors:
            ** UNAVAILABLE **
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0008  1x 8 bytes
         bInterval              10
Device Status:     0x0002
   (Bus Powered)
   Remote Wakeup Enabled

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=26922Signed-off-by: NTomoki Sekiyama <tomoki.sekiyama@gmail.com>
Cc: Greg KH <gregkh@suse.de>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
Reported-by: NThomas B?chler <thomas@archlinux.org>
Tested-by: NThomas B?chler <thomas@archlinux.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Per the HID Specification, Feature reports must be sent and received on
the Configuration endpoint (EP 0) through the Set_Report/Get_Report
interfaces.  This patch adds two ioctls to hidraw to set and get feature
reports to and from the device.  Modifications were made to hidraw and
usbhid.

New hidraw ioctls:
  HIDIOCSFEATURE - Perform a Set_Report transfer of a Feature report.
  HIDIOCGFEATURE - Perform a Get_Report transfer of a Feature report.
Signed-off-by: NAlan Ott <alan@signal11.us>
Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch doesn't alter functionality, but removes a dedicated kernel
thread.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Tested-by: NMaulik Mankad <x0082077@ti.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Neaten current uses of dev_<level> by adding and using
hid specific hid_<level> macros.

Convert existing uses of dev_<level> uses to hid_<level>.
Convert hid-pidff printk uses to hid_<level>.

Remove err_hid and use hid_err instead.

Add missing newlines to logging messages where necessary.
Coalesce format strings.

Add and use pr_fmt(fmt) KBUILD_MODNAME ": " fmt

Other miscellaneous changes:

Add const struct hid_device * argument to hid-core functions
extract() and implement() so hid_<level> can be used by them.
Fix bad indentation in hid-core hid_input_field function
that calls extract() function above.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Now that hiddev_driver isn't being used for anything, there's no
reason to keep it around.  This patch (as1419) gets rid of it
entirely.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Added blank line after declarations.
Signed-off-by: NAlan Ott <alan@signal11.us>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Feature reports should only be sent on the control endpoint.

The USB HID standard is unclear and confusing on this issue. It seems to
suggest that Feature reports can be sent on a HID device's Interrupt OUT
endpoint.  This cannot be the case because the report type is not encoded in
transfers sent out the Interrput OUT endpoint.  If Feature reports were sent on
the Interrupt OUT endpint, they would be indistinguishable from Output reports
in the case where Report IDs were not used.

Further, Windows and Mac OS X do not send Feature reports out the interrupt OUT
Endpoint.  They will only go out the Control Endpoint.

In addition, many devices simply do not hande Feature reports sent out the
Interrupt OUT endpoint.

Reported-by: simon@mungewell.org
Signed-off-by: NAlan Ott <alan@signal11.us>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>