On Tue, 4 Nov 2014 09:14:49 +0100 Johan Hovold <johan@xxxxxxxxxx> wrote: > > 2. The chip responds with single correct character followed by a few > > hundred or so replies containing only the overrun status (no > > data) which are then converted to a bunch of binary zeroes by the > > ldisc because of the bug I mentioned earlier. After that the chip > > starts responding with proper data again and works until closed. > > Note that the only "bug" is that the application cannot disable the > overrun reporting, but why would you want that? The merits of doing so may be debatable, but if using the quotes around "bug" is supposed to indicate that it isn't one, I have to respectfully disagree. I know it is not the most important thing in the world and without the hardware fault I probably would not have seen it at all, but I would still call it a bug. > What's on the other side of the FTDI chip? Some kind of an optical receiver circuit (the link is optically isolated). On the other side of that is then the device that sends periodical data packets (a couple of times per second 17 bytes each) to the computer. The computer doesn't send anything i.e. the tx functionality of the chip is not used at all. > It still sounds like your hardware is broken, but at least you > seem to have found a work-around. Like I said, the hw is the real culprit here, there's no doubt about it. But I also doubt that it's just the individual chip in my device that has this issue. The device is practically brand new and while that is no guarantee that there won't be any faults, I find it much more likely that what I am seeing here is a quirk of the implementation and there are lots of these chips with the same issue out there. The real questions that remain are then; 1. is the chip real or counterfeit and how am I supposed to know it, 2. how much the driver can or even should try to accommodate the quirks of the hw, and 3. does the answer to #2 depend on the answer to #1. > Perhaps you can report it to the logging-device (?) manufacturer > or FTDI. Sure, if I can find someone that cares, which is doubtful. > What is the "lsusb -v" output for your device by the way. Bus 002 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 6.00 iManufacturer 1 FTDI iProduct 2 FT232R USB UART iSerial 3 A400EJPK bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 90mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 FT232R USB UART Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html