On Wed, Jun 29, 2016 at 11:59:06PM +0200, Michael Walle wrote: > Am 2016-05-27 20:02, schrieb Johan Hovold: > > 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? Yeah, that's not right 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. I had a change to take a closer look at this today, and just submitted a patch that should fix this. Only processing break and error status for packets with status payload avoids over-reporting break and error conditions. > What comes directly to my mind is the handling of the break condition. > Can't look into that at the moment. But if break conditions are > translated into status-only packets, how are two consecutive breaks > recognized. Ie. if the break condition flag is sticky (until a new > character is received) you can't determine if its one or more. But maybe > we are lucky and the chip will send some different pattern. If only > there were some specs ;) Specs would be nice... Through experimentation I found that these flags are always first reported for packets with data payload (NULL in case of break) which seems to make sense. > > 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. > > Well, I've already tried a soft reset with no success. So I doubt there > is any solution. Seems like a soft reset doesn't reset the internal > state entirely. I can confirm that. Specifically, it does not seem to clear the LSR and holding registers, so an overrun along with the final character received is still reported if an overrun occurs while the port is closed. 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
