From: Johan Hovold <johan@kernel.org>
To: Janne Huttunen <jahuttun@gmail.com>
Cc: linux-usb@vger.kernel.org,
Peter Hurley <peter@hurleysoftware.com>,
linux-serial@vger.kernel.org
Subject: Re: usbserial / ftdi_sio (+ others) bug?
Date: Wed, 29 Oct 2014 09:51:28 +0100 [thread overview]
Message-ID: <20141029085128.GC7841@localhost> (raw)
In-Reply-To: <CAHdUje_wc+-SwUTDsNHg8HkD2ynJDtOE18VXe5616UpFYyAU0Q@mail.gmail.com>
[ +CC: Peter, linux-serial ]
On Wed, Oct 29, 2014 at 10:07:26AM +0200, Janne Huttunen wrote:
> I own a device that implements a data logging interface using the
> FT232 USB-serial -chip. Very often it happens that connecting the
> associated software with the device requires multiple attempts.
> There seems to be two kinds of issues; either the program reports
> that it did not receive any data or it reports reading lots of
> data, but it was all invalid. I haven't yet looked at the former,
> but I did spend some time investigating the latter.
>
> Simple strace of the program startup showed that when connecting
> fails, the program gets a lot (hundreds) of binary zeros while
> reading the device. I used usbmon to capture the traffic between
> the host and the device and the zeros are not strictly speaking
> coming from the device. However when this problem happens the
> device seems to report quite lot of overruns for a while, which
> was a clue. After a somewhat successful attempt to understand
> the operation of the tty code in Linux, I have a theory.
>
> The usbserial driver sets the TTY_DRIVER_REAL_RAW flag. Based on
> the comment in tty_driver.h this implies that the driver is not
> supposed to report any statuses (including overruns) to ldisc
> if they are ignored by the application (like they are in this
> case). It's just that AFAICS the ftdi_sio subdriver (and many
> others) doesn't seem quite honor this, but seems to report any
> status unconditionally. Also AFAICS this then means that every
> overrun will get converted into single binary zero delivered to
> the application(?). If so, this probably isn't what is supposed
> to happen and would explain the flood of extraneous zeros the
> application was seeing when the connecting failed.
>
> I haven't had yet the time to test this theory, but at least it
> seems plausible to me. Any thoughts, anybody?
You are correct. The usb-serial drivers, and at least some serial
drivers, fail to implement TTY_DRIVER_REAL_RAW correctly in that they
do not honour ((IGNBRK || (!BRKINT && !PARMRK)) && (IGNPAR || !INPCK)).
I'll take a look at the usb-serial drivers.
Having the driver not reporting overrun (and other) errors will
obviously not fix the underlying issue with your device, which is
generating all these errors in the first place.
Thanks,
Johan
next parent reply other threads:[~2014-10-29 8:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAHdUje_wc+-SwUTDsNHg8HkD2ynJDtOE18VXe5616UpFYyAU0Q@mail.gmail.com>
2014-10-29 8:51 ` Johan Hovold [this message]
2014-10-29 9:38 ` usbserial / ftdi_sio (+ others) bug? Janne Huttunen
2014-10-29 11:53 ` Peter Hurley
2014-11-03 21:46 ` Janne Huttunen
2014-11-04 8:14 ` Johan Hovold
2014-11-04 18:29 ` Janne Huttunen
2014-11-05 9:58 ` Johan Hovold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141029085128.GC7841@localhost \
--to=johan@kernel.org \
--cc=jahuttun@gmail.com \
--cc=linux-serial@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peter@hurleysoftware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).