On Fri, 27 Apr 2007, Greg KH wrote:
> > BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
[ .. stacktraces stripped .. ]
> Jiri, any thoughts about this? This looks like it comes from your tree
> as 2.6.21 doesn't have the drivers/hid/usbhid/ directory...
Paul (author of the corresponding patch) added to CC.
This BUG (it's in fact a warning) is this one:
WARN_ON(idVendor == 0);
I now don't immediately see how this could happen - the vendor ID seems to
be propagated properly from hid_probe() (nothing has been changed in this
codepath), so this would mean that hid_probe() has been passed
usb_interface for which
le16_to_cpu(interface_to_usbdev(intf).dev->descriptor.idVendor) is equal
to zero ... and this definitely shouldn't happen for any sane device
(could the original poster please verify with lsusb, just to be 100%
sure?).
It would also help if the original poster, who is able to reproduce this
WARN_ON, would verify whether hid_probe() is really being passed such
strange usb_interface from upper USB layer ... please see the patch below,
and send me the output if possible.
Paul, do you have any idea? In fact, what was your reason for putting this
WARN_ON() there? Did you ever meet any condition when idVendor == 0
appears there?
Thanks.
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index f929dee..2a77d8b 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -984,6 +984,8 @@ static int hid_probe(struct usb_interfac
dbg("HID probe called for ifnum %d",
intf->altsetting->desc.bInterfaceNumber);
+ printk(KERN_DEBUG "DEBUG - hid_probe: idVendor: %x\n",
+
le16_to_cpu(interface_to_usbdev(intf)->descriptor.idVendor));
if (!(hid = usb_hid_configure(intf)))
return -ENODEV;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
