Bug 205033
| Summary: | CREAD ignored by almost all USB serial drivers | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Harald Welte (laforge) |
| Component: | USB | Assignee: | Greg Kroah-Hartman (greg) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | cajin, hemadd22, isubmitgoodcontent, lokw, phdguidancein, qusovol, selenayoung789, shery41, ucelsanicin |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 5.2.0 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
On Sat, Sep 28, 2019 at 07:00:34PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=205033 > > Bug ID: 205033 > Summary: CREAD ignored by almost all USB serial drivers > Product: Drivers > Version: 2.5 > Kernel Version: 5.2.0 All USB bugs should be sent to the linux-usb@vger.kernel.org mailing list, and not entered into bugzilla. Please bring this issue up there, if it is still a problem in the latest kernel release. (In reply to Greg Kroah-Hartman from comment #1) > All USB bugs should be sent to the linux-usb@vger.kernel.org mailing > list, and not entered into bugzilla. Please bring this issue up there, > if it is still a problem in the latest kernel release. Done: https://marc.info/?l=linux-usb&m=156971819526633&w=2 is the link for reference, in case anyone sees this ticket and wants to see where follow-up is happening. |
It seems that a lot of Linux kernel 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, 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 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 ino 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.