From: Tapio Reijonen <tapio.reijonen@vaisala.com>
To: Maarten Brock <Maarten.Brock@sttls.nl>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
Hugo Villeneuve <hvilleneuve@dimonoff.com>,
Tapio Reijonen <tapio.reijonen@kolumbus.fi>
Subject: Re: [PATCH v6 5/9] serial: max310x: wait for TX to drain before powering down in shutdown
Date: Mon, 5 Oct 2026 13:51:49 +0300 [thread overview]
Message-ID: <b20fcb96-964e-46bc-b06c-0d0fcbf596d1@vaisala.com> (raw)
In-Reply-To: <GV2PR05MB119415B20C7D800FA6279CE4183962@GV2PR05MB11941.eurprd05.prod.outlook.com>
On 10/5/26 13:12, Maarten Brock wrote:
> Would it not be better to retrieve the fifo level and multiply that
> by char_time_us to wait first? Yes, the (MAX3109) datasheet mentions
> its value may sometimes be inaccurate, but the worst that can happen
> is waiting too long. And after that use this max310x_tx_empty().
That would tighten the loop, but v7 drops the drain altogether - see
my reply to the review bot elsewhere in this thread. Draining turned
out to be wrong twice over: the wait is an uninterruptible sleep of
up to fifosize+1 character times per close() (~26 s at 50 baud, and
unbounded when CTS flow control holds the FIFO), and a close() with
data still queued on the auto-RTS path powers the port down
mid-transmission, where the stopped UART clock freezes RTS at its
asserted level until the next open - reproduced on the wire.
In v7, shutdown() stops the transmitter instead: MODE1 TxDisabl lets
the character in flight complete, data beyond it is abandoned (it is
only still queued when the tty layer was told not to wait for it),
the FIFOs are reset so the auto-RTS engine sees the transmitter empty
and releases RTS, and the power-off waits the configured after-send
hold plus one bit time. With the transmitter stopped the fill level
no longer matters; the remaining one-character wait covers the shift
register, which no level register reports.
Tapio
next prev parent reply other threads:[~2026-10-05 10:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-04 12:16 [PATCH v6 0/9] serial: max310x: RS485 delay and RTS fixes, software-timed delays Tapio Reijonen
2026-10-04 12:16 ` [PATCH v6 1/9] serial: max310x: don't clobber the TX break bit in set_termios Tapio Reijonen
2026-10-05 15:45 ` Hugo Villeneuve
2026-10-04 12:16 ` [PATCH v6 2/9] serial: max310x: assert the transceiver during a break Tapio Reijonen
2026-10-04 12:16 ` [PATCH v6 3/9] serial: max310x: centralize the RS485 transceiver programming Tapio Reijonen
2026-10-04 12:16 ` [PATCH v6 4/9] serial: max310x: convert RS485 delays from milliseconds to bit-times Tapio Reijonen
2026-10-04 12:16 ` [PATCH v6 5/9] serial: max310x: wait for TX to drain before powering down in shutdown Tapio Reijonen
[not found] ` <20261004122835.92E741F000FF@smtp.kernel.org>
2026-10-05 8:19 ` Tapio Reijonen
2026-10-05 10:12 ` Maarten Brock
2026-10-05 10:51 ` Tapio Reijonen [this message]
2026-10-04 12:16 ` [PATCH v6 6/9] serial: max310x: support active-low RTS on the hardware path Tapio Reijonen
2026-10-04 12:16 ` [PATCH v6 7/9] serial: max310x: schedule tx_work directly from the IRQ handler Tapio Reijonen
2026-10-04 12:16 ` [PATCH v6 8/9] serial: max310x: drive RTS in software when hardware delays are too short Tapio Reijonen
2026-10-04 12:16 ` [PATCH v6 9/9] serial: max310x: don't transmit while an RS485 reconfigure is pending Tapio Reijonen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b20fcb96-964e-46bc-b06c-0d0fcbf596d1@vaisala.com \
--to=tapio.reijonen@vaisala.com \
--cc=Maarten.Brock@sttls.nl \
--cc=gregkh@linuxfoundation.org \
--cc=hvilleneuve@dimonoff.com \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=tapio.reijonen@kolumbus.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®