On Mon, Dec 20, 2021 at 07:30:52AM +0100, Jiri Slaby wrote:
> On 20. 12. 21, 7:28, Jiri Slaby wrote:
> > On 18. 12. 21, 10:58, Lukas Wunner wrote:
> > > Commit a6845e1e1b78 ("serial: core: Consider rs485 settings to drive
> > > RTS") sought to deassert RTS when opening an rs485-enabled uart port.
> > > That way, the transceiver does not occupy the bus until it transmits
> > > data.
> > >
> > > Unfortunately, the commit mixed up the logic and *asserted* RTS instead
> > > of *deasserting* it:
> > >
> > > The commit amended uart_port_dtr_rts(), which raises DTR and RTS when
> > > opening an rs232 port. "Raising" actually means lowering the signal
> > > that's coming out of the uart, because an rs232 transceiver not only
> > > changes a signal's voltage level, it also *inverts* the signal. See
> > > the simplified schematic in the MAX232 datasheet for an example:
> > > https://www.ti.com/lit/ds/symlink/max232.pdf
> > >
> > > So, to raise RTS on an rs232 port, TIOCM_RTS is *set* in port->mctrl
> > > and that results in the signal being driven low.
> > >
> > > In contrast to rs232, the signal level for rs485 Transmit Enable is the
> > > identity, not the inversion: If the transceiver expects a "high" RTS
> > > signal for Transmit Enable, the signal coming out of the uart must also
> > > be high, so TIOCM_RTS must be *cleared* in port->mctrl.
> > >
> > > The commit did the exact opposite, but it's easy to see why given the
> > > confusing semantics of rs232 and rs485. Fix it.
> > >
> > > Fixes: a6845e1e1b78 ("serial: core: Consider rs485 settings to drive
> > > RTS")
> > > Signed-off-by: Lukas Wunner <lukas@xxxxxxxxx>
> > > Cc: stable@xxxxxxxxxxxxxxx # v4.14+
> > > Cc: Rafael Gago Castano <rgc@xxxxxx>
> >
> > Rafael, can you ack/test this, please?
>
> Definitely on that e-mail:
> 550 5.4.1 Recipient address rejected: Access denied. AS(201806281)
> [DB5EUR03FT039.eop-EUR03.prod.protection.outlook.com]
>
> Trying rafael.gago@xxxxxxxxx from the Author field.
A bit of GitHub sleuthing turned up the following alternative addresses:
rafael_gago_81@xxxxxxxxxxx
rafael.gago@xxxxxxxxxxx
rafael.gago@xxxxxxxxxxxx
Unfortunately none of them is responsive. I was hoping that the Siemens
folks might be willing to attest correctness of the patch.
Thanks,
Lukas
