Jeremy Robertson reports that GTCO engineers made a mistake and we don't
need 0x60x GTCO product ids blacklisted.
This mostly reverts dda3fd35, but leaves PID 0x1007 intact.
Reported-by: Jeremy Roberson <jeremy.roberson@einstruction.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
I have people whining about using these headers in userspace, and they have
__KERNEL__ markings which implies they're supposed to be exported. I also
added the required linux/types.h include to hidraw.h since it uses the __u##
kernel types.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Cc: Jiri Kosina <jikos@jikos.cz>
Cc: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is no need to keep a few years old ThrustMaster force-feedback
driver as experimental.
HID_FF is currently marked experimental anyway, so this is even redundant.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is a window:
task A task B
spin_lock_irq(&usbhid->inlock); /* Sync with error handler */
usb_set_intfdata(intf, NULL);
spin_unlock_irq(&usbhid->inlock);
usb_kill_urb(usbhid->urbin);
usb_kill_urb(usbhid->urbout);
usb_kill_urb(usbhid->urbctrl);
del_timer_sync(&usbhid->io_retry);
cancel_work_sync(&usbhid->reset_work);
if (!hid->open++) {
res = usb_autopm_get_interface(usbhid->intf);
if (res < 0) {
hid->open--;
return -EIO;
}
}
if (hid_start_in(hid))
if (hid->claimed & HID_CLAIMED_INPUT)
hidinput_disconnect(hid);
in which an open() to an already disconnected device will submit an URB
to an undead device. In case disconnect() was called by an ioctl, this'll
oops. Fix by introducing a new flag and checking it in hid_start_in().
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch makes the following needlessly global functions static:
- hid-core.c:hid_input_field()
- usbhid/hid-quirks.c:usbhid_modify_dquirk()
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The numbered reports need to be passed properly to hidraw (i.e. with the first
data field indicating the report number), otherwise userspace has no idea
about the identification of the report.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This moves the misplaced rdesc quirk to the place where it belongs.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
To check paramters even if debug is disabled, convert dbg_hid
to inline function with __attribute__(format) checking.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fix these sparse warnings:
.../hid/hid-core.c:100:15: warning: incorrect type in assignment (different signedness)
.../hid/hid-core.c:100:15: expected signed int [usertype] *value
.../hid/hid-core.c:100:15: got unsigned int *<noident>
by unsigned -> s32
.../hid/hid-input-quirks.c:336:10: warning: Using plain integer as NULL pointer
by 0 -> NULL
.../hid/usbhid/hid-core.c:786:46: warning: incorrect type in argument 3 (different signedness)
.../hid/usbhid/hid-core.c:786:46: expected int *max
.../hid/usbhid/hid-core.c:786:46: got unsigned int *<noident>
.../hid/usbhid/hid-core.c:787:47: warning: incorrect type in argument 3 (different signedness)
.../hid/usbhid/hid-core.c:787:47: expected int *max
.../hid/usbhid/hid-core.c:787:47: got unsigned int *<noident>
.../hid/usbhid/hid-core.c:788:48: warning: incorrect type in argument 3 (different signedness)
.../hid/usbhid/hid-core.c:788:48: expected int *max
.../hid/usbhid/hid-core.c:788:48: got unsigned int *<noident>
by int -> unsigned int
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Currently using debug=1 with hid module prints out all sent and received
reports to the kernel log, while in many cases we only want to see the
report descriptors and hid-input mappings that are printed when a device
is probed.
Add new level debug=2, and only dump the report traffic with that level.
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This must be the weirdest failure yet. My external disk stops processing
the storage commands the moment it receives a GET_REPORT. The firmware
does not crash; if I do rmmod hid, then SET-INTERFACE restores normal
operations. Still, I cannot live without the keyboard when I want backup
my files. Adding the NOGET quirk fixes this problem for me.
Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This device has reports lower logical maximum compared to the real
usages for Zoom+ and Zoom- it emits.
This patch bumps the values in the report descriptor up, and also
adjusts HID_MAX_USAGE accordingly.
Reported-by: Khelben Blackstaff <eye.of.the.8eholder@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Microsoft's wireless desktop receiver (Model 1028) has a bug in the report
descriptor -- namely, in four seperate places it uses USAGE_MIN and _MAX when
it quite obviously doesn't intend to.
In other words, it reports that it has pretty much _everything_ in 'consumer'
and 'generic desktop'. And then the X evdev driver believes I have a mouse
with 36 absolute axes and a huge pile of keys and buttons, when I in fact,
should have zero. 255/256 in three of the cases, and 0-1024 in another.
This patch fixes the report descriptor of this device before it enters the HID
parser.
Signed-off-by: Jim Duchek <jim.duchek@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Many vendors highspeed devices give erroneously fullspeed interval value in
endpoint descriptor for interrupt endpoints. This quirk fixes up that by
recalculating the right value for highspeed device.
At the time of hid configuration this quirk calculates which highspeed interval
value gives same interval delay as, or next smaller then, what it would be if
the original value would be interpreted as fullspeed value. In subsequent urbs
that new value is used instead.
Forming the 'hid->name' in usb_hid_config() was moved up to accommodate more
descriptive printk reporting the fixup.
In this patch the quirk is set for one such device: Afatech DVB-T 2 infrared
HID-keyboard. It reports value 16 which means 4,069s in highspeed while
obviously 16ms was intended. In this case quirk calculates new value to be 8
which gives when interpreted as highspeed value 16ms as wanted. The behavior of
the device was verified to be what expected both before and after the patch.
Signed-off-by: Pekka Sarnila <sarnila@adit.fi>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
IB/ipath: Correct capitalization "IntX" -> "INTx"
IB/ipath: Remove tests of PCI_MSI in ipath_iba7220.c
IB/ipath: Remove dependency on PCI_MSI || HT_IRQ
IB/ipath: Build IBA7220 code unconditionally
IB/ipath: Remove reference to dev->class_dev
IB/ipath: Fix module parameter description for disable_sma
RDMA/nes: Remove unneeded function declarations
Fix up conflict in drivers/infiniband/hw/ipath/ipath_verbs.c (by picking
the solution from the infiniband branch)
The PCI MSI interface is stubbed out properly so that all the
functions just return failure if PCI_MSI=n, so there's no reason to
have "#ifdef CONFIG_PCI_MSI" blocks in ipath_iba7220.c.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Before IBA7220 support was added, the ipath driver didn't support any
hardware unless PCI_MSI and/or HT_IRQ was enabled. However, the
IBA7220 can generate INTx interrupts, so it makes sense to allow the
driver to be build even if PCI_MSI=n and HT_IRQ=n.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
The new IBA7220 code added a call to ipath_init_iba7220_funcs() that
is compiled unconditionally, but only built the IBA7220 code if
PCI_MSI is enabled. Fix this by building the IBA7220 file
unconditonally.
This fixes build breakage when PCI_MSI=n, HT_IRQ=y and
INFINIBAND_IPATH=y reported by Ingo Molnar <mingo@elte.hu>:
drivers/built-in.o: In function `ipath_init_one':
ipath_driver.c:(.devinit.text+0x1e5bc): undefined reference to `ipath_init_iba7220_funcs'
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Commit 124b4dcb ("IB/ipath: add calls to new 7220 code and enable in
build") inadvertently added core to set dev->class_dev.dev back into
ib_ipath. This is completely redundant since commit 1912ffbb ("IB: Set
class_dev->dev in core for nice device symlink"), which removed
class_dev setting from low-level drivers, and also will break the build
when class_dev is removed completely from struct ib_device.
Signed-off-by: Roland Dreier <rolandd@cisco.com>