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: <3b8548b1-b8a9-0c9e-4040-5cfda06a85c6@gmx.de>
Date:   Sun, 26 Nov 2023 00:40:07 +0100
From:   Lino Sanfilippo <LinoSanfilippo@....de>
To:     Lukas Wunner <lukas@...ner.de>,
        Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     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,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
        Crescent CY Hsieh <crescentcy.hsieh@...a.com>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
        brenda.streiff@...com, cniedermaier@...electronics.com,
        Tomas Paukrt <tomaspaukrt@...il.cz>
Subject: Re: [PATCH 1/2] dt-bindings: serial: rs485: add rs485-mux-gpios
 binding

Hi,

On 22.11.23 at 15:53, Lukas Wunner wrote:
> On Mon, Nov 20, 2023 at 04:10:54PM +0100, Rasmus Villemoes wrote:
>> Some boards are capable of both rs232 and rs485, and control which
>> external terminals are active via a gpio-controlled mux. Allow
>> describing that gpio in DT so that the kernel can transparently handle
>> the proper setting when the uart is switched between rs232 and rs485
>> modes.
>
> 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.
I dont know if it is a good choice in the long term to handle both modes within
the RS485 configuration. It would be cleaner to have an own RS422 structure with
its own flags and properties. And until now the only flag that seems to make sense
for both RS422 and RS485 is AFAICS SER_RS485_TERMINATE_BUS.

On the other hand the bus termination is at least a property that both modes have
in common. And handling RS422 in its own structure would require another ioctl
to set and get the the RS422 settings.

But maybe there are more or better possibilities to handle RS4822 support. I would like to
hear other ideas.

> I don't know whether that makes sense at all (I had thought RS-422 is
> the same as RS-485 with full-duplex, i.e. SER_RS485_ENABLED plus
> SER_RS485_RX_DURING_TX)
>
> But if that patch gets accepted, we'd have *three* different modes:
> RS-232, RS-485, RS-422.

Actually we would have four (as Brenda already wrote,
see https://lore.kernel.org/all/c6ea912f-d5ab-4761-813d-3b6b6be141cb@ni.com/),
and with the propose SER_RS485_MODE_RS422 flag these modes would be used like

RS-232:                       rs485->flags = 0
RS-422:                       rs485->flags = SER_RS485_ENABLED|SER_RS485_MODE_RS422
RS-485 (2-wire half-duplex):  rs485->flags = SER_RS485_ENABLED
RS-485 (4-wire full-duplex):  rs485->flags = SER_RS485_ENABLED|SER_RS485_RX_DURING_TX

>  A single GPIO seems insufficient to handle that.

GPIOs for RS485 is another thing.

I mean, currently we have a GPIO for RS485 termination (I introduced it with commit 44b27aec9d9680875).
Christoph introduced support for a rx-during-tx GPIO (see commit 163f080eb717). Tomas intends
to add a GPIO which enables RS485 if asserted
(see https://lore.kernel.org/all/3Za.ZZs%7D.ndXI8CMee4.1bN6eQ@seznam.cz/) and with Rasmus patches
we are about to add a MUX-GPIO which is to be asserted if RS485 is enabled.

I wonder where this will end and if we really have to support every possible GPIO
in the serial core.

Regards,
Lino