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: <67a2cea0-f2de-4e7d-bc9d-ae29885f9210@linaro.org>
Date:   Tue, 21 Nov 2023 09:34:02 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     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>
Cc:     devicetree@...r.kernel.org,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Lukas Wunner <lukas@...ner.de>, Rob Herring <robh@...nel.org>,
        linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: serial: rs485: add rs485-mux-gpios
 binding

On 21/11/2023 09:27, Rasmus Villemoes wrote:
> On 21/11/2023 08.52, Krzysztof Kozlowski wrote:
>> On 20/11/2023 16:10, 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.
>>>
>>> Signed-off-by: Rasmus Villemoes <linux@...musvillemoes.dk>
>>> ---
>>>  Documentation/devicetree/bindings/serial/rs485.yaml | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml
>>> index 9418fd66a8e9..e8136c7d22ed 100644
>>> --- a/Documentation/devicetree/bindings/serial/rs485.yaml
>>> +++ b/Documentation/devicetree/bindings/serial/rs485.yaml
>>> @@ -61,6 +61,11 @@ properties:
>>>        the active state enables RX during TX.
>>>      maxItems: 1
>>>  
>>> +  rs485-mux-gpios:
>>> +    description: GPIO pin to control muxing of the SOC signals to the RS485
>>> +      transceiver.
>>> +    maxItems: 1
>>
>> Aren't you duplicating
>> https://lore.kernel.org/all/3Nk.ZZrp.5w3Yn0Ecy5C.1bMzDp@seznam.cz/ ?
> 
> Hadn't seen that, but no, this is not at all the same. That patch seems
> to define an input pin to tell whether to enable rs485 mode or not (sort
> of early run-time version of the linux,rs485-enabled-at-boot-time).
> 
>> Anyway, similar comments: this does not look like generic RS485
>> property. Are you saying that standard defines such GPIO?
> 
> No, I'm saying that several boards that exist in the wild have the
> RX/TX/CTS etc. pins routed to a multiplexer, which in turn routes those
> signals to either a rs485 transceiver or an rs232 driver (and those in
> turn are connected to different screw terminals). So no, it's not a
> property of the rs485 protocol itself, but very much related to making
> use of rs485 (and rs232, though of course not simultaneously) on such
> boards.

Which upstream boards use it? To me it looks like specific to each
controller, not to RS485.

> 
> Would a link to a schematic help?

Yes, always :)

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ