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

[Lukas Wunner <lukas@wunner.de>]

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