Received-SPF: pass (google.com: domain of linux-kernel+bounces-1735-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <1b0af20c-8a2c-46ba-ab2e-d598b65fd0c1@gmx.de>
Date: Fri, 15 Dec 2023 23:13:41 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] dt-bindings: serial: rs485: add rs485-mux-gpios
 binding
Content-Language: en-US
To: Christoph Niedermaier <cniedermaier@dh-electronics.com>,
 Crescent CY Hsieh <crescentcy.hsieh@moxa.com>,
 Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Lukas Wunner <lukas@wunner.de>,
 Rasmus Villemoes <linux@rasmusvillemoes.dk>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 Jiri Slaby <jirislaby@kernel.org>, Rob Herring <robh+dt@kernel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
 Conor Dooley <conor+dt@kernel.org>,
 "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
 =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
 "brenda.streiff@ni.com" <brenda.streiff@ni.com>,
 Tomas Paukrt <tomaspaukrt@email.cz>
References: <20231120151056.148450-1-linux@rasmusvillemoes.dk>
 <20231120151056.148450-2-linux@rasmusvillemoes.dk>
 <20231122145344.GA18949@wunner.de>
 <3b8548b1-b8a9-0c9e-4040-5cfda06a85c6@gmx.de>
 <ec66d25162de4cbc92720df1e7008fe8@dh-electronics.com>
 <5c140498-69e3-4187-8703-db0c41e7ca89@gmx.de>
 <fe28eb93-daa1-41af-a005-f21aa87e1984@gmx.de>
 <ZXcJr4VS_uGr_6TV@smile.fi.intel.com>
 <ZXrX4mQXPLum0jL3@moxa-ThinkCentre-M90t>
 <b35730df8288469fbaf67b5ceae4eece@dh-electronics.com>
 <ed087928-43ac-42bc-8e4d-d1632db451b9@gmx.de>
 <cc59c5bb16574073ba8b2bf9bc59bc7c@dh-electronics.com>
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
In-Reply-To: <cc59c5bb16574073ba8b2bf9bc59bc7c@dh-electronics.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:oiUTxF7LW/I=;01gP3CrURX/RACgl6u/hm4kcUjB
 hahsEkwwPDj+bL+6RFpCqdSOUCMivMkVRTBxjBXCIpVDk1YnsY+Qjxcy//vsoC+Fuyuqjyg+v
 qys9FiGDbQ89zVmGl1KNGvYJPEvh5RZg5vYP0H7Nsey1UEc1HlBBYjoS05d3ZdIc52hyElBcV
 F5mFo2FWQrG46ObwtdsfjyLUIlrwH7TezyA571sUx9KGzIezsqUaA9YYjynVF1GyEI3YINU7b
 AC6J9RN2XGw4VKmwucifG5nRw5f0UUrLD1hjxx4HSY+CsEhu2VNKzhM54ibNLHdLlGrrPhdKE
 MRxNxhw2RbHzm+/AT6w6PpoqqMu7qXXdzbyCVm+R5SsrU8jQGtff3+YWXEPin8wk6oP3OlmcE
 J4QesO1qu3rXpFfJrSiOLrQ5bCLwDFNdHQgpmCdJUQLHUCqolHoLVM1QdfJ0DABd6htQAu3cW
 zhOxhcoPwIPTNIjmz/6xeAyN2z3l+m6DwalMwJOgPB+CBuToATIWQnX27UzTFssebTyZUjxx2
 16GkjF0VJoJd3xds1LamQOO2IsMBZbUzNNnSP+TG9p+WornZE4JROYNx5MmcnCZPfr9+TDV+U
 irRGE0Fhnq7Wh0HzB/qBsTopr0QuD2TGrr4HMoLF5XLsciKf6HGfi0XOSo9nocpLhWPo99wwA
 E/OpdfmVOv9lbVZXHCW6oqQuzJZEZGR/4YKDK+ey1m0pDCVwxEkc1bI8bp1y4mGHv/nAupOMJ
 qx0Lh7VhUH6cdjXVj/v9+MBwCj4eiVJvX9OoNbNciq8YitBz9C2bIPVgAh8vCmzRAxPIKmGIu
 nol3VT+rJrVGUJww/OC5nUxPZc14pR1ptI/0c/C8JXWSKHPv8LzElce8R/ZsivwvNbiQEQCty
 5lcomLZeIUOkfD1ESG549A9alZgv7lPHXJN0Qx86feWx88VXOIELXqVyGCE7HmWivFT4tTq0y
 ji57uA==

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 T=
X. 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_S=
END and
RTS_AFTER_SEND flag (only if the driver supports this special RS485 mode, =
of course).

Regards,
Lino