The critical section protected by usbhid->lock in hid_ctrl() is too
big and because of this it causes a recursive deadlock. "Too big" means
the case statement and the call to hid_input_report() do not need to be
protected by the spinlock (no URB operations are done inside them).
The deadlock happens because in certain rare cases drivers try to grab
the lock while handling the ctrl irq which grabs the lock before them
as described above. For example newer wacom tablets like 056a:033c try
to reschedule proximity reads from wacom_intuos_schedule_prox_event()
calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report()
which tries to grab the usbhid lock already held by hid_ctrl().
There are two ways to get out of this deadlock:
1. Make the drivers work "around" the ctrl critical region, in the
wacom case for ex. by delaying the scheduling of the proximity read
request itself to a workqueue.
2. Shrink the critical region so the usbhid lock protects only the
instructions which modify usbhid state, calling hid_input_report()
with the spinlock unlocked, allowing the device driver to grab the
lock first, finish and then grab the lock afterwards in hid_ctrl().
This patch implements the 2nd solution.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If an event is discarded the device stays idle. Just reverse the order of
check and marking busy.
Found by code inspection.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It was reported that after 10-20 reboots, a usb keyboard plugged
into a docking station would not work unless it was replugged in.
Using usbmon, it turns out the interrupt URBs were streaming with
callback errors of -71 for some reason. The hid-core.c::hid_io_error was
supposed to retry and then reset, but the reset wasn't really happening.
The check for HID_NO_BANDWIDTH was inverted. Fix was simple.
Tested by reporter and locally by me by unplugging a keyboard halfway until I
could recreate a stream of errors but no disconnect.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
During open() it is unnecessary to wait for the device to flush
stale inputs if the device is polled while closed due to a quirk
or opening fails.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
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: Mathieu Magnaudet <mathieu.magnaudet@enac.fr>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When events occurs while no one is listening to the node (hid->open == 0
and usb_kill_urb() called) some events are still stacked somewhere in
the USB (kernel or device?) stack. When the node gets reopened, these
events are drained, and this results in spurious touch down/up, or mouse
button clicks.
The problem was spotted with touchscreens in fdo bug #81781 [1], but it
actually occurs with any mouse using hid-generic or touchscreen.
A way to reproduce it is to call:
$ xinput disable 9 ; sleep 5 ; xinput enable 9
With 9 being the device ID for the touchscreen/mouse. During the "sleep",
produce some touch events or click events. When "xinput enable" is called,
at least one click is generated.
This patch tries to fix this by draining the queue for 50 msec and
during this time frame, not forwarding these old events to the hid layer.
Hans completed the explanation:
"""
Devices like mice (basically any hid device) will have a fifo
on the device side, when we stop submitting urbs to get hid reports from
it, that fifo will fill up, and when we resume we will get whatever
is there in that fifo.
"""
[1] https://bugs.freedesktop.org/show_bug.cgi?id=81781
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add quirk to make sure that a device is always polled for input events
even if it hasn't been opened.
This is needed for devices that disconnects from the bus unless the
interrupt endpoint has been polled at least once or when not responding
to an input event (e.g. after having shut down X).
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch changes the way usbhid carries out Clear-Halt and reset.
Currently, after a Clear-Halt on the interrupt-IN endpoint, the driver
immediately restarts the interrupt URB, even if the Clear-Halt failed.
This doesn't work out well when the reason for the failure was that
the device was disconnected (when a low- or full-speed device is
connected through a hub to an EHCI controller, transfer errors caused
by disconnection are reported as stalls by the hub). Instead now the
driver will attempt a reset after a failed Clear-Halt.
The way resets are carried out is also changed. Now the driver will
call usb_queue_reset_device() instead of calling usb_reset_device()
directly. This avoids a deadlock that would arise when a device is
unplugged: The hid_reset() routine runs as a workqueue item, a reset
attempt after the device has been unplugged will fail, failure will
cause usbhid to be unbound, and the disconnect routine will try to do
cancel_work_sync(). The usb_queue_reset_device() implementation is
carefully written to handle scenarios like this one properly.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The quirks_param array is located in the BSS, no need to explicitly
initialize it with NULL.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Nobody calls hid_output_raw_report anymore, and nobody should.
We can now remove the various implementation in the different
transport drivers and the declarations.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
hid_out_raw_report is going to be obsoleted as it is not part of the
unified HID low level transport documentation
(Documentation/hid/hid-transport.txt)
To do so, we need to introduce two new quirks:
* HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP: this quirks prevents the
transport driver to use the interrupt channel to send output report
(and thus force to use HID_REQ_SET_REPORT command)
* HID_QUIRK_SKIP_OUTPUT_REPORT_ID: this one forces usbhid to not
include the report ID in the buffer it sends to the device through
HID_REQ_SET_REPORT in case of an output report
This also fixes a regression introduced in commit 3a75b24949
(HID: hidraw: replace hid_output_raw_report() calls by appropriates ones).
The hidraw API was not able to communicate with the PS3 SixAxis
controllers in USB mode.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Antonio Ospite <ao2@ao2.it>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri 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: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Well, no use to keep twice the same code.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add raw_request, set_raw_report and output_report transport-driver functions to
the USB HID driver.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Acked-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri 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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Tested-by: Srinivas Pandruvada<srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID core provides the same functionality as we do, so drop the custom
hidinput_input_event() handler.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri 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: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri 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: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri 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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID updates from Jiri Kosina:
- hid driver transport cleanup, finalizing the long-desired decoupling
of core from transport layers, by Benjamin Tissoires and Henrik
Rydberg
- support for hybrid finger/pen multitouch HID devices, by Benjamin
Tissoires
- fix for long-standing issue in Logitech unifying driver sometimes not
inializing properly due to device specifics, by Andrew de los Reyes
- Wii remote driver updates to support 2nd generation of devices, by
David Herrmann
- support for Apple IR remote
- roccat driver now supports new devices (Roccat Kone Pure, IskuFX), by
Stefan Achatz
- debugfs locking fixes in hid debug interface, by Jiri Kosina
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (43 commits)
HID: protect hid_debug_list
HID: debug: break out hid_dump_report() into hid-debug
HID: Add PID for Japanese version of NE4K keyboard
HID: hid-lg4ff add support for new version of DFGT wheel
HID: icade: u16 which never < 0
HID: clarify Magic Mouse Kconfig description
HID: appleir: add support for Apple ir devices
HID: roccat: added media key support for Kone
HID: hid-lenovo-tpkbd: remove doubled hid_get_drvdata
HID: i2c-hid: fix length for set/get report in i2c hid
HID: wiimote: parse reduced status reports
HID: wiimote: add 2nd generation Wii Remote IDs
HID: wiimote: use unique battery names
HID: hidraw: warn if userspace headers are outdated
HID: multitouch: force BTN_STYLUS for pen devices
HID: multitouch: append " Pen" to the name of the stylus input
HID: multitouch: add handling for pen in dual-sensors device
HID: multitouch: change touch sensor detection in mt_input_configured()
HID: multitouch: do not map usage from non used reports
HID: multitouch: breaks out touch handling in specific functions
...
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: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg 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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri 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: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri 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: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
For the sensor-hub part:
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri 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: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri 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: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri 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/1049623
Signed-off-by: Kevin Daughtridge <kevin@kdau.com>
Signed-off-by: Jiri 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: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri 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: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri 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: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri 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: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri 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: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri 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: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID subsystem updates from Jiri Kosina:
"Apart from various driver updates and added support for a number of
new devices (mostly multitouch ones, but not limited to), there is one
change that is worth pointing out explicitly: creation of HID device
groups and proper autoloading of hid-multitouch, implemented by Henrik
Rydberg."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (50 commits)
HID: wacom: fix build breakage without CONFIG_LEDS_CLASS
HID: waltop: Extend barrel button fix
HID: hyperv: Set the hid drvdata correctly
HID: wacom: Unify speed setting
HID: wacom: Add speed setting for Intuos4 WL
HID: wacom: Move Graphire raport header check.
HID: uclogic: Add support for UC-Logic TWHL850
HID: explain the signed/unsigned handling in hid_add_field()
HID: handle logical min/max signedness properly in parser
HID: logitech: read all 32 bits of report type bitfield
HID: wacom: Add LED selector control for Wacom Intuos4 WL
HID: hid-multitouch: fix wrong protocol detection
HID: wiimote: Fix IR data parser
HID: wacom: Add tilt reporting for Intuos4 WL
HID: multitouch: MT interface matching for Baanto
HID: hid-multitouch: Only match MT interfaces
HID: Create a common generic driver
HID: hid-multitouch: Switch to device groups
HID: Create a generic device group
HID: Allow bus wildcard matching
...
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: Greg 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: Oliver Neukum <oneukum@suse.de>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg 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: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Jiri 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: Henrik Rydberg <rydberg@euromail.se>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri 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: Toby Gray <toby.gray@realvnc.com>
Signed-off-by: Simon Haggett <simon.haggett@realvnc.com>
Signed-off-by: Jiri 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: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri 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: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri 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: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri 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: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* 'pm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (63 commits)
PM / Clocks: Remove redundant NULL checks before kfree()
PM / Documentation: Update docs about suspend and CPU hotplug
ACPI / PM: Add Sony VGN-FW21E to nonvs blacklist.
ARM: mach-shmobile: sh7372 A4R support (v4)
ARM: mach-shmobile: sh7372 A3SP support (v4)
PM / Sleep: Mark devices involved in wakeup signaling during suspend
PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
PM / Hibernate: Do not initialize static and extern variables to 0
PM / Freezer: Make fake_signal_wake_up() wake TASK_KILLABLE tasks too
PM / Hibernate: Add resumedelay kernel param in addition to resumewait
MAINTAINERS: Update linux-pm list address
PM / ACPI: Blacklist Vaio VGN-FW520F machine known to require acpi_sleep=nonvs
PM / ACPI: Blacklist Sony Vaio known to require acpi_sleep=nonvs
PM / Hibernate: Add resumewait param to support MMC-like devices as resume file
PM / Hibernate: Fix typo in a kerneldoc comment
PM / Hibernate: Freeze kernel threads after preallocating memory
PM: Update the policy on default wakeup settings
PM / VT: Cleanup #if defined uglyness and fix compile error
PM / Suspend: Off by one in pm_suspend()
PM / Hibernate: Include storage keys in hibernation image on s390
...
Ioan-Adrian Ratiu
Oliver Neukum
Don Zickus
Oliver Neukum
Jiri Kosina
Mathieu Magnaudet
Benjamin Tissoires
Johan Hovold
Alan Stern
Reyad Attiyat
Mathias Krause
Frank Praznik
David Herrmann
Linus Torvalds
Ming Lei
Benjamin Tissoires
Henrik Rydberg
Kevin Daughtridge
Greg Kroah-Hartman
Oliver Neukum
Simon Haggett
Daniel Kurtz