linux-kernel - Re: [PATCH 1/7] serial: 8250_dwlib: RS485 HW half duplex support

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: <20220308145042.GA20520@wunner.de>
Date:   Tue, 8 Mar 2022 15:50:42 +0100
From:   Lukas Wunner <lukas@...ner.de>
To:     Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Johan Hovold <johan@...nel.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Raymond Tan <raymond.tan@...el.com>,
        Heiko Stuebner <heiko@...ech.de>
Subject: Re: [PATCH 1/7] serial: 8250_dwlib: RS485 HW half duplex support

On Tue, Mar 08, 2022 at 02:59:59PM +0200, Ilpo Järvinen wrote:
> On Tue, 8 Mar 2022, Lukas Wunner wrote:
> > On Tue, Mar 08, 2022 at 02:16:56PM +0200, Ilpo Järvinen wrote:
> > > The SoC also has a pin to select between RS485 and RS232. With a combo 
> > > transceiver, TCR-based heuristic just runs into the same problems as the 
> > > version-based one did.
> > 
> > I thought this was about detecting whether hardware-assisted DE assertion
> > may be used (versus software-controlled), not about whether to enable
> > RS-485 mode.  Right?
> 
> HW DE assertion only works when RS485 mode is enabled so I don't see how 
> these questions could be easily decoupled like that. That's assuming with 
> "software-controlled" you mean RTS(RS232)+em485?

Right, that's what I meant.

Enabling RS-485 mode is only supposed to happen upon a TIOCSRS485 ioctl
or if the "linux,rs485-enabled-at-boot-time" property is present.
We don't need to second-guess the user's decision to enable RS-485 mode.
If that's what they've asked for, then we can and should assume that an
RS-485 transceiver is attached.

Of course, if hardware-assisted DE assertion requires a particular pinmux
state, we could double-check whether that pinmux state is set.  If the
RTS/DE pin is not muxed as a DE pin but rather as an RTS pin, one option
would be to fall back to software-controlled RTS assertion.  A warning
message may be warranted in that case.

Whether hardware-assisted DE assertion is supported by the chip can not
only be detected by checking for the POR 0x6 value in the TCR register:
You can alternatively write a non-zero value to any of the RS-485 registers,
then check if reading the register back returns a non-zero value
(RE_EN is probably a good candidate).  That approach is more robust
than relying on the POR value 0x6 in TCR because you never know if
boot firmware fiddled with the registers before passing control to the
kernel.

Thanks,

Lukas