Re: [PATCH v5 4/8] serial: max310x: wait for TX to drain before powering down in shutdown

[Tapio Reijonen <tapio.reijonen@vaisala.com>]

Hi Hugo,

On Thu, 1 Oct 2026 16:00:20 -0400, Hugo Villeneuve wrote:
> > +	unsigned int		one_char_duration_us;
>
> char_time_us?

Renamed in v6.

> > +	to_max310x_port(port)->baud = baud;
> > +	to_max310x_port(port)->one_char_duration_us =
> > +		DIV_ROUND_UP(USEC_PER_SEC * frame_bits, baud);
>
> Would it be a good idea to if you moved these two lines after
> max310x_set_rts_ctl_params(), then you could probably leave the
> original comments and simply add a new comment to indicate "Compute
> time it takes to clock out one character", simplifying the diff
> (review) and readability?

I would prefer not to move them: the helper consumes both values.
The baud is what the millisecond-to-bit-time conversion divides by,
so it must be cached before the call. And as of v6 the helper can
also arm the after-send hold directly - v6 adds a fix for the case
where a reconfigure moves the port off the hardware RTS path while a
transmission is still in flight, and the takeover computes the hold
from char_time_us - so the character time has to be current at that
point as well.

> > +	unsigned int loops = port->fifosize + 1;
>
> tries?

Renamed in v6.

> Based on these comments, does it mean that the FIFO has already been
> validated empty at this point by the tty layer, so you don't need the
> loop at all, just the unconditional last fsleep()?

No - that wait is not guaranteed. uart_wait_until_sent() runs only on
the close path and is bounded by closing_wait, which can be configured
to none, and hangup reaches shutdown() with no wait at all. In
testing, a vhangup issued mid-transfer entered shutdown() with the
chip FIFO still holding over a hundred characters; this loop is what
drained them before power-down.

> For certain combinations of large fifo_sizes and high-baud rates,
> that could mean a lot of I2C/SPI transactions?

It is bounded at one FIFO-level read per character time, at most
fifosize + 1 of them, only on the close/hangup path, and it stops as
soon as the FIFO reads empty - in total no longer than the remaining
transmit time of the data itself. At high baud rates the character
time shrinks, so the polls get more frequent but the window they can
occupy shrinks with it.

Tapio