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
