Linux-USB Archive on
 help / color / Atom feed
From: Greg KH <>
To: Harald Welte <>
Subject: Re: CREAD ignored by almost all USB serial drivers
Date: Tue, 8 Oct 2019 17:34:38 +0200
Message-ID: <> (raw)
In-Reply-To: <20191007131852.GN3821@nataraja>

On Mon, Oct 07, 2019 at 03:18:52PM +0200, Harald Welte wrote:
> Hi Greg,
> On Mon, Oct 07, 2019 at 01:06:33PM +0200, Greg KH wrote:
> > On Sat, Sep 28, 2019 at 10:49:55PM +0200, Harald Welte wrote:
> > > It seems that a lot of Linux kernel USB serial device drivers are
> > > ignoring the CREAD setting of termios.c_cflag.
> >
> > You just discovered something that has been broken since the first
> > usb-serial driver was written, all those years ago :)
> Amazing and frightening at the same time.  I would have expected
> somebody had built something like a hardware test fixture to test those
> drivers during all those decades.  Something like a "well-known" serial
> device as the tester, attaching to all the handshake etc. lines of the
> "device under test" and then running through many of the possible
> settings from HW to SW flow control, baud rate, parity, number of stop
> bits, break characters, etc.

I had a tester that was just a loopback device.  Amazing what just a
simple device like that found over time, these things barely work :)

Anyway, yes, a "real" test setup like this would be great to have, I
don't know of one around anywhere, and if you use it, I am sure you will
find lots of issues.  Turns out almost all usb-serial devices are used
for "basic" rx/tx stuff, all of the "fancy" serial things just are not
all that common anymore given that serial is not the primary way data is
transferred anymore.

> I have no shortage of projects to work on, but if somebody else was
> interested to host a physical setup with many different [USB] serial
> ports and some CI around, I might be tempted to build the actual tester
> hardware and some test suite software for it.

Would be nice to see :)

> > I did add support for this to the digi driver, as you saw, as the
> > hardware had support for it.  For everything else, they are all just
> > dumb uarts and do not expose that information to the host computer and I
> > think everyone just forgot about this option.
> I am aware that many USB serial adapters are rather "dumb", hence my suggestion
> to add a related option to the core usb-serial, or even to the core tty/serial
> layer: If the driver doesn't process CREAD, simply discard the received bytes
> at this common/shared layer.

Yes, that could be done in the usb-serial core probably.

> > Given that you are the first to report it that I can think of, I don't
> > think very many people use half-duplex protocols with a shared Rx/Tx
> > (which is crazy anyway...)
> Every smart card interface [1] on this planet, including every SIM card in every
> mobile phone uses such a setup: asynchronous half-duplex communication with
> shared Rx/Tx.  Sure, not many people attach something like that to a USB-Serial
> adapter (as oppose to a USB-CCID reader), but I just wanted to clarify
> it's not as obscure as one may think.  You can actually buy
> ultra-low-cost SIM card readers built that way.
> Also, I would assume that RS-485 is still used in lots of technology,
> including e.g. DMX and industrial control systems.  Unless you go for a
> rather obscure 4-wire RS-485, then you have the same half-duplex
> operation on shared medium.  Please note that USB-RS485 adapters exist,
> using a variety of USB-serial chipsets.

485 just got added to some tty drivers recently, so yes, it is used, but
not all that common it seems.  Or maybe it is and everyone "knows" to
buy the one good device that supports it.


greg k-h

      reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-28 20:49 Harald Welte
2019-10-07 11:06 ` Greg KH
2019-10-07 13:18   ` Harald Welte
2019-10-08 15:34     ` Greg KH [this message]

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-USB Archive on

Archives are clonable:
	git clone --mirror linux-usb/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-usb linux-usb/ \
	public-inbox-index linux-usb

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone