On Fri, May 13, 2016 at 12:17:24PM +0200, michael@xxxxxxxx wrote: > Hi, > > if the internal buffer is full, a read() returns a steady stream of > zeros until one valid character is received. According to my experiments > this happens if the FT232 receives characters while the device is not > opened. After the 257th byte the device returns overrun errors, which > are translated to zero bytes (with TTY_OVERRUN flag set). The 257 bytes > makes sense because the internal RX FIFO is 256 bytes and there is room > for one more byte in the receive register, before the overrun occurs. > Unfortunately, this happens until one (valid?) character is received. > > The FT232RL seems to set the overrun flag and only clears it on the next > received character. This flag is polled every $poll_interval > microseconds and for each single poll there is one zero character placed > in the tty buffer (and the overrun error is incremented). > Before commit cc01f17d5 (USB: ftdi_sio: re-implement read processing) > there was a similar note in the driver: > > /* if a parity error is detected you get status packets forever > until a character is sent without a parity error. > This doesn't work well since the application receives a > never ending stream of bad data - even though new data > hasn't been sent. Therefore I (bill) have taken this out. > However - this might make sense for framing errors and so on > so I am leaving the code in for now. > */ > > So I guess this is still true for the parity error, but in this case > there will be no character inserted into the tty buffer. Only the > counter will be incremented indefinitely. I guess this is not the > correct behaviour, either? > > The first byte of the status packet is compared to a saved > "prev_status", maybe we should do the same for the second byte, too? > > Btw. this does not happen if, the adapter is plugged in for the first > time. I see that the open causes issues a reset, I guess this doesn't > reset this error condition. Thanks for reporting this. It sounds like we need to ignore the errors on status-only packets, possibly after checking for changes. Might be a second issue since you say you can set the device in an error state which is not cleared when later opening the port. Care to send patches to address this? I'm afraid I won't be able to look at this myself for the next couple of weeks at least. Thanks, Johan -- 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
