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

[Lukas Wunner <lukas@wunner.de>]

On Thu, Sep 22, 2022 at 04:43:51PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Sep 21, 2022 at 06:39:33AM +0200, Lukas Wunner wrote:
> > 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.
[...]
> 
> This message never made it to lore.kernel.org, so I can't seem to apply
> it using `b4`.
> 
> Can you resend it so that it does make it to the public archives?

Yes, both v1 and v2 didn't make it to the mailing list archive.
My suspicion is that the Cc: line was probably too long.

I resent as v3 with only you in To: and the mailing list in Cc: and
this time it went through:

https://lore.kernel.org/linux-serial/2de36eba3fbe11278d5002e4e501afe0ceaca039.1663860626.git.lukas@wunner.de/

On the bright side, v2 contained an embarrassing checkpatch issue
(superfluous newline) and resending as v3 provided a welcome
opportunity to fix that. :)

Thanks,

Lukas