[PATCH 0/2] serial: keep the flushed TX buffer mapped until DMA has stopped
Samarth Narang
samarth.colleges at gmail.com
Sat Oct 31 06:44:58 PDT 2026
Thanks Greg, I will address the findings Sashiko found, would
appreciate someone with hardware giving a stamp of approval!
On Sat, Oct 31, 2026 at 9:00 AM Greg Kroah-Hartman
<gregkh at linuxfoundation.org> wrote:
>
> On Sat, Oct 31, 2026 at 12:37:47PM +0000, Samarth Narang wrote:
> > This series addresses the DMA buffer lifetime issues in amba-pl011 and
> > fsl_lpuart reported in the parent thread, where flush_buffer() unmaps
> > the TX buffer before the terminated DMA transfer is guaranteed to have
> > stopped accessing it. In fsl_lpuart, the buffer is unmapped even before
> > termination is requested.
> >
> > Since flush_buffer() runs under the port lock and cannot wait for DMA
> > termination, both patches request termination while holding the lock and
> > defer unmapping to a work item that first calls dmaengine_synchronize().
> > The TX completion callback leaves the cleanup of flushed transfers to
> > this work item, while shutdown, and suspend in the case of fsl_lpuart,
> > waits for the work to finish before releasing the TX DMA state.
> >
> > Both patches have only been compile-tested with arm64 defconfig, the
> > relevant drivers enabled, and W=1, with no new warnings. I do not have
> > access to PL011 or LPUART hardware with DMA support, so testing by
> > someone with suitable hardware would be appreciated.
> >
> > The imx driver also needs a fix for the issue reported in the same
> > thread, but requires a different approach because its TX completion
> > callback unmaps the scatterlist unconditionally. I will send that patch
> > separately.
>
> Again, these need to be tested on real hardware. Not to mention the
> bugs that sashiko just found in the changes as well.
>
> thanks,
>
> greg k-h
More information about the linux-arm-kernel
mailing list