linux-kernel - Re: [PATCH 1/2] dt-bindings: serial: rs485: add rs485-mux-gpios binding

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: Thu, 21 Dec 2023 16:53:05 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Christoph Niedermaier <cniedermaier@...electronics.com>
Cc: Crescent CY Hsieh <crescentcy.hsieh@...a.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Lino Sanfilippo <LinoSanfilippo@....de>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jirislaby@...nel.org>, Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	"brenda.streiff@...com" <brenda.streiff@...com>,
	Tomas Paukrt <tomaspaukrt@...il.cz>
Subject: Re: [PATCH 1/2] dt-bindings: serial: rs485: add rs485-mux-gpios
 binding

On Thu, Dec 14, 2023 at 01:41:47PM +0000, Christoph Niedermaier wrote:
> I will summarize the current situation from my point of view, maybe it helps:
> 
> RS-232:
>   - Full Duplex Point-to-Point connection
>   - No transceiver control with RTS
>   - No termination
>   - No extra struct in use
> 
> RS-422:
>   - Full Duplex Point-to-Point connection
>   - No transceiver control with RTS needed
>   - Termination possible
>   - Extra struct serial_rs485 needed if termination is used
>  => RS-422 can be used in RS-232 operation, but if a termination should be
>     switchable the RS485 flag has to be enabled. But then also transceiver
>     control will be enabled. Not a very satisfying situation.

Well why don't we just allow enabling or disabling RS-485 termination
independently from the SER_RS485_ENABLED bit in struct serial_rs485?

Just let the user issue a TIOCSRS485 ioctl to toggle termination even
if in RS-232 mode and use that mode for RS-422.

Looks like the simplest solution to me.


> RS-485 (2-wire) very common:
>   - Half Duplex RS-485 bus
>   - Transceiver control with RTS is needed
>   - Termination possible
>   - Extra struct serial_rs485 is needed
>  => RS-485 has to be enabled and configured:
>     - Set SER_RS485_ENABLED 
>     - Set SER_RS485_RTS_ON_SEND or SER_RS485_RTS_AFTER_SEND
>     - Set/clear SER_RS485_RX_DURING_TX depending on whether
>       the receiver path should be on or off during sending.
>       If it's set it allows to monitor the sending on the bus
>       and detect whether another bus device is transmitting
>       at the same time.
>     - Set/clear SER_RS485_TERMINATE_BUS for bus termination.
> 
> RS-485 (4-wire) little used:
>   - Full Duplex RS-485 bus
>   - Transceiver control with RTS is needed
>   - Termination possible
>   - Extra struct serial_rs485 is needed
>  => RS-485 has to be enabled and configured:
>     - Set SER_RS485_ENABLED 
>     - Set SER_RS485_RTS_ON_SEND or SER_RS485_RTS_AFTER_SEND
>     - Set SER_RS485_RX_DURING_TX, as the receiver should always
>       be enabled independently of TX, because TX and RX are
>       separated from each other by their own wires.
>     - Set/clear SER_RS485_TERMINATE_BUS for bus termination.

Thanks for that overview, I found it very helpful.

One small addendum:  Hardware flow control.  Only possible with
RS-232.  Doesn't work in any of the other modes, right?

Thanks,

Lukas