linux-kernel - Re: [PATCH 1/7] serial: 8250_dwlib: RS485 HW half duplex support

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:   Wed, 9 Mar 2022 09:52:36 +0100
From:   Lukas Wunner <lukas@...ner.de>
To:     Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc:     linux-serial <linux-serial@...r.kernel.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Johan Hovold <johan@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Raymond Tan <raymond.tan@...el.com>,
        Heiko Stuebner <heiko@...ech.de>, Rob Herring <robh@...nel.org>
Subject: Re: [PATCH 1/7] serial: 8250_dwlib: RS485 HW half duplex support

On Mon, Mar 07, 2022 at 12:54:19PM +0200, Ilpo Järvinen wrote:
> I don't have strong opinion on the actual names myself (every RS-485 
> transceivers I've come across name their pins to DE and RE).

It's true that transceiver datasheets usually call these pins DE and RE,
but on the UART side, by convention the RTS pin is used to drive DE.

And RTS is then either asserted/deasserted in software (by the kernel
driver), or by the UART hardware if it's capable of it.

Hence the properties in Documentation/devicetree/bindings/serial/rs485.yaml
and the members in struct serial_rs485 refer to "rts".  It's synonymous
to DE.  I suppose Synopsys wanted to afford the integrator of the IP core
as much freedom as possible and therefore offers separate RTS+DE pins
as well as an RE pin.  But that degree of freedom also leads to confusion,
particularly if firmware might mux the pins in an unexpected way
behind the OS's back.

The RE pin of transceivers is usually either pulled-up (i.e. always
asserted, full-duplex) or connected to negated RTS (half-duplex).
A lot of transceivers have a !RE pin so RTS can be wired directly
to DE and !RE.

Full-duplex is primarily for RS-422.  If full-duplex is enabled with
RS-485, you'll receive your own echo, which is often (but not always)
undesirable (depends on the application).

For simplicity and consistency, it is best if the existing properties
defined in rs485.yaml are used, instead of defining new ones which
have the same meaning.  For this reason I'd recommend using
rs485-rts-active-low for the polarity of the DE pin.

> What I think is more important though, is that RE would be by default
> active low which matches to about every RS485 transceiver expectations.
> Given what device_property_read_bool does when the property is missing,
> it would make sense to have the property named as -active-high but I
> don't know if that breaks some dt naming rule to have them opposites
> of each other like that?

That's a good point, I agree.  I don't think that would violate any
DT naming rule.

Thanks,

Lukas