On Mon, Jun 27, 2011 at 11:07 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 26 Jun 2011, Xiaofan Chen wrote: > >> 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. > > It's worth noting that the solution proposed in that thread (having the > USB serial driver fix the invalid maxpacket value) won't work if the > device is plugged into a USB-3 port. Not without extra help. Thanks. I think maybe it is not worth to fix in the kernel in this case. > The easiest solution might be to replace the buggy, non-compliant > devices. Yes that is the fix in the end. It turns out to be a bug in older version of libftdi to cause EEPROM corruption. http://permalink.gmane.org/gmane.comp.hardware.libftdi.general/1377 -- 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
