All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tapio Reijonen" <tapio.reijonen@vaisala.com>
Cc: linux-serial@vger.kernel.org
Subject: Re: [PATCH v7 5/9] serial: max310x: stop the transmitter before powering down in shutdown
Date: Mon, 05 Oct 2026 13:34:21 +0000	[thread overview]
Message-ID: <20261005133421.9D9B21F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261005-max310x-rs485-sw-delay-v7-5-6ae392eca08c@vaisala.com>

> max310x_shutdown() powers the port down regardless of what the
> transmitter is doing. The power-off stops the UART clock mid-character,
> truncating the final frame, and on the auto-RTS path it freezes the
> RTS output at its current level: a close() with data still queued
> leaves the RS485 transceiver asserted until the next open, which also
> emits the interrupted character corrupted.
> 
> Waiting for the data to drain is no better: the tty layer's
> wait-until-sent is bounded by closing_wait, configurable to none, and
> a hangup arrives with no wait at all, so draining a full FIFO blocks
> close() in uninterruptible sleep for seconds at low baud rates - and
> forever when CTS flow control blocks the FIFO.
> 
> Instead, set MODE1 TxDisabl: the character in flight completes and the
> transmitter ceases with TX_ at idle. Give that character one character
> time (the chip has no transmitter-idle status), then reset the FIFOs
> so the auto-RTS engine sees the transmitter empty and releases RTS
> within the configured after-send hold; wait that hold plus one bit
> time before powering off. Abandoned data was explicitly not waited
> for, and startup() resets the FIFOs and TxDisabl on open anyway.
> 
> Measured on a MAX14830: a truncating close() at 50 baud takes 0.23 s,
> RTS releases one character plus the hold after the last stop bit on
> both polarities, and the reopen corruption is gone.
> 
> Fixes: f65444187a66 ("serial: New serial driver MAX310X")
> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005-max310x-rs485-sw-delay-v7-0-6ae392eca08c@vaisala.com?part=5


  reply	other threads:[~2026-10-05 13:34 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-05 13:19 [PATCH v7 0/9] (no cover subject) Tapio Reijonen
2026-10-05 13:19 ` [PATCH v7 1/9] serial: max310x: don't clobber the TX break bit in set_termios Tapio Reijonen
2026-10-05 13:27   ` sashiko-bot
2026-10-05 15:57   ` Hugo Villeneuve
2026-10-06  4:06     ` Tapio Reijonen
2026-10-06 13:42       ` Hugo Villeneuve
2026-10-08  9:06         ` Tapio Reijonen
2026-10-05 13:19 ` [PATCH v7 2/9] serial: max310x: assert the transceiver during a break Tapio Reijonen
2026-10-05 13:39   ` sashiko-bot
2026-10-05 13:19 ` [PATCH v7 3/9] serial: max310x: centralize the RS485 transceiver programming Tapio Reijonen
2026-10-05 13:19 ` [PATCH v7 4/9] serial: max310x: convert RS485 delays from milliseconds to bit-times Tapio Reijonen
2026-10-05 13:33   ` sashiko-bot
2026-10-05 13:19 ` [PATCH v7 5/9] serial: max310x: stop the transmitter before powering down in shutdown Tapio Reijonen
2026-10-05 13:34   ` sashiko-bot [this message]
2026-10-05 13:19 ` [PATCH v7 6/9] serial: max310x: support active-low RTS on the hardware path Tapio Reijonen
2026-10-05 13:34   ` sashiko-bot
2026-10-05 13:19 ` [PATCH v7 7/9] serial: max310x: schedule tx_work directly from the IRQ handler Tapio Reijonen
2026-10-05 13:30   ` sashiko-bot
2026-10-05 13:19 ` [PATCH v7 8/9] serial: max310x: drive RTS in software when hardware delays are too short Tapio Reijonen
2026-10-05 13:40   ` sashiko-bot
2026-10-05 13:19 ` [PATCH v7 9/9] serial: max310x: don't transmit while an RS485 reconfigure is pending Tapio Reijonen
2026-10-05 13:41   ` sashiko-bot
2026-10-05 13:37 ` [PATCH v7 0/9] (no cover subject) Tapio Reijonen
2026-10-05 15:51 ` Hugo Villeneuve
2026-10-06  4:03   ` 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=20261005133421.9D9B21F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tapio.reijonen@vaisala.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.