* [PATCH v2 2/3] spi: tegra210-quad: Track DMA mapping state
[not found] <20261026111412.3843954-1-va@nvidia.com>
@ 2026-10-26 11:14 ` Vishwaroop A
2026-10-26 11:14 ` [PATCH v2 3/3] spi: tegra210-quad: Unmap DMA buffers on transfer timeout Vishwaroop A
1 sibling, 0 replies; 2+ messages in thread
From: Vishwaroop A @ 2026-10-26 11:14 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, Mark Brown
Cc: Sowjanya Komatineni, Laxman Dewangan, Breno Leitao, Aaron Kling,
Carol Soto, Suresh Mangipudi, Vishwaroop A, linux-tegra,
linux-spi, linux-kernel, stable
tegra_qspi_dma_unmap_xfer() assumes a streaming mapping is always
outstanding and recomputes its length from the live
tqspi->curr_dma_words. Nothing records whether tegra_qspi_dma_map_xfer()
mapped anything, so neither assumption holds.
For a multi-chunk transfer, handle_dma_based_xfer() unmaps the chunk that
just completed, recalculates the parameters for the next chunk, which
overwrites curr_dma_words, and re-arms the hardware. If
tegra_qspi_start_dma_based_transfer() then fails at its
tegra_qspi_dma_map_xfer() call, nothing is mapped. That early return also
sits above the smp_store_release() that clears tqspi->trans_status, so the
previous chunk's QSPI_RDY survives, and the re-arm's return value is never
checked, so handle_dma_based_xfer() returns IRQ_HANDLED without completing
the transfer.
The caller times out, tegra_qspi_handle_timeout() sees the stale QSPI_RDY,
concludes the transfer completed and calls handle_dma_based_xfer() again.
No DMA completion arrives, so num_errors is incremented and
tegra_qspi_dma_unmap_xfer() runs with nothing mapped. t->tx_dma then holds
either the DMA_MAPPING_ERROR sentinel or, if the RX mapping was the one
that failed, the preceding chunk's address that has already been released.
Behind an IOMMU the latter frees an IOVA that may since have been
reallocated.
Record whether a mapping is outstanding and the length that was mapped,
and return early from tegra_qspi_dma_unmap_xfer() when there is nothing to
release. is_dma_mapped is only updated under tqspi->lock, or on the timeout
path after synchronize_irq() and cancel_work_sync() have quiesced the ISR
and the bottom half.
Also skip releasing the TX mapping on the RX failure path unless a TX
mapping was created; t->tx_dma is uninitialised when t->tx_buf is NULL.
Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller")
Suggested-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Vishwaroop A <va@nvidia.com>
---
drivers/spi/spi-tegra210-quad.c | 31 +++++++++++++++++++++++++------
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/spi-tegra210-quad.c b/drivers/spi/spi-tegra210-quad.c
index 4a5933d8112c..d74aa46636ec 100644
--- a/drivers/spi/spi-tegra210-quad.c
+++ b/drivers/spi/spi-tegra210-quad.c
@@ -237,6 +237,17 @@ struct tegra_qspi {
bool is_packed;
bool use_dma;
+ /*
+ * Set while a streaming mapping created by
+ * tegra_qspi_dma_map_xfer() is outstanding, together with the
+ * length that was handed to dma_map_single(). is_curr_dma_xfer
+ * only records that the last armed chunk took the DMA path,
+ * which is not the same thing: a chunk whose mapping failed
+ * leaves the DMA path flagged with nothing mapped.
+ */
+ bool is_dma_mapped;
+ unsigned int dma_map_len;
+
u32 command1_reg;
u32 dma_control_reg;
u32 def_command1_reg;
@@ -606,24 +617,32 @@ static int tegra_qspi_dma_map_xfer(struct tegra_qspi *tqspi, struct spi_transfer
if (t->rx_buf) {
t->rx_dma = dma_map_single(tqspi->rx_dma_dev, (void *)rx_buf, len, DMA_FROM_DEVICE);
if (dma_mapping_error(tqspi->rx_dma_dev, t->rx_dma)) {
- dma_unmap_single(tqspi->tx_dma_dev, t->tx_dma, len, DMA_TO_DEVICE);
+ if (t->tx_buf)
+ dma_unmap_single(tqspi->tx_dma_dev, t->tx_dma,
+ len, DMA_TO_DEVICE);
return -ENOMEM;
}
}
+ tqspi->dma_map_len = len;
+ tqspi->is_dma_mapped = true;
+
return 0;
}
static void tegra_qspi_dma_unmap_xfer(struct tegra_qspi *tqspi, struct spi_transfer *t)
{
- unsigned int len;
-
- len = DIV_ROUND_UP(tqspi->curr_dma_words * tqspi->bytes_per_word, 4) * 4;
+ if (!tqspi->is_dma_mapped)
+ return;
if (t->tx_buf)
- dma_unmap_single(tqspi->tx_dma_dev, t->tx_dma, len, DMA_TO_DEVICE);
+ dma_unmap_single(tqspi->tx_dma_dev, t->tx_dma,
+ tqspi->dma_map_len, DMA_TO_DEVICE);
if (t->rx_buf)
- dma_unmap_single(tqspi->rx_dma_dev, t->rx_dma, len, DMA_FROM_DEVICE);
+ dma_unmap_single(tqspi->rx_dma_dev, t->rx_dma,
+ tqspi->dma_map_len, DMA_FROM_DEVICE);
+
+ tqspi->is_dma_mapped = false;
}
static int tegra_qspi_start_dma_based_transfer(struct tegra_qspi *tqspi, struct spi_transfer *t)
--
2.17.1
^ permalink raw reply related [flat|nested] 2+ messages in thread* [PATCH v2 3/3] spi: tegra210-quad: Unmap DMA buffers on transfer timeout
[not found] <20261026111412.3843954-1-va@nvidia.com>
2026-10-26 11:14 ` [PATCH v2 2/3] spi: tegra210-quad: Track DMA mapping state Vishwaroop A
@ 2026-10-26 11:14 ` Vishwaroop A
1 sibling, 0 replies; 2+ messages in thread
From: Vishwaroop A @ 2026-10-26 11:14 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, Mark Brown
Cc: Sowjanya Komatineni, Laxman Dewangan, Breno Leitao, Aaron Kling,
Carol Soto, Suresh Mangipudi, Vishwaroop A, linux-tegra,
linux-spi, linux-kernel, stable
tegra_qspi_start_dma_based_transfer() maps the client TX/RX buffers with
dma_map_single() via tegra_qspi_dma_map_xfer(). The matching unmap only
happens in handle_dma_based_xfer(), which runs from the interrupt bottom
half.
When wait_for_completion_timeout() expires and tegra_qspi_handle_timeout()
cannot establish that the hardware finished, it returns an error without
the bottom half ever having run. Both transfer paths then abort the
transfer with tegra_qspi_dma_stop(), reset the controller and clear
curr_xfer, but never unmap the buffers. Every genuine transfer timeout
therefore leaks the streaming DMA mappings for that chunk, which
gradually exhausts the IOVA space on systems with an IOMMU in front of
QSPI.
Unmap the transfer after stopping DMA on both timeout error paths. The
unmap is placed after tegra_qspi_dma_stop() so the DMA engine is
quiesced before the mappings go away.
The recovery paths that do reach handle_dma_based_xfer() unmap there
themselves. The preceding patch makes tegra_qspi_dma_unmap_xfer() a no-op
once the mapping is released, so this cleanup cannot unmap twice or run
against a chunk that was never mapped.
Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller")
Cc: stable@vger.kernel.org # with "spi: tegra210-quad: Track DMA mapping state"
Signed-off-by: Vishwaroop A <va@nvidia.com>
---
drivers/spi/spi-tegra210-quad.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-tegra210-quad.c b/drivers/spi/spi-tegra210-quad.c
index d74aa46636ec..58c87c45431a 100644
--- a/drivers/spi/spi-tegra210-quad.c
+++ b/drivers/spi/spi-tegra210-quad.c
@@ -1507,10 +1507,12 @@ static int tegra_qspi_combined_seq_xfer(struct tegra_qspi *tqspi,
dev_err(tqspi->dev, "transfer timeout\n");
/* Abort transfer by resetting pio/dma bit */
- if (tqspi->is_curr_dma_xfer)
+ if (tqspi->is_curr_dma_xfer) {
tegra_qspi_dma_stop(tqspi);
- else
+ tegra_qspi_dma_unmap_xfer(tqspi, xfer);
+ } else {
tegra_qspi_pio_stop(tqspi);
+ }
/* Reset controller if timeout happens */
tegra_qspi_reset(tqspi);
@@ -1624,8 +1626,10 @@ static int tegra_qspi_non_combined_seq_xfer(struct tegra_qspi *tqspi,
WARN_ON(1);
dev_err(tqspi->dev, "transfer timeout\n");
- if (tqspi->is_curr_dma_xfer)
+ if (tqspi->is_curr_dma_xfer) {
tegra_qspi_dma_stop(tqspi);
+ tegra_qspi_dma_unmap_xfer(tqspi, xfer);
+ }
tegra_qspi_handle_error(tqspi);
ret = -EIO;
--
2.17.1
^ permalink raw reply related [flat|nested] 2+ messages in thread