linux-kernel - RE: [PATCH] serial: Revert RS485 polarity change on UART open

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 29 Mar 2022 13:19:25 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Matthias Schiffer' <matthias.schiffer@...tq-group.com>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
        "Lino Sanfilippo" <LinoSanfilippo@....de>,
        Lukas Wunner <lukas@...ner.de>
Subject: RE: [PATCH] serial: Revert RS485 polarity change on UART open

From: Matthias Schiffer
> Sent: 29 March 2022 14:03
> 
> On Tue, 2022-03-29 at 12:55 +0000, David Laight wrote:
> > From: Matthias Schiffer
> > > Sent: 29 March 2022 11:39
> > ...
> > > I guess that would work. The fact that even the different
> > > variants of the 8250 are implemented inconsistently makes this
> > > especially ugly... It certainly puts a damper on the efforts to
> > > make
> > > the handling of RS485 in serial drivers more generic.
> >
> > One thing to remember is that RS232 (IIRC really V.38) line driver
> > chips are typically inverting.
> >
> > So the modem signals on a TTL level output will have the
> > opposite polarity to that required on the actual connector.
> >
> > Normally a UART will have an 'active high' register bit for
> > a modem signal that drives and 'active low' pin so you get
> > the correct polarity with an inverting line driver.
> >
> > 	David
> >
> 
> Indeed. As far as I can tell, this property of UARTs is what got us
> into this mess: Some people interpreted SER_RS485_RTS_ON_SEND as "set
> the RTS flag in the MCR register on send", while other thought it
> should mean "set the RTS pin to high on send", leading to opposite
> behaviours in different UART drivers (and even different UART variants
> in the same driver, in the case of the 8250 family).

Hmmm... A complete mess.
The 'RTS pin' that needs to go high is the one on the (typically) 'D'
connector after the inverting line driver.
Not the pin on the uart package.
I'd expect TTL level serial interfaces to require active low
modem signals.

If RS485 is trying to do half duplex using RTS (request to send)
and CTS (clear to send) you've typically got bigger problems
than asserting RTS before a transmit.
The real problem is removing RTS once the last transmit data bit
(the stop bit) has left the UART pin.
I've used local loopback (tx to rx) to detect that in the past.

Of course, if it is just doing flow control that should use RFS
(ready for sending) to indicate space in the receive fifo but
using the RTS pin instead that is a different matter.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)