Re: [PATCH v8 6/6] serial: 8250: retain DMA resources when termination fails

From
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date
2026-10-30 09:40:15
Also in
imx, linux-arm-kernel, linuxppc-dev, lkml
Reply to
James Hilliard, 2026-10-29
On Thu, Oct 29, 2026 at 11:19:59AM -0600, James Hilliard wrote:
On Thu, Oct 29, 2026 at 8:24 AM Andy Shevchenko
[off-list ref] wrote:
quoted
On Thu, Oct 29, 2026 at 01:37:02AM -0600, James Hilliard wrote:
...
quoted
quoted
+     while (rx_ret || tx_ret) {
+             dev_err_ratelimited(p->port.dev,
+                                 "DMA termination failed: RX %d, TX %d; retrying\n",
+                                 rx_ret, tx_ret);
quoted
+             msleep(100);
Huh?!
quoted
+             if (rx_ret)
+                     rx_ret = dmaengine_terminate_sync(dma->rxchan);
+             if (tx_ret)
+                     tx_ret = dmaengine_terminate_sync(dma->txchan);
+     }
This is unacceptable. Sleeping is okay, but value should really match the
baudspeed and other parameters of the transfer.
This sleep is backoff after dmaengine_terminate_sync() has returned
an error, rather than an estimate of UART transmission time. Each
retry asks the provider to stop the channel again; elapsed time is
never treated as evidence that the resources are safe to free.

The particular 100 ms interval has no hardware-derived justification.
However, I don't yet see a sound way to derive the retry cadence from
baud rate either. RX can be waiting for input, TX can be held by flow
control, and callback retirement is a separate requirement from
moving bytes through the UART.

Do you have a particular provider failure mode in mind where retrying
termination should follow the serial transfer timing? I'd like to
base the interval on the condition that can make termination succeed,
rather than substitute a wire-time estimate for an arbitrary delay.
Termination of DMA sometimes require to clean up internal FIFOs and other state
machines. That's what happens on HW side. In the software waiting for too much
may lead to the very big undesired latencies. The value of 100ms sounds insane
to me for the HSUART cases (megabaud range of speed). Also note, not every PCB
design uses HW flow control, so this may be even worse for them.
Regardless of the retry interval, shutdown cannot release the buffers
until the provider establishes that DMA and its callbacks have stopped.
-- 
With Best Regards,
Andy Shevchenko

Thread (35 messages) 35 messages, 4 authors, last reply 2d ago
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help