Linux-USB Archive on lore.kernel.org
 help / color / Atom feed
From: Harald Welte <laforge@gnumonks.org>
To: linux-usb@vger.kernel.org
Subject: CREAD ignored by almost all USB serial drivers
Date: Sat, 28 Sep 2019 22:49:55 +0200
Message-ID: <20190928204955.GE4247@nataraja> (raw)

[Copied on requst from https://bugzilla.kernel.org/show_bug.cgi?id=205033]

It seems that a lot of Linux kernel USB serial device drivers are
ignoring the CREAD setting of termios.c_cflag.

The man page is quite clear:
       CREAD  Enable receiver.

The glibc man page at
https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_17.html
states:
	"Macro: tcflag_t CREAD
	 If this bit is set, input can be read from the terminal.
	 Otherwise, input is discarded when it arrives."

When I mask this bit and then call tcsetattr(), I'm still receiving
input characters, at least on a pl2303 USB UART.  Looking at the source
code of drivers/usb/serial/, the *only* driver appearing to respect
CREAD is digi_acceleport.c.  All others seem to ignore it.  To the
contrary, most classic serial drivers in drivers/tty/serial seem to
implement it.

In absence of low-level support in individual drivers to actually
disable the receiver in hardware, I would have at least expected the
core tty/serial layer to drop/discard any characters received by the
hardware while CREAD is not set.  But that also doesn't appear to be the
case.

What's even more worrying is that the tcsetattr() call succeeds, i.e. it
is a silent error.  I would expect the kernel to either implement the
functionalty in one way or another, or simply return tcsetattr() with
an error if an unsupported combination (i.e. CFLAG not set) is
configured.

This is not a theoretical issue.  Anyone implementing a half-duplex
protocol with shared Rx and Tx line will face the same issue.

Am I missing something here?  Please don't tell me that I just
discovered something that's broken for some 20-odd years, or at the very
least as far as normal linux.git history reaches back :/

Please keep me in Cc of any responses, I'm not subscribed to linux-usb.

Thanks!

Regards,
	Harald
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

             reply index

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

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:
  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=20190928204955.GE4247@nataraja \
    --to=laforge@gnumonks.org \
    --cc=linux-usb@vger.kernel.org \
    /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

Linux-USB Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-usb/0 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/ https://lore.kernel.org/linux-usb \
		linux-usb@vger.kernel.org
	public-inbox-index linux-usb

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-usb


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git