Am 2016-05-27 20:02, schrieb Johan Hovold:
On Fri, May 13, 2016 at 12:17:24PM +0200, mich...@walle.cc 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.
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 ;)
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.
Care to send patches to address this?
yeah, in the near future.
-michael
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
