[PATCH v2 0/3] spi: tegra210-quad: Fix timeout path status handling and DMA leak

[Vishwaroop A]

Three fixes in the Tegra QSPI transfer timeout path: the two from v1, plus
one new patch out of Mark's review.

Patch 1 fixes a regression from commit 1ff82c13ea94 ("spi: tegra210-quad:
Cache TRANS_STATUS in ISR for timeout handler"), currently in linux-next
only. When tegra_qspi_handle_timeout() observes a real ISR completion
after draining the workqueue, it still publishes the pre-drain lost-IRQ
FIFO snapshot. That snapshot can hold zeroed error bits if the ISR W1C-ed
the hardware between the two reads, which makes the manual completion
handler downstream accept a transfer that actually reported a FIFO
underflow or overflow. No stable backport is needed because the offending
commit has not been released.

Patch 2 is new in v2. Mark observed that the unmap added by patch 3 can
run for a transfer flagged as DMA that has nothing mapped, which happens
when one chunk of a multi-chunk transfer completes and the next fails in
tegra_qspi_dma_map_xfer(). The same hazard is already reachable through
handle_dma_based_xfer()'s own cleanup, so rather than special-case the new
site this records the mapping state and makes tegra_qspi_dma_unmap_xfer()
a no-op when nothing is outstanding. Failing the transfer on a start
error, the other option Mark offered, is left for a follow-up along with
the mappings leaked by tegra_qspi_start_dma_based_transfer()'s own error
returns. Tagged for stable.

Patch 3 fixes a DMA mapping leak present since the driver was added. The
only unmap lives in handle_dma_based_xfer(), which runs from the interrupt
bottom half, so on a genuine timeout the bottom half never runs and both
transfer paths abort without unmapping. Every real timeout therefore leaks
the streaming mappings for that chunk, gradually exhausting the IOVA space
on systems with an IOMMU in front of QSPI. Tagged for stable, and it has
to be applied after patch 2, which its stable tag records.

Neither patch 2 nor patch 3 applies to a released tree as posted, although
both bugs are older than the code they are written against: patch 2 needs
tqspi->tx_dma_dev and tqspi->rx_dma_dev from commit f469138a77ac, itself
still linux-next only, and patch 3 collides with the WARN_ON() calls added
to the timeout paths after v6.19. I will send adapted backports once this
series lands.

Changes in v2:
 - New patch 2 recording DMA mapping state, so patch 3's unmap cannot run
   against a stale or never-created mapping (Mark Brown).
 - Picked up Breno's Reviewed-by on patch 1.
 - Recorded patch 2 as a stable prerequisite on patch 3's tag.
 - Rebased onto next-20261023; patch 1 and patch 3 code is unchanged.

v1: https://lore.kernel.org/r/20261016132520.3723412-1-va@xxxxxxxxxx

Vishwaroop A (3):
  spi: tegra210-quad: don't overwrite refreshed status with lost-IRQ
    snapshot
  spi: tegra210-quad: Track DMA mapping state
  spi: tegra210-quad: Unmap DMA buffers on transfer timeout

 drivers/spi/spi-tegra210-quad.c | 52 ++++++++++++++++++++++++++-------
 1 file changed, 42 insertions(+), 10 deletions(-)


base-commit: 20a33c6b6cbe7e4805dfb6cd68816937443aa148
-- 
2.17.1