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]
Message-ID: <1b0af20c-8a2c-46ba-ab2e-d598b65fd0c1@gmx.de>
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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ