Re: [PATCH 4/5] dmaengine: xilinx_dma: Withhold an AXI DMA engine whose reset did not complete

[Frank Li <Frank.li@oss.nxp.com>]

On Tue, Oct 27, 2026 at 01:36:27PM -0700, Jeff C. Jensen wrote:
> In theory. I haven't seen a reset time out on our hardware. Every failed
> reset in my testing was injected with fail_function, as the cover letter
> notes.
>
> PG021 describes the soft reset as graceful: "Pending commands/transfers
> are flushed or completed", and the Reset bit reads 1 while the reset is
> in progress. My reading is that a transfer that must complete needs the
> memory side to respond, so a stalled interconnect or memory port would
> keep the reset in progress. The driver already allows for that, since
> xilinx_dma_reset() polls the Reset bit with a timeout and returns an
> error. It just doesn't act on the error: xilinx_dma_terminate_all()
> frees the descriptors and returns 0 regardless, so if the engine is
> still fetching, the next transaction reuses segments the engine owns.
>
> Patch 4 may be more than this series should carry as a fix. One option
> is to drop it from the series and post it with patch 5 as a two-patch
> RFC, scoping failed resets out of this series.

Yes, reset timeout is most likely Triple fault. If timeout happen, most
likely hardware fault and can't recover at all.

We generally choose timeout value is much bigger than enough.

Frank

>
> -Jeff
>
> On Tue, Oct 27, 2026 at 12:22 PM Frank Li <Frank.li@oss.nxp.com> wrote:
> >
> > On Thu, Oct 22, 2026 at 03:11:33PM -0700, Jeff C. Jensen wrote:
> > > When xilinx_dma_chan_reset() times out, all the driver knows is that it
> >
> > Does this real happen? or just in theory
> >
> > Frank
> >