From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: James Hilliard <james.hilliard1@gmail.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Raul E Rangel" <rrangel@chromium.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
"Tony Lindgren" <tony@atomide.com>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
"Richard Genoud" <richard.genoud@bootlin.com>,
"Nicolas Ferre" <nicolas.ferre@microchip.com>,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Claudiu Beznea" <claudiu.beznea@tuxon.dev>,
"Jacky Huang" <ychuang3@nuvoton.com>,
"Shan-Chun Hung" <schung@nuvoton.com>,
"Pali Rohár" <pali@kernel.org>, "Frank Li" <Frank.Li@nxp.com>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Pengutronix Kernel Team" <kernel@pengutronix.de>,
"Fabio Estevam" <festevam@gmail.com>,
"Maciej W. Rozycki" <macro@orcam.me.uk>,
"Timur Tabi" <timur@kernel.org>,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v8 2/6] serial: serialize asynchronous write wakeups with the port lock
Date: Thu, 29 Oct 2026 16:17:55 +0200 [thread overview]
Message-ID: <auNVk_Y8iiAXyFa3@ashevche-desk.local> (raw)
In-Reply-To: <20261029-submit-serial-8250-dma-cancel-v1-v8-2-3fd56ba352ed@gmail.com>
On Thu, Oct 29, 2026 at 01:36:58AM -0600, James Hilliard wrote:
> uart_write_wakeup() expects the UART port lock to be held. Several worker,
> DMA completion and interrupt paths call it without that lock, including
> indirect calls from uart_handle_cts_change() and the transmit helpers.
>
> Take the port lock around these notifications or their transmit helper.
> Keep sleeping SPI and regmap accesses outside the locked region, and keep
> the FSL LPUART completion lock held through its wakeup. Acquire the port
> lock after releasing private channel locks to preserve the ordering used
> by UART callbacks. In the MUX timer, publish available FIFO space under
> the port lock and keep the hardware FIFO-drain wait outside it.
>
> Use IRQ-safe locking in the Atmel RX and TX tasklets and SB1250 termios
> path, since their interrupt handlers now acquire the same port lock.
> Preserve the caller's interrupt state when releasing those locks.
>
> On SB1250, lock modem-state updates after reading and filtering the change
> status, and wake modem-status waiters after unlocking. Take the TX lock
> inside its service routine so RX-only interrupts need no acquisition.
> Keep that lock across x_char handling, FIFO consumption and the decision
> to mask TX interrupts: a writer must not enqueue data and enable TX between
> the empty-FIFO check and the interrupt-mask write. Each TX invocation sends
> at most one character.
>
> Serialize CLPS711x TX servicing and its interrupt-enable state with the
> port lock. Disable TX interrupts without waiting in stop_tx(), since a
> threaded handler may need that same lock. Have an already queued handler
> leave stopped output untouched, and drain it outside the lock during
> shutdown before the transmit FIFO can be released.
>
> SCCNXP handles interrupts under a controller lock which its UART callbacks
> acquire with the port lock already held. Collect the ports needing wakeups
> in an unsigned long bitmap while servicing the controller, then release
> that lock before visiting the set bits, taking each port lock and
> rechecking the wakeup threshold. Removal drains the IRQ or timer before
> unregistering the ports.
>
> This serializes write notifications with port-locked serial-core state
> changes, allowing readiness and transmit-storage reservations to gate the
> notification without a check-versus-shutdown race.
>
> Cover DZ TX servicing and JSM Classic modem notifications as well. On
> DECstation ZS, acquire the port lock before the SCC lock and notify writers
> after releasing the SCC lock. Defer normal TX restart after console output
> to a worker, since console output can already run under the port lock.
> Check transmitter readiness before consuming another character and drain
> the restart worker during shutdown and removal. Release Lantiq's hardware
> lock through the transmit helper's completion hook before notifying the
> line discipline.
...
> static irqreturn_t serial21285_tx_chars(int irq, void *dev_id)
> struct uart_port *port = dev_id;
> u8 ch;
>
> + guard(uart_port_lock_irqsave)(port);
Why _irqsave?
> uart_port_tx_limited(port, ch, 256,
> !(*CSR_UARTFLG & 0x20),
> *CSR_UARTDR = ch,
...
Same Q everywhere (it might be legit in some cases,
it might be too strong in others).
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-10-29 14:18 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 7:36 [PATCH v8 0/6] serial: 8250: serialize DMA cancellation with buffer reuse James Hilliard
2026-10-29 7:36 ` [PATCH v8 1/6] serial: 8250_omap: separate locked TX DMA completion processing James Hilliard
2026-10-29 7:41 ` sashiko-bot
2026-10-29 7:36 ` [PATCH v8 2/6] serial: serialize asynchronous write wakeups with the port lock James Hilliard
2026-10-29 7:49 ` sashiko-bot
2026-10-29 14:17 ` Andy Shevchenko [this message]
2026-10-29 17:13 ` James Hilliard
2026-10-29 7:36 ` [PATCH v8 3/6] serial: core: allow drivers to reserve flushed transmit storage James Hilliard
2026-10-29 8:06 ` sashiko-bot
2026-10-29 7:37 ` [PATCH v8 4/6] serial: 8250: drain canceled TX DMA before reusing its buffer James Hilliard
2026-10-29 7:51 ` sashiko-bot
2026-10-29 14:19 ` Andy Shevchenko
2026-10-29 17:15 ` James Hilliard
2026-10-29 7:37 ` [PATCH v8 5/6] serial: 8250: retire canceled RX DMA before reusing the receive buffer James Hilliard
2026-10-29 7:51 ` sashiko-bot
2026-10-29 14:22 ` Andy Shevchenko
2026-10-29 17:17 ` James Hilliard
2026-10-29 22:27 ` Raul E Rangel
2026-10-30 0:32 ` James Hilliard
2026-10-29 7:37 ` [PATCH v8 6/6] serial: 8250: retain DMA resources when termination fails James Hilliard
2026-10-29 7:42 ` sashiko-bot
2026-10-29 14:23 ` Andy Shevchenko
2026-10-29 17:19 ` James Hilliard
2026-10-29 22:27 ` Raul E Rangel
2026-10-30 0:35 ` James Hilliard
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=auNVk_Y8iiAXyFa3@ashevche-desk.local \
--to=andriy.shevchenko@linux.intel.com \
--cc=Frank.Li@nxp.com \
--cc=alexandre.belloni@bootlin.com \
--cc=bigeasy@linutronix.de \
--cc=claudiu.beznea@tuxon.dev \
--cc=festevam@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=imx@lists.linux.dev \
--cc=james.hilliard1@gmail.com \
--cc=jirislaby@kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=macro@orcam.me.uk \
--cc=nicolas.ferre@microchip.com \
--cc=pali@kernel.org \
--cc=richard.genoud@bootlin.com \
--cc=rrangel@chromium.org \
--cc=s.hauer@pengutronix.de \
--cc=schung@nuvoton.com \
--cc=timur@kernel.org \
--cc=tony@atomide.com \
--cc=ychuang3@nuvoton.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.