Re: [PATCH v4] serial: Deassert Transmit Enable on probe in driver-specific way

[Lukas Wunner <lukas@wunner.de>]

On Mon, Oct 10, 2022 at 03:17:14PM +0900, Dominique MARTINET wrote:
> Lukas Wunner wrote on Thu, Sep 22, 2022 at 06:27:33PM +0200:
> > When a UART port is newly registered, uart_configure_port() seeks to
> > deassert RS485 Transmit Enable by setting the RTS bit in port->mctrl.
> > However a number of UART drivers interpret a set RTS bit as *assertion*
> > instead of deassertion:  Affected drivers include those using
> > serial8250_em485_config() (except 8250_bcm2835aux.c) and some using
> > mctrl_gpio (e.g. imx.c).
> > 
> > Since the interpretation of the RTS bit is driver-specific, it is not
> > suitable as a means to centrally deassert Transmit Enable in the serial
> > core.  Instead, the serial core must call on drivers to deassert it in
> > their driver-specific way.  One way to achieve that is to call
> > ->rs485_config().  It implicitly deasserts Transmit Enable.
> > 
> > So amend uart_configure_port() and uart_resume_port() to invoke
> > uart_rs485_config().  That allows removing calls to uart_rs485_config()
> > from drivers' ->probe() hooks and declaring the function static.
[...]
> We also noticed rs485 DE was initially wrong last week and I noticed
> this when I was about to send a patch that just inverted the
> SER_RS485_RTS_AFTER_SEND check in uart_configure_port, but after reading
> the commit message here it's a lot more complicated than that depending
> on the serial driver...

Yes, sorry for the breakage.

> Unfortunately you've marked this for v4.14+ stable, but it doesn't even
> apply to 5.19.14
[...]
> What would you like to do for stable branches?
> Would you be able to send a patch that applies on older 5.10 and 5.15
> where commit d3b3404df318 ("serial: Fix incorrect rs485 polarity on uart
> open") has been backported?

Greg will try to apply it to stable kernels (probably after the merge
window closes) and send an e-mail that it failed.  I was going to wait
for that to happen and then look into backporting the patch.

Basically what needs to be done is replace calls to uart_rs485_config()
with a direct invocation of port->rs485_config().  Plus carefully checking
that nothing is missing or breaks.  That's probably simpler than just
backporting additional patches or reverting stuff.  If you want to take
a stab at it, go ahead. :)

Thanks,

Lukas