On Sat, 28 Apr 2007, Vincent ETIENNE wrote: > > No, it isn't a problem in the USB core. The device itself is messed up; > > it really does report idVendor and idProduct both equal to 0. > So is it just a scary trace but without consequence that i could ignored > ? May i ask you what is the device which is messed up ? ( Maybe should i > change it ? )
Hi Vincent, yes, the device is messed up, but it shouldn't have any consequences for you - the HID driver is able to correctly handle that, so as soon as we don't need to add any extra quirks for such device, everything should be fine. I have removed the WARN_ON from the code in my tree. I think we still don't want users to add quirks for such broken devices (as it would collide with hid_blakclist[] terminator), so I have left the initial condition in usbhid_modify_dquirk() untouched. From: Jiri Kosina <[EMAIL PROTECTED]> USB HID: don't warn on idVendor == 0 It turns out that there are broken devices out there that incorrectly report VID/PID as 0x000, see http://lkml.org/lkml/2007/4/27/496 Therefore we should not confuse users by dumping warnings and stacktraces in such situation. It is not possible to add quirks for such horribly broken devices, but currently that's not needed. Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c index 27188bd..17a8755 100644 --- a/drivers/hid/usbhid/hid-quirks.c +++ b/drivers/hid/usbhid/hid-quirks.c @@ -477,8 +477,6 @@ static struct hid_blacklist *usbhid_exis struct quirks_list_struct *q; struct hid_blacklist *bl_entry = NULL; - WARN_ON(idVendor == 0); - list_for_each_entry(q, &dquirks_list, node) { if (q->hid_bl_item.idVendor == idVendor && q->hid_bl_item.idProduct == idProduct) { - 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/
