summaryrefslogtreecommitdiffstats
path: root/drivers/hid/usbhid/usbhid.h
Commit message (Collapse)AuthorAgeFilesLines
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156Thomas Gleixner2019-05-301-14/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1334 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: usbhid: do not rely on hid->open when deciding to do IODmitry Torokhov2017-06-081-0/+11
| | | | | | | | | | | | Instead of checking hid->open (that we plan on having HID core manage) in hid_start_in(), let's allocate a couple of new flags: HID_IN_POLLING and HID_OPENED, and use them to decide whether we should be submitting URBs or not. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: hiddev: use hid_hw_power instead of usbhid_get/put_powerDmitry Torokhov2017-06-081-2/+0
| | | | | | | | | | | | | | Instead of calling into usbhid code directly, let's use the standard accessors for the transport HID drivers, and stop clobbering their error codes with -EIO. This also allows us to remove usbhid_get/put_power(), leaving only usbhid_power(). Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: hiddev: use hid_hw_open/close instead of usbhid_open/closeDmitry Torokhov2017-06-081-2/+0
| | | | | | | | | | | | | Instead of calling into usbhid code directly, let's use the standard accessors for the transport HID drivers, and stop clobbering their errors with -EIO. This also allows us make usbhid_open and close static. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: usbhid: use to_usb_deviceGeliang Tang2015-12-281-1/+1
| | | | | | | Use to_usb_device() instead of open-coding it. Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: usbhid: prevent unwanted events to be sent when re-opening the deviceBenjamin Tissoires2014-10-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* HID: usbhid: use generic hidinput_input_event()David Herrmann2013-07-311-3/+0
| | | | | | | | | 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>
* HID: use hid_hw_wait() instead of direct call to usbhidBenjamin Tissoires2013-02-251-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* HID: use hid_hw_request() instead of direct call to usbhidBenjamin Tissoires2013-02-251-2/+0
| | | | | | | | | | | | | | | | | | | 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>
* HID: usbhid: replace HID_REPORTED_IDLE with HID_SUSPENDEDAlan Stern2012-07-201-1/+0
| | | | | | | | | | | | | | 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>
* HID: usbhid: fix error handling of not enough bandwidthOliver Neukum2012-03-301-0/+1
| | | | | | | | | | | | 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>
* HID: usbhid: defer LED setting to a workqueueDaniel Kurtz2011-12-211-0/+2
| | | | | | | | | 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>
* HID: usbhid: remove LED_ONDaniel Kurtz2011-12-211-1/+0
| | | | | | | | | | 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>
* HID: usbhid: base runtime PM on modern APIOliver Neukum2010-12-221-1/+0
| | | | | | | | | This patch doesn't alter functionality, but removes a dedicated kernel thread. Signed-off-by: Oliver Neukum <oneukum@suse.de> Tested-by: Maulik Mankad <x0082077@ti.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: fix hiddev's use of usb_find_interfaceGuillaume Chazarain2010-09-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | My macbook infrared remote control was broken by commit bd25f4dd6972755579d0ea50d1a5ace2e9b00d1a ("HID: hiddev: use usb_find_interface, get rid of BKL"). This device appears in dmesg as: apple 0003:05AC:8242.0001: hiddev0,hidraw0: USB HID v1.11 Device [Apple Computer, Inc. IR Receiver] on usb-0000:00:1d.2-1/input0 It stopped working as lircd was getting ENODEV when opening /dev/usb/hiddev0. AFAICS hiddev_driver is a dummy driver so usb_find_interface(&hiddev_driver) does not find anything. The device is associated with the usbhid driver, so let's do usb_find_interface(&hid_driver) instead. $ ls -l /sys/devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1:1.0/usb/hiddev0/device/driver lrwxrwxrwx 1 root root 0 2010-09-12 16:28 /sys/devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1:1.0/usb/hiddev0/device/driver -> ../../../../../../bus/usb/drivers/usbhid Signed-off-by: Guillaume Chazarain <guichaz@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* USB: remove uses of URB_NO_SETUP_DMA_MAPAlan Stern2010-05-201-1/+0
| | | | | | | | | | | | | | | | | | | | This patch (as1350) removes all usages of coherent buffers for USB control-request setup-packet buffers. There's no good reason to reserve coherent memory for these things; control requests are hardly ever used in large quantity (the major exception is firmware transfers, and they aren't time-critical). Furthermore, only seven drivers used it. We might as well always use streaming DMA mappings for setup-packet buffers, and remove some extra complexity from usbcore. The DMA-mapping portion of hcd.c is currently in flux. A separate patch will be submitted to remove support for URB_NO_SETUP_DMA_MAP after everything else settles down. The removal should go smoothly, as by then nobody will be using it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* HID: usbhid: introduce timeout for stuck ctrl/out URBsOliver Neukum2010-02-121-0/+2
| | | | | | | | | | | Some devices do not react to a control request (seen on APC UPS's) resulting in a slow stream of messages, "generic-usb ... control queue full". Therefore request needs a timeout. Cc: stable@kernel.org Signed-off-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: David Fries <david@fries.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: autosuspend support for USB HIDOliver Neukum2009-03-251-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | This uses the USB busy mechanism for aggessive autosuspend of USB HID devices. It autosuspends all opened devices supporting remote wakeup after a timeout unless - output is being done to the device - a key is being held down (remote wakeup isn't triggered upon key release) - LED(s) are lit - hiddev is opened As in the current driver closed devices will be autosuspended even if they don't support remote wakeup. The patch is quite large because output to devices is done in hard interrupt context meaning a lot a queuing and locking had to be touched. The LED stuff has been solved by means of a simple counter. Additions to the generic HID code could be avoided. In addition it now covers hidraw. It contains an embryonic version of an API to let the generic HID code tell the lower levels which capabilities with respect to power management are needed. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: move usbhid flags to usbhid.hJiri Slaby2009-01-041-0/+10
| | | | | | | Move usbhid specific flags from global hid.h into local usbhid.h. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: remove setup mutex, fix possible deadlockJiri Slaby2008-11-231-1/+0
| | | | | | | | | | | | | | | It causes recursive locking warning and is unneeded after introduction of STARTED flag. * Resume vs. stop is effectively solved by DISCONNECT flag. * No problem in suspend vs. start -- urb is submitted even after open which is possible after connect which is called after start. * Resume vs. start solved by STARTED flag. * Suspend vs. stop -- no problem in killing urb and timer twice. Reported-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: fix oops during suspend of unbound HID devicesJiri Slaby2008-10-271-0/+2
| | | | | | | | | | | | | | | | | Usbhid structure is allocated on start invoked only from probe of some driver. When there is no driver, the structure is null and causes null-dereference oopses. Fix it by allocating the structure on probe and disconnect of the device itself. Also make sure we won't race between start and resume or stop and suspend respectively. References: http://bugzilla.kernel.org/show_bug.cgi?id=11827 Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Andreas Schwab <schwab@suse.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: fix a lockup regression when using force feedback on a PID deviceAnssi Hannula2008-10-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Commit 8006479c9b75fb6594a7b746af3d7f1fbb68f18f introduced a spinlock in input_dev->event_lock, which is locked when handling input events. However, the hid-pidff driver sleeps when handling events as it waits for reports being sent to the device before changing the report contents again. This causes a system lockup when trying to use force feedback with a PID device, a regression introduced in 2.6.24 and 2.6.23.15. Fix it by extracting the raw report data from struct hid_report immediately when hid_submit_report() is called, therefore allowing drivers to change the contents of struct hid_report immediately without affecting the already-queued transfer. In hid-pidff, re-add the removed usbhid_wait_io() to pidff_erase_effect() instead, to prevent a full report queue from causing the submission to fail, thus not freeing up device memory. pidff_erase_effect() is not called while dev->event_lock is held. Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: make a bus from hid codeJiri Slaby2008-10-141-1/+1
| | | | | | | | | | | | | | | | Make a bus from hid core. This is the first step for converting all the quirks and separate almost-drivers into real drivers attached to this bus. It's implemented to change behaviour in very tiny manner, so that no driver needs to be changed this time. Also add generic drivers for both usb and bt into usbhid or hidp respectively which will bind all non-blacklisted device. Those blacklisted will be either grabbed by special drivers or by nobody if they are broken at the very rude base. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: move wait from hid to usbhidJiri Slaby2008-04-221-1/+2
| | | | | | | Since only place where this is used is usbhid, move it there. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* USB HID: move usbhid code from drivers/usb/input to drivers/hid/usbhidJiri Kosina2007-04-111-0/+87
Separate usbhid code into dedicated drivers/hid/usbhid directory as discussed previously with Greg, so that it eases maintaineance process. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
OpenPOWER on IntegriCloud