On Fri, Nov 12, 2021 at 02:14:11PM +0800, Su Bao Cheng wrote: > The issue is observed on omap8250 hardware (CPU: AM6548). the use case > is RS485 half-duplex (2 wire mode), in this mode the RTS pin is used to > control the direction and is software controller via the MCR[1] > register. The problem is that the RS485 transmitting is OK, but the > receiving is not working. That means the RTS pin is always asserted and never deasserted. I don't see how that could be related to the patch in question. It's rather an indication that RS-485 is not enabled on the port. > The MCR is set to 0 at this line within uart_port_startup(): > retval = uport->ops->startup(uport); > > On omap8250, the startup() points to omap_8250_startup(), within it: > up->mcr = 0; > > For software controlled RTS pin of RS485 half-duplex, when not in the > transmitting, the MCR[1] should be constant to indicate the current > direction is receiving. This is set in serial8250_em485_stop_tx(). > > So after this point of setting the MCR to 0, this up->mcr register > mirror does not reflect the actual desired value anymore. Further > checking against it leads to false result. And? up->mcr is not used by the patch. It retrieves the current value of the RTS bit from the MCR register instead of using the cached value in up->mcr. And all it seeks to achieve is *preserve* the current value of the RTS bit. So I don't see why the cached value up->mcr is relevant here. Thanks, Lukas
