On Tue, 12 May 2009, Clemens Ladisch wrote: > David Fries wrote: > > usb_submit_urb returns -22 EINVAL invalid argument as it is trying to > > submit an interrupt packet to what is registered as an isoc endpoint. How does one know which type the endpoint really is? Through prior experience with the device? > > The second interface has the same end point addresses as the first. > > Any suggestions on how to deal with this class of broken hardware? > > > > I:* If#= 0 Alt= 0 ... > > E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=1ms > > I:* If#= 1 Alt= 0 ... > > E: Ad=81(I) Atr=01(Isoc) MxPS= 4 Ivl=1ms > > AFAICS the USB core memorizes the descriptor belonging to a specific > endpoint number whenever usb_set_interface() is called. In this case, > the second interface is initialized later, so the second set of > descriptors wins. > > The driver could call usb_set_interface() again for the first interface > so that the USB core takes notice of the first set of endpoints again. > Please try the patch below. > > I guess I'll have to write another quirk for this. > > > --- linux/sound/usb/usbmidi.c > +++ linux/sound/usb/usbmidi.c > @@ -1779,6 +1779,7 @@ > err = snd_usbmidi_detect_per_port_endpoints(umidi, endpoints); > break; > case QUIRK_MIDI_RAW: > + usb_set_interface(umidi->chip->dev, 0, 0); > umidi->usb_protocol_ops = &snd_usbmidi_raw_ops; > err = snd_usbmidi_detect_per_port_endpoints(umidi, endpoints); > break; This is only a bandaid. The underlying problem is still there. Basically, the second interface shouldn't exist at all. The only proper way to deal with it is to pretend there's only one interface -- which would mean changing the descriptors before the kernel parses them. A much easier approach is to throw the device away and replace it with something that _is_ compliant with the USB specification. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
