On Sun, Mar 2, 2008 at 11:02 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sat, 1 Mar 2008, Greg KH wrote: > >> > > > In the SnoopyPro dump of the windows driver, the SELECT_CONFIGURATION call >> > > > has MaximumPacketSize = 0x40, the same for both pipes. As a software >> > > > workaround, would it be safe to modify the usb_endpoint_descriptor for the >> > > > device inside the ftdi_sio driver? >> > > >> > > Hm, what a hack :( >> > >> > The USB core already contains similar hacks. Provided the descriptor >> > is changed before any URBs are submitted to the endpoint, there >> > shouldn't be any trouble. >> >> Should we create a new "quirk" for this kind of thing? PCI has logic >> that supports fixing up the device before any driver gets ahold of it, I >> don't see why we couldn't do the same for USB. > > We could. Or we might not even need a special flag; the core could > automatically fix up invalid bulk maxpacket values. For high speed the > maxpacket must be 512; for full speed it can be either 8, 16, 32, or > 64. Setting it to 64 would be a reasonable default. > I know this is an old thread but there is just a discussion on this topic in the libftdi mailing list. The OP there has such a device with wMaxPacketSize=0 for EP1 IN (should be 0x40). http://comments.gmane.org/gmane.comp.hardware.libftdi.general/1369 As per this thread ( http://marc.info/?t=120423246300011&r=1&w=2 ), there is supposed to be a patch but I could not find such a patch. -- Xiaofan -- 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