[PATCH v2 0/2] arm64: tegra: Enable DMA Support on Tegra194 QSPI

[PATCH v2 0/2] arm64: tegra: Enable DMA Support on Tegra194 QSPI

[Aaron Kling via B4 Relay]

The reason for this is to properly support the spi nor chip on the
Jetson Xavier NX module. Prior to this, it would time out on all
transfers and sometimes even trigger a cbb fault, locking up the entire
unit. With this, reading and writing to the flash memory works as
expected.

This also fixes the tegra210-quad spi driver to properly use the dma
memory space instead of the spi controllers. Without this, enabling dma
on the controllers results in mmu faults.

The driver change has only been tested on tegra210 / p3450 and tegra194
/ p3518 as that is the only available test platforms. Tegra234 and
Tegra241 should also be verified. I have p3766 for tegra234, but the
qspi flash memory is firewalled by mb1 on all publicly available
bootloaders, and no other spi devices are part of the devkit.

---
Changes in v2:
- Drop bindings patches
- Add patch to use dma memory space instead of the spi controllers when
  dma is enabled.
- Drop iommu properties from final patch
- Link to v1: https://lore.kernel.org/r/20260515-tegra194-qspi-iommu-v1-0-57dfb63cd3d6@gmail.com

---
Aaron Kling (2):
      spi: tegra210-quad: Allocate DMA memory for DMA engine
      arm64: tegra: Enable DMA Support on Tegra194 QSPI

 arch/arm64/boot/dts/nvidia/tegra194.dtsi |  4 ++++
 drivers/spi/spi-tegra210-quad.c          | 29 ++++++++++++++++++-----------
 2 files changed, 22 insertions(+), 11 deletions(-)
---
base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
change-id: 20260515-tegra194-qspi-iommu-e4e4644d5fdf

Best regards,
-- 
Aaron Kling <webgeek1234@gmail.com>

[PATCH v2 1/2] spi: tegra210-quad: Allocate DMA memory for DMA engine

[Aaron Kling via B4 Relay]

From: Aaron Kling <webgeek1234@gmail.com>

When the SPI controllers are running in DMA mode, it is the DMA engine
that performs the memory accesses rather than the SPI controller. Pass
the DMA engine's struct device pointer to the DMA API to make sure the
correct DMA operations are used.

Suggested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 drivers/spi/spi-tegra210-quad.c | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/spi-tegra210-quad.c b/drivers/spi/spi-tegra210-quad.c
index db28dd556484b2..588a929a97850a 100644
--- a/drivers/spi/spi-tegra210-quad.c
+++ b/drivers/spi/spi-tegra210-quad.c
@@ -226,11 +226,13 @@ struct tegra_qspi {
 	struct completion			xfer_completion;
 	struct spi_transfer			*curr_xfer;
 
+	struct device				*rx_dma_dev;
 	struct dma_chan				*rx_dma_chan;
 	u32					*rx_dma_buf;
 	dma_addr_t				rx_dma_phys;
 	struct dma_async_tx_descriptor		*rx_dma_desc;
 
+	struct device				*tx_dma_dev;
 	struct dma_chan				*tx_dma_chan;
 	u32					*tx_dma_buf;
 	dma_addr_t				tx_dma_phys;
@@ -574,15 +576,15 @@ static int tegra_qspi_dma_map_xfer(struct tegra_qspi *tqspi, struct spi_transfer
 	len = DIV_ROUND_UP(tqspi->curr_dma_words * tqspi->bytes_per_word, 4) * 4;
 
 	if (t->tx_buf) {
-		t->tx_dma = dma_map_single(tqspi->dev, (void *)tx_buf, len, DMA_TO_DEVICE);
-		if (dma_mapping_error(tqspi->dev, t->tx_dma))
+		t->tx_dma = dma_map_single(tqspi->tx_dma_dev, (void *)tx_buf, len, DMA_TO_DEVICE);
+		if (dma_mapping_error(tqspi->tx_dma_dev, t->tx_dma))
 			return -ENOMEM;
 	}
 
 	if (t->rx_buf) {
-		t->rx_dma = dma_map_single(tqspi->dev, (void *)rx_buf, len, DMA_FROM_DEVICE);
-		if (dma_mapping_error(tqspi->dev, t->rx_dma)) {
-			dma_unmap_single(tqspi->dev, t->tx_dma, len, DMA_TO_DEVICE);
+		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);
 			return -ENOMEM;
 		}
 	}
@@ -597,9 +599,9 @@ static void tegra_qspi_dma_unmap_xfer(struct tegra_qspi *tqspi, struct spi_trans
 	len = DIV_ROUND_UP(tqspi->curr_dma_words * tqspi->bytes_per_word, 4) * 4;
 
 	if (t->tx_buf)
-		dma_unmap_single(tqspi->dev, t->tx_dma, len, DMA_TO_DEVICE);
+		dma_unmap_single(tqspi->tx_dma_dev, t->tx_dma, len, DMA_TO_DEVICE);
 	if (t->rx_buf)
-		dma_unmap_single(tqspi->dev, t->rx_dma, len, DMA_FROM_DEVICE);
+		dma_unmap_single(tqspi->rx_dma_dev, t->rx_dma, len, DMA_FROM_DEVICE);
 }
 
 static int tegra_qspi_start_dma_based_transfer(struct tegra_qspi *tqspi, struct spi_transfer *t)
@@ -745,7 +747,7 @@ static int tegra_qspi_start_cpu_based_transfer(struct tegra_qspi *qspi, struct s
 static void tegra_qspi_deinit_dma(struct tegra_qspi *tqspi)
 {
 	if (tqspi->tx_dma_buf) {
-		dma_free_coherent(tqspi->dev, tqspi->dma_buf_size,
+		dma_free_coherent(tqspi->tx_dma_dev, tqspi->dma_buf_size,
 				  tqspi->tx_dma_buf, tqspi->tx_dma_phys);
 		tqspi->tx_dma_buf = NULL;
 	}
@@ -756,7 +758,7 @@ static void tegra_qspi_deinit_dma(struct tegra_qspi *tqspi)
 	}
 
 	if (tqspi->rx_dma_buf) {
-		dma_free_coherent(tqspi->dev, tqspi->dma_buf_size,
+		dma_free_coherent(tqspi->rx_dma_dev, tqspi->dma_buf_size,
 				  tqspi->rx_dma_buf, tqspi->rx_dma_phys);
 		tqspi->rx_dma_buf = NULL;
 	}
@@ -782,6 +784,7 @@ static int tegra_qspi_init_dma(struct tegra_qspi *tqspi)
 		}
 
 		tqspi->rx_dma_chan = dma_chan;
+		tqspi->rx_dma_dev = dmaengine_get_dma_device(tqspi->rx_dma_chan);
 
 		dma_chan = dma_request_chan(tqspi->dev, "tx");
 		if (IS_ERR(dma_chan)) {
@@ -790,15 +793,19 @@ static int tegra_qspi_init_dma(struct tegra_qspi *tqspi)
 		}
 
 		tqspi->tx_dma_chan = dma_chan;
+		tqspi->tx_dma_dev = dmaengine_get_dma_device(tqspi->tx_dma_chan);
 	} else {
 		if (!device_iommu_mapped(tqspi->dev)) {
 			dev_warn(tqspi->dev,
 				 "IOMMU not enabled in device-tree, falling back to PIO mode\n");
 			return 0;
 		}
+
+		tqspi->rx_dma_dev = tqspi->dev;
+		tqspi->tx_dma_dev = tqspi->dev;
 	}
 
-	dma_buf = dma_alloc_coherent(tqspi->dev, tqspi->dma_buf_size, &dma_phys, GFP_KERNEL);
+	dma_buf = dma_alloc_coherent(tqspi->rx_dma_dev, tqspi->dma_buf_size, &dma_phys, GFP_KERNEL);
 	if (!dma_buf) {
 		err = -ENOMEM;
 		goto err_out;
@@ -807,7 +814,7 @@ static int tegra_qspi_init_dma(struct tegra_qspi *tqspi)
 	tqspi->rx_dma_buf = dma_buf;
 	tqspi->rx_dma_phys = dma_phys;
 
-	dma_buf = dma_alloc_coherent(tqspi->dev, tqspi->dma_buf_size, &dma_phys, GFP_KERNEL);
+	dma_buf = dma_alloc_coherent(tqspi->tx_dma_dev, tqspi->dma_buf_size, &dma_phys, GFP_KERNEL);
 	if (!dma_buf) {
 		err = -ENOMEM;
 		goto err_out;

-- 
2.53.0

Re: [PATCH v2 1/2] spi: tegra210-quad: Allocate DMA memory for DMA engine

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] Unconditional DMA unmapping in tegra_qspi_dma_unmap_xfer() causes invalid unmaps for unpacked transfers.
- [High] The error path in tegra_qspi_dma_map_xfer() unmaps tx_dma without verifying if tx_buf was provided.
- [High] Aligning the DMA transfer length up to a multiple of 4 bytes can cause the DMA engine to write out of bounds.
- [High] DMA mappings are leaked when the transfer times out or when DMA setup fails.
--

commit 78250c2468331b7f824d5bbb2690d151a21edc13
Author: Aaron Kling <webgeek1234@gmail.com>

spi: tegra210-quad: Allocate DMA memory for DMA engine

When the SPI controllers are running in DMA mode, it is the DMA engine
that performs the memory accesses rather than the SPI controller. Pass
the DMA engine's struct device pointer to the DMA API to make sure the
correct DMA operations are used.

> diff --git a/drivers/spi/spi-tegra210-quad.c b/drivers/spi/spi-tegra210-quad.c
> index db28dd556484b..588a929a97850 100644
> --- a/drivers/spi/spi-tegra210-quad.c
> +++ b/drivers/spi/spi-tegra210-quad.c

[ ... ]

> @@ -574,15 +576,15 @@ static int tegra_qspi_dma_map_xfer(struct tegra_qspi *tqspi, struct spi_transfer
>  	len = DIV_ROUND_UP(tqspi->curr_dma_words * tqspi->bytes_per_word, 4) * 4;

[Severity: High]
This isn't a bug introduced by this patch, but could aligning this length up
to a multiple of 4 bytes cause the DMA engine to write out of bounds?

If the client requested a transfer length that is not a multiple of 4 bytes,
the DMA engine will write up to 3 bytes past the end of the client's buffer.

If the buffer lacks sufficient alignment padding, could this cause memory
corruption?

>  
>  	if (t->tx_buf) {
> -		t->tx_dma = dma_map_single(tqspi->dev, (void *)tx_buf, len, DMA_TO_DEVICE);
> -		if (dma_mapping_error(tqspi->dev, t->tx_dma))
> +		t->tx_dma = dma_map_single(tqspi->tx_dma_dev, (void *)tx_buf, len, DMA_TO_DEVICE);
> +		if (dma_mapping_error(tqspi->tx_dma_dev, t->tx_dma))
>  			return -ENOMEM;
>  	}
>  
>  	if (t->rx_buf) {
> -		t->rx_dma = dma_map_single(tqspi->dev, (void *)rx_buf, len, DMA_FROM_DEVICE);
> -		if (dma_mapping_error(tqspi->dev, t->rx_dma)) {
> -			dma_unmap_single(tqspi->dev, t->tx_dma, len, DMA_TO_DEVICE);
> +		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);

[Severity: High]
This isn't a bug introduced by this patch, but does this error path safely
unmap tx_dma?

If t->tx_buf is NULL during a half-duplex RX-only transfer, t->tx_dma is
never mapped.  If the rx_dma mapping then fails, we will attempt to unmap an
uninitialized DMA address here.

Could this corrupt the IOMMU state and trigger faults?

>  			return -ENOMEM;
>  		}
>  	}
> @@ -597,9 +599,9 @@ static void tegra_qspi_dma_unmap_xfer(struct tegra_qspi *tqspi, struct spi_trans
>  	len = DIV_ROUND_UP(tqspi->curr_dma_words * tqspi->bytes_per_word, 4) * 4;
>  
>  	if (t->tx_buf)
> -		dma_unmap_single(tqspi->dev, t->tx_dma, len, DMA_TO_DEVICE);
> +		dma_unmap_single(tqspi->tx_dma_dev, t->tx_dma, len, DMA_TO_DEVICE);
>  	if (t->rx_buf)
> -		dma_unmap_single(tqspi->dev, t->rx_dma, len, DMA_FROM_DEVICE);
> +		dma_unmap_single(tqspi->rx_dma_dev, t->rx_dma, len, DMA_FROM_DEVICE);

[Severity: High]
This isn't a bug introduced by this patch, but can this cause invalid DMA
unmaps for unpacked transfers?

For unpacked transfers, tegra_qspi_start_dma_based_transfer() skips mapping
client buffers and uses a pre-allocated bounce buffer instead.

Since this function is called unconditionally and only checks for the presence
of t->tx_buf and t->rx_buf, it will call dma_unmap_single() on the
uninitialized t->tx_dma and t->rx_dma fields when tqspi->is_packed is false.

>  }
>  
>  static int tegra_qspi_start_dma_based_transfer(struct tegra_qspi *tqspi, struct spi_transfer *t)

[Severity: High]
This isn't a bug introduced by this patch, but are DMA mappings leaked when
the transfer times out or when DMA setup fails?

When tegra_qspi_dma_map_xfer() dynamically maps client buffers, if subsequent
steps like dmaengine_slave_config() fail in this function, the driver returns
immediately without unmapping the buffers.

Additionally, if the DMA transfer times out in
tegra_qspi_transfer_one_message(), it jumps to the exit label and returns
without calling tegra_qspi_dma_unmap_xfer().

Could this permanently leak mapped DMA addresses?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260525-tegra194-qspi-iommu-v2-0-a11c53f804b2@gmail.com?part=1

[PATCH v2 2/2] arm64: tegra: Enable DMA Support on Tegra194 QSPI

[Aaron Kling via B4 Relay]

From: Aaron Kling <webgeek1234@gmail.com>

Without dma enabled pio mode is used and flash storage such as the one
on the p3668 module times out and cannot complete any transfers. In some
cases, these timeouts cause hangs and cbb faults.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 1d659454a6f9fe..e2ddbc6715d5e8 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -923,6 +923,8 @@ spi@3270000 {
 				 <&bpmp TEGRA194_CLK_QSPI0_PM>;
 			clock-names = "qspi", "qspi_out";
 			resets = <&bpmp TEGRA194_RESET_QSPI0>;
+			dmas = <&gpcdma 5>, <&gpcdma 5>;
+			dma-names = "rx", "tx";
 			status = "disabled";
 		};
 
@@ -1013,6 +1015,8 @@ spi@3300000 {
 				 <&bpmp TEGRA194_CLK_QSPI1_PM>;
 			clock-names = "qspi", "qspi_out";
 			resets = <&bpmp TEGRA194_RESET_QSPI1>;
+			dmas = <&gpcdma 6>, <&gpcdma 6>;
+			dma-names = "rx", "tx";
 			status = "disabled";
 		};
 

-- 
2.53.0

Re: [PATCH v2 2/2] arm64: tegra: Enable DMA Support on Tegra194 QSPI

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Calling dma_unmap_single on an unmapped DMA address during the DMA mapping error path.
- [High] DMA buffer overflow causing memory corruption when reading unaligned sizes in packed mode.
--

commit ab48224cb433a33d32049c6cfc39eea2bdf25194
Author: Aaron Kling <webgeek1234@gmail.com>

arm64: tegra: Enable DMA Support on Tegra194 QSPI

Without dma enabled pio mode is used and flash storage such as the one
on the p3668 module times out and cannot complete any transfers. In some
cases, these timeouts cause hangs and cbb faults.

> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index 1d659454a6f9f..e2ddbc6715d5e 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -923,6 +923,8 @@ spi@3270000 {
>  				 <&bpmp TEGRA194_CLK_QSPI0_PM>;
>  			clock-names = "qspi", "qspi_out";
>  			resets = <&bpmp TEGRA194_RESET_QSPI0>;
> +			dmas = <&gpcdma 5>, <&gpcdma 5>;
> +			dma-names = "rx", "tx";

[Severity: High]
This isn't a bug introduced by this patch, but enabling DMA mode exposes a
pre-existing issue in the driver.

In tegra_qspi_dma_map_xfer(), t->tx_dma is mapped conditionally only if
t->tx_buf is non-NULL.

However, if mapping t->rx_buf subsequently fails, the error path
unconditionally calls dma_unmap_single(..., t->tx_dma, ...).

If t->tx_buf was NULL, t->tx_dma is zero or uninitialized.

Could this lead to unmapping an invalid DMA address, potentially corrupting
IOMMU page tables or triggering a panic?

[Severity: High]
This is a pre-existing issue, but directly switching the controller to
DMA mode makes a buffer overflow vulnerability triggerable.

In tegra_qspi_start_dma_based_transfer(), the driver calculates the mapped
and transferred DMA length by rounding up to the nearest multiple of 4:
len = DIV_ROUND_UP(..., 4) * 4.

For an unaligned SPI read (e.g., 5 bytes), len becomes 8. The driver maps 8
bytes and programs the DMA engine to write exactly 8 bytes into the client's
t->rx_buf via dmaengine_prep_slave_single().

Because the client's t->rx_buf is only guaranteed to be the requested 5 bytes
long, does this cause the DMA hardware to blindly overwrite adjacent memory
by 3 bytes?

Could this out-of-bounds write corrupt adjacent heap objects or KASAN
redzones?

>  			status = "disabled";
>  		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260525-tegra194-qspi-iommu-v2-0-a11c53f804b2@gmail.com?part=2

Re: (subset) [PATCH v2 0/2] arm64: tegra: Enable DMA Support on Tegra194 QSPI

[Mark Brown]

On Mon, 25 May 2026 01:47:43 -0500, Aaron Kling wrote:
> arm64: tegra: Enable DMA Support on Tegra194 QSPI
> 
> The reason for this is to properly support the spi nor chip on the
> Jetson Xavier NX module. Prior to this, it would time out on all
> transfers and sometimes even trigger a cbb fault, locking up the entire
> unit. With this, reading and writing to the flash memory works as
> expected.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.2

Thanks!

[1/2] spi: tegra210-quad: Allocate DMA memory for DMA engine
      https://git.kernel.org/broonie/spi/c/f469138a77ac

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark