>>> However, "uhci-hcd" and "usb-uhci-hcd" did >>>not want to bind the audio driver: reading the config descriptor >>>(in audio.c) stalled rather consistently. That failure was seen >>>with the other USB 1.1 drivers too, but not as consistently. >> >>I have this problem too. It seems that the drivers bind the device >>sometimes, but something else seems wrong. The ohci-hcd driver works >>just fine with the device. I'll play around some more with this to see >>if I can figure out anything > > This seems to be another sideeffect of the queued control urbs by HID/input > and the missing support for that in *uhci*. If I don't have HID loaded, the > binding works.
Didn't work that way for me. In any case, the HID driver would be probed only after the audio driver failed, even if hotplugging kicked in (after all the in-kernel drivers got a whack at the new device). Given that reading those first 8 bytes sometimes failed with the other drivers, I wonder if there's not some hardware quirk kicking in here. Presuming Philips has multiple revisions of their audio hardware, this is not one of the newer ones ... and FWIW it's the same device that has that short-read problem with string descriptors that need N*maxpacket. And yes, ep0 maxpacket is 8 bytes, so this is 1*maxpacket... Let me know if there's some information I can usefully provide. Maybe I'll check whether it's returning the stall after reading 8 bytes; that would indicate it's really the same underlying read-descriptor problem. - Dave _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
