On Sat, 13 Feb 2010, Bruno [UTF-8] Prémont wrote: > On Mon, 08 February 2010 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > Clearly something is setting usbhid->intf to NULL. But I don't see > > any code that would do it. You may have to resort to putting > > printk() statements at various strategic places to find out where it > > happens. You could start with the beginnings and ends of hid_suspend, > > hid_resume, and hid_reset_resume. Maybe also usbhid_disconnect(), > > just in case. > > I did add a few printk()s and WARN_ON()s to get a better idea of > why/when usbhid->intf is NULL and it is already since probe time of the > second interface anounced by the USB keyboard (hid.debug=1): ... > This lets me guess that hid_add_device() is doing something wrong > here when report parsing fails... (as that one is the only one which > could be doing the initialization of usbhid which does work for the > first interface announced by my keyboard) I don't know about doing anything wrong... However it does appear that in this case the interface is registered on the HID bus but doesn't get bound to a driver. Jiri will know whether or not that's the desired outcome. On the other hand, I don't think there would be anything wrong with moving the usbhid->intf = intf; usbhid->ifnum = interface->desc.bInterfaceNumber; lines from usbhid_start() to usbhid_probe(), just before the call to hid_add_device(). It should fix the bug, and those lines do belong in the probe routine. Jiri, any problems with doing this? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
