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: Fri, 15 Dec 2023 23:13:41 +0100
From: Lino Sanfilippo <LinoSanfilippo@....de>
To: Christoph Niedermaier <cniedermaier@...electronics.com>,
 Crescent CY Hsieh <crescentcy.hsieh@...a.com>,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Lukas Wunner <lukas@...ner.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

Hi Christoph,

On 14.12.23 15:50, Christoph Niedermaier wrote:

>
> I think we don't need to distinguish, because for a full duplex RS-485
> transceiver also needs RTS control. For example look at the full duplex
> RS-485 transceiver ADM3491E [1]. It's a full duplex transceiver (A/B and Z/Y)
> that has DE (Driver enable) and DI (Driver Input) pins for controlling TX. I
> think the RS-485 master doesn't need it. The DE pin could also be set
> permanently high. But if we have more than one RS-485 slaves it's needed to
> avoid blocking of each other on the receiving wires of the RS-485 master.
>

Thanks for the explanation. So while still needed for the slaves, in case of the
RS485 master the RTS control is not needed, right? Is this something that userspace
should be able to configure? It could be set by clearing both the RTS_ON_SEND and
RTS_AFTER_SEND flag (only if the driver supports this special RS485 mode, of course).

Regards,
Lino