Re: [PATCH 7/7] serial: max310x: Three-state TX and RTS while the port is closed

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Medium] serial: max310x: phantom break on TX line in
  max310x_startup() [1]
--

commit e4e606eca28fdbe85b131fef6cbe0acf9223f301
Author: Tapio Reijonen <tapio.reijonen@vaisala.com>

serial: max310x: Three-state TX and RTS while the port is closed

This commit implements the maxim,tristate-when-closed property to keep TX and
RTS three-stated in MODE1 while the UART port is closed.

> diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
> index 876bdd1f5496d..d5884c870d8e0 100644
> --- a/drivers/tty/serial/max310x.c
> +++ b/drivers/tty/serial/max310x.c

[ ... ]

> @@ -1542,6 +1557,7 @@ static int max310x_startup(struct uart_port *port)
>  	struct max310x_one *one = to_max310x_port(port);
>  	unsigned int val;
>  
> +	max310x_set_tristate(port, false);
>  	max310x_power(port, 1);
>  
>  	/*

[Severity: Medium]
This problem wasn't introduced by this patch, but can max310x_startup()
transmit a 50ms phantom break on the TX line [1] when reopening a port
that was closed with a break condition still asserted?

MAX310X_LCR_TXBREAK_BIT is only cleared in MAX310X_LCR_REG after
max310x_power(port, 1) returns.  Because max310x_power(port, 1) sleeps for
50ms via msleep(50) while waking the device, the newly enabled TX pin drives
the latched break state across the entire 50ms settle window, which can cause
framing errors or data corruption on the remote receiver.

[1] https://sashiko.dev/#/bug/linux-48f66bf9-1d5f-4959-b6b9-bc3800762a8e

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111-serial-transceiver-supply-v1-0-40bad0f912f2@vaisala.com?part=7