Re: [PATCH] Revert "serial: 8250: Don't touch RTS modem control while in rs485 mode"

[Lukas Wunner <lukas@wunner.de>]

On Sun, Nov 21, 2021 at 10:00:51AM +0100, Jan Kiszka wrote:
> Meanwhile reproduced myself, and now I believe your patch is broken in
> ignoring the internal call path to serial8250_set_mctrl, coming from
> uart_port_dtr_rts:
> 
> [  257.923335] uart_port_dtr_rts: rs485_on 1, RTS_after_send 1, raise 1
> [   25.411508] mcr = 1 (was 0)
> [  257.932631] CPU: 0 PID: 457 Comm: cat Not tainted 5.16.0-rc1+ #190
> [  257.938803] Hardware name: SIMATIC IOT2050 Basic (DT)
> [  257.943843] Call trace:
> [  257.946280]  dump_backtrace+0x0/0x1ac
> [  257.949948]  show_stack+0x18/0x70
> [  257.953260]  dump_stack_lvl+0x68/0x84
> [  257.956920]  dump_stack+0x18/0x34
> [  257.960231]  serial8250_do_set_mctrl+0x184/0x190
> [  257.964847]  omap8250_set_mctrl+0x24/0xd0
> [  257.968855]  serial8250_set_mctrl+0x18/0x34
> [  257.973033]  uart_port_dtr_rts+0xc0/0x160

Are you using a custom patch which is not in mainline to fix the behavior
of uart_port_dtr_rts() if rs485 is enabled?

In the dmesg output above, why does the timestamp jump from 257.923335
back to 25.411508?

After extensive debugging and staring at the code for a couple of days
I'm under the impression commit a6845e1e1b78 is broken and sets RTS
exactly the wrong way.  The commit failed to appreciate that with RS-485,
there's a single negation of RTS (MCR contains the complement of the
desired signal level) whereas with RS-232 there's a double negation
(the RS-232 transceiver negates the resulting signal level yet again).
So, "setting RTS" and "clearing RTS" is the inverse for RS-232 vis-a-vis
RS-485.

With the code in mainline broken, yet it apparently not being broken in
your tree (going by your debug output above), only explanation I can
think of is you've got a custom fix in your tree.  If you do, why haven't
you upstreamed it?

Thanks,

Lukas