From: Christoph Niedermaier <cniedermaier@dh-electronics.com>
To: Crescent CY Hsieh <crescentcy.hsieh@moxa.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Lino Sanfilippo <LinoSanfilippo@gmx.de>
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>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"brenda.streiff@ni.com" <brenda.streiff@ni.com>,
"Tomas Paukrt" <tomaspaukrt@email.cz>
Subject: RE: [PATCH 1/2] dt-bindings: serial: rs485: add rs485-mux-gpios binding
Date: Thu, 14 Dec 2023 13:41:47 +0000 [thread overview]
Message-ID: <b35730df8288469fbaf67b5ceae4eece@dh-electronics.com> (raw)
In-Reply-To: <ZXrX4mQXPLum0jL3@moxa-ThinkCentre-M90t>
From: Crescent CY Hsieh <crescentcy.hsieh@moxa.com>
Sent: Thursday, December 14, 2023 11:25 AM
> On Mon, Dec 11, 2023 at 03:07:59PM +0200, Andy Shevchenko wrote:
>> On Sat, Dec 09, 2023 at 12:47:47PM +0100, Lino Sanfilippo wrote:
>>> On 06.12.23 16:42, Lino Sanfilippo wrote:
>>
>>>>>>> Crescent CY Hsieh (+cc) is in parallel trying to add an RS-422 mode bit
>>>>>>> to struct serial_rs485:
>>>>>>>
>>>>>>> https://lore.kernel.org/all/20231121095122.15948-1-crescentcy.hsieh@moxa.com/
>>>>>>>
>>>>>>
>>>>>> That new flag was suggested by me instead of using SER_RS422_ENABLED, which
>>>>>> would mostly be redundant to SER_RS485_ENABLED.
>>>
>>> A cleaner solution would probably be to not handle RS422 with the RS485 settings at
>>> all, but to introduce another set of ioctls to set and read it.
>>>
>>> An own RS422 structure like
>>>
>>> struct serial_rs422 {
>>> __u32 flags;
>>> #define SER_RS422_ENABLED (1 << 0)
>>> #define SER_RS422_TERMINATE_BUS (1 << 1)
>>> };
>>>
>>>
>>> could be used as the parameter for these new ioctls.
>>>
>>> Any comments on this?
>>
>> I have (maybe not so constructive) a comment. Please, at all means try to not
>> extend the existing serial data structures, we have too many ones with too many
>> fields already. For user space, though, one may use unions and flags, but for
>> internal ones it might be better ways, I think.
>
> How about revising the name of 'TIOCSRS485' and 'serial_rs485' to a
> general one, and put RS422 and RS485 configuration flags into that
> structure?
>
> So that in userspace it could set RS422 or RS485 configurations using a
> single ioctl command and one structure.
>
> In this way, it won't be confused in userspace and won't add new data
> structure internally as well.
>
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.
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.
I think the GPIOs reflect the flag states and are meaningful:
- SER_RS485_TERMINATE_BUS: Switch bus termination on/off by GPIO
- SER_RS485_RX_DURING_TX: Used to enable/disable RX during TX
in hardware by GPIO (for 2-wire)
- SER_RS485_ENABLED: Muxing between RS-232 and RS-485 by GPIO
Switching RS-485 on during boot could also be handled by a devicetree
overlay. Evaluate the GPIO and load a DTO accordingly before booting.
Please correct me if I have misrepresented something...
If I looked at it in this new way, I would discard my idea with the
FULL_DUPLEX and HALF_DUPLEX. For a better use of RS-422 it would be
good to disable transceiver control via RTS. It can be done by clearing
the existing flags SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND
at the same time, but I think it is confusing. Better would be a flag
for RS-422:
RS-422: Set SER_RS422_MODE for disabling
transceiver control via RTS.
RS-485 (2-wire and 4-wire): Clear SER_RS422_MODE for enabling
transceiver control via RTS.
Finally, at present it is also not possible to distinguish between RS485
2-wire and 4-wire operation. I think it isn't necessary, as different
hardware has to be used anyway. The hardware then determines the
configuration, see above.
Regards
Christoph
next prev parent reply other threads:[~2023-12-14 13:50 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-20 15:10 [PATCH 0/2] serial: add rs485-mux-gpio dt binding and support Rasmus Villemoes
2023-11-20 15:10 ` [PATCH 1/2] dt-bindings: serial: rs485: add rs485-mux-gpios binding Rasmus Villemoes
2023-11-21 7:52 ` Krzysztof Kozlowski
2023-11-21 8:27 ` Rasmus Villemoes
2023-11-21 8:34 ` Krzysztof Kozlowski
2023-11-21 9:28 ` Rasmus Villemoes
2023-11-22 18:00 ` Krzysztof Kozlowski
2023-11-22 14:53 ` Lukas Wunner
2023-11-23 10:07 ` Rasmus Villemoes
2023-11-23 10:38 ` Lukas Wunner
2023-11-23 13:48 ` Rasmus Villemoes
2023-11-25 23:40 ` Lino Sanfilippo
2023-11-27 12:14 ` Christoph Niedermaier
2023-12-06 15:42 ` Lino Sanfilippo
2023-12-07 12:35 ` Andy Shevchenko
2023-12-09 11:24 ` Lino Sanfilippo
2023-12-09 11:47 ` Lino Sanfilippo
2023-12-11 13:07 ` Andy Shevchenko
2023-12-14 8:52 ` Lino Sanfilippo
2023-12-14 10:24 ` Crescent CY Hsieh
2023-12-14 13:41 ` Christoph Niedermaier [this message]
2023-12-14 14:04 ` Lino Sanfilippo
2023-12-14 14:50 ` Christoph Niedermaier
2023-12-15 22:13 ` Lino Sanfilippo
2023-12-18 9:08 ` Christoph Niedermaier
2023-12-21 15:53 ` Lukas Wunner
2023-12-23 12:49 ` Christoph Niedermaier
2023-12-23 13:40 ` Lino Sanfilippo
2023-12-24 10:11 ` Christoph Niedermaier
2023-12-28 23:25 ` Lukas Wunner
2023-11-20 15:10 ` [PATCH 2/2] serial: core: implement support for rs485-mux-gpios Rasmus Villemoes
2023-11-20 23:28 ` Lino Sanfilippo
2023-11-21 10:49 ` Dan Carpenter
2023-11-22 15:10 ` Lukas Wunner
2023-12-04 5:00 ` Dan Carpenter
2023-11-22 14:57 ` [PATCH 0/2] serial: add rs485-mux-gpio dt binding and support Andy Shevchenko
-- strict thread matches above, loose matches on Subject: below --
2023-12-27 17:40 [PATCH 1/2] dt-bindings: serial: rs485: add rs485-mux-gpios binding Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b35730df8288469fbaf67b5ceae4eece@dh-electronics.com \
--to=cniedermaier@dh-electronics.com \
--cc=LinoSanfilippo@gmx.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brenda.streiff@ni.com \
--cc=conor+dt@kernel.org \
--cc=crescentcy.hsieh@moxa.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jirislaby@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=lukas@wunner.de \
--cc=robh+dt@kernel.org \
--cc=tomaspaukrt@email.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).