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

[Jeff C. Jensen]

That makes sense. Given the cause is likely a hardware fault, and
that a timeout is generally a sufficient and common recovery, I'll
drop patch 4 from the series in v2.

On Wed, Oct 28, 2026 at 8:16 AM Frank Li <Frank.li@xxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxx> 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
> > >