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: <766f5d0d08c14666a3291073e1a43b23@dh-electronics.com>
Date: Sun, 24 Dec 2023 10:11:17 +0000
From: Christoph Niedermaier <cniedermaier@...electronics.com>
To: Lino Sanfilippo <LinoSanfilippo@....de>, Lukas Wunner <lukas@...ner.de>
CC: Crescent CY Hsieh <crescentcy.hsieh@...a.com>, Andy Shevchenko
	<andriy.shevchenko@...ux.intel.com>, 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: Saturday, December 23, 2023 2:41 PM
> On 23.12.23 13:49, Christoph Niedermaier wrote:
>> From: Lukas Wunner [mailto:lukas@...ner.de]
>> Sent: Thursday, December 21, 2023 4:53 PM
>>>
>>> On Thu, Dec 14, 2023 at 01:41:47PM +0000, Christoph Niedermaier wrote:
>>>> 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.
>>>
>>> Well why don't we just allow enabling or disabling RS-485 termination
>>> independently from the SER_RS485_ENABLED bit in struct serial_rs485?
>>>
>>> Just let the user issue a TIOCSRS485 ioctl to toggle termination even
>>> if in RS-232 mode and use that mode for RS-422.
>>>
>>> Looks like the simplest solution to me.
>>
>> Sounds not bad. The termination should only depend on whether the GPIO is
>> given or not.
>>
>> Irrespective of this, I think the Linos idea of an RS-422 mode is not bad.
>> This allows you to take care of special features that were previously
>> overlooked. For example, hardware flow control can be switched off so that
>> this does not cause any problems.
>>
> 
> Also note, that RS232 and RS422 may NOT always be the same from driver perspective.
> Take a look at 8250_excar.c for example. That driver has to configure the hardware
> accordingly when switching from RS232 to RS422 (see iot2040_rs485_config()).
> 
> While a SER_RS485_MODE_RS422 flag set by userspace could work to switch to RS422, I
> still think that the cleanest solution would be another ioctl TIOCSRS422 with a
> parameter like
> 
> struct serial_rs422 {
>        __u32   flags;
> #define SER_RS422_ENABLED              (1 << 0)
> #define SER_RS422_TERMINATE_BUS        (1 << 1)
>         __u32   padding[7]
> };
> 
> The SER_RS485_MODE_RS422 flag could still be used internally as a hint to the driver.
> That solution would also be expandable if needed. I planned to send a patch that
> implements this
> as a RFC to the mailing list (maybe in the next few days).

Having your own ioctl is a nice distinction, but when I think about it for a moment,
questions come to mind:

From userspace perspective then there are two termination flags
SER_RS485_TERMINATE_BUS and SER_RS422_TERMINATE_BUS?
How will they interact internally?

What about the devicetree property?
Will there be rs422-term-gpios as well?

Could the user enable RS422 and RS485 at the same time?


Regards and Merry Christmas
Christoph