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]

Message-ID: <ca3374724da24e38b611c24fb4fd57d1@dh-electronics.com>
Date: Mon, 18 Dec 2023 09:08:15 +0000
From: Christoph Niedermaier <cniedermaier@...electronics.com>
To: Lino Sanfilippo <LinoSanfilippo@....de>, 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

From: Lino Sanfilippo [mailto:LinoSanfilippo@....de]
Sent: Friday, December 15, 2023 11:14 PM
> 
> Hi Christoph,
> 

Hi Lino,

> 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?

Yes, for the RS-485 (4-wire) master it isn't needed, but I think on the driver
level it is better not to distinguish between master and salve. So use also RTS
control for enabling sending on a RS-485 (4-wire) master device.

> 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).

No, I think it shouldn't configure in userspace. Treating a RS-485 (4-wire) master
device in the driver as a slave (with RTS control) has the following advantages:
- Less confusion in user space (no additional setting available).
- Only bus topology determines who is master and salve.
- Save energy, because DE is only driven during sending.


Regards
Christoph