On Fri, Oct 07, 2022 at 01:34:19PM +0200, Matthias Schiffer wrote: > On Thu, 2022-09-22 at 18:30 +0200, Lukas Wunner wrote: > > Here's a v4 with full changelog: > > > > https://lore.kernel.org/linux-serial/2de36eba3fbe11278d5002e4e501afe0ceaca039.1663863805.git.lukas@xxxxxxxxx/ > > I've noticed that this patch (well, the version that was applied to > tty.git) also changed the setting of the DTR flag in the MCR register. > Without your patch, I can see that the values passed to > serial8250_out_MCR() alternate between 0x03 and 0x01 when switching > between tx and rx, but with your patch, the values become 0x02 and > 0x00. > > I'm not sure if setups RS485 exist where the DTR flag is relevant, but > as this was not mentioned in the commit message, I suspect that the > change might have been unintended. That's intentional and documented in the following paragraph of the commit message: Skip any invocation of ->set_mctrl() if RS485 is enabled. RS485 has no hardware flow control, so the modem control lines are irrelevant and need not be touched. When leaving RS485 mode, reset the modem control lines to the state stored in port->mctrl. That way, UARTs which are muxed between RS485 and RS232 transceivers drive the lines correctly when switched to RS232. (serial8250_do_startup() historically raises the OUT1 modem signal because otherwise interrupts are not signaled on ancient PC UARTs, but I believe that no longer applies to modern, RS485-capable UARTs and is thus safe to be skipped.) I think that the Siemens IOT20x0 series muxes the UART between RS232 and RS485 transceivers, though I'm not sure if that applies both to the contemporary AM6548-based IOT2050 and to the older Intel-based machines. In RS485 mode, the DTR signal should be completely irrelevant as the transceiver is only attached to RX, TX and RTS pins. When switching from RS485 to RS232 mode, the patch ensures that the modem signals are reset to what's been saved in port->mctrl. So DTR will be raised once the UART is switched to RS232. Thanks, Lukas
