- 25 2月, 2013 2 次提交
-
-
由 Benjamin Tissoires 提交于
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>
-
由 Benjamin Tissoires 提交于
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>
-
- 20 7月, 2012 1 次提交
-
-
由 Alan Stern 提交于
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>
-
- 30 3月, 2012 1 次提交
-
-
由 Oliver Neukum 提交于
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>
-
- 21 12月, 2011 2 次提交
-
-
由 Daniel Kurtz 提交于
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>
-
由 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>
-
- 23 12月, 2010 1 次提交
-
-
由 Oliver Neukum 提交于
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>
-
- 14 9月, 2010 1 次提交
-
-
由 Guillaume Chazarain 提交于
My macbook infrared remote control was broken by commit bd25f4dd ("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: NGuillaume Chazarain <guichaz@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 21 5月, 2010 1 次提交
-
-
由 Alan Stern 提交于
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: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 12 2月, 2010 1 次提交
-
-
由 Oliver Neukum 提交于
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: NOliver Neukum <oliver@neukum.org> Signed-off-by: NDavid Fries <david@fries.net> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 26 3月, 2009 1 次提交
-
-
由 Oliver Neukum 提交于
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: NOliver Neukum <oneukum@suse.de> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 04 1月, 2009 1 次提交
-
-
由 Jiri Slaby 提交于
Move usbhid specific flags from global hid.h into local usbhid.h. Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 23 11月, 2008 1 次提交
-
-
由 Jiri Slaby 提交于
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: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 27 10月, 2008 1 次提交
-
-
由 Jiri Slaby 提交于
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=11827Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Andreas Schwab <schwab@suse.de> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 15 10月, 2008 2 次提交
-
-
由 Anssi Hannula 提交于
Commit 8006479c 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: NAnssi Hannula <anssi.hannula@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Jiri Slaby 提交于
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: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 22 4月, 2008 1 次提交
-
-
由 Jiri Slaby 提交于
Since only place where this is used is usbhid, move it there. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 11 4月, 2007 1 次提交
-
-
由 Jiri Kosina 提交于
Separate usbhid code into dedicated drivers/hid/usbhid directory as discussed previously with Greg, so that it eases maintaineance process. Signed-off-by: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 22 1月, 2007 1 次提交
-
-
由 Anssi Hannula 提交于
The commit 4916b3a5 introduced a hid regression between 2.6.19 and 2.6.20-rc1. The device put in input_dev->cdev is now of type usb_device instead of usb_interface. Before: > # readlink -f /sys/class/input/input6/event4/device > /sys/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.1 After: > # readlink -f /sys/class/input/input3/event3/device > /sys/devices/pci0000:00/0000:00:10.0/usb1/1-1 This causes breakage: > # udevinfo -q all -n /dev/input/event3 > P: /class/input/input3/event3 > N: input/event3 > S: input/by-path/pci-1-1--event- > E: ID_SERIAL=noserial > E: ID_PATH=pci-1-1- No ID_MODEL, ID_VENDOR, ID_REVISION, ID_TYPE etc etc. Fix this by assigning the intf->dev into hid->dev, and fixing all the users. Signed-off-by: NAnssi Hannula <anssi.hannula@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 09 12月, 2006 1 次提交
-
-
由 Jiri Kosina 提交于
- 'dev' in struct hid_device changed from struct usb_device to struct device and fixed all the users - renamed functions which are part of USB HID API from 'hid_*' to 'usbhid_*' - force feedback initialization moved from common part into USB-specific driver - added usbhid.h header for USB HID API users - removed USB-specific fields from struct hid_device and moved them to new usbhid_device, which is pointed to by hid_device->driver_data - fixed all USB users to use this new structure Signed-off-by: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-