From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: spi: tegra210-quad: Allocate DMA memory for DMA engine
Date: Tue, 26 May 2026 07:40:38 +1000
Message-ID: <review-patch1-20260525-tegra194-qspi-iommu-v2-1-a11c53f804b2@gmail.com>
In-Reply-To: <20260525-tegra194-qspi-iommu-v2-1-a11c53f804b2@gmail.com>
References: <20260525-tegra194-qspi-iommu-v2-0-a11c53f804b2@gmail.com> <20260525-tegra194-qspi-iommu-v2-1-a11c53f804b2@gmail.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Patch Review

This is the substantive driver change. It adds `rx_dma_dev` and `tx_dma_dev` fields to `struct tegra_qspi` and uses them consistently throughout all DMA API calls.

**Structure additions look correct:**
```c
+	struct device				*rx_dma_dev;
 	struct dma_chan				*rx_dma_chan;
...
+	struct device				*tx_dma_dev;
 	struct dma_chan				*tx_dma_chan;
```
Placed logically next to their associated DMA channel pointers.

**DMA device initialization is correct for the `has_ext_dma` path:**
```c
 		tqspi->rx_dma_chan = dma_chan;
+		tqspi->rx_dma_dev = dmaengine_get_dma_device(tqspi->rx_dma_chan);
...
 		tqspi->tx_dma_chan = dma_chan;
+		tqspi->tx_dma_dev = dmaengine_get_dma_device(tqspi->tx_dma_chan);
```
`dmaengine_get_dma_device()` returns either the channel-specific DMA device or the DMA controller's device, which is exactly what should be passed to `dma_map_single()` / `dma_alloc_coherent()`.

**Fallback path (non-ext-dma) is correct:**
```c
+		tqspi->rx_dma_dev = tqspi->dev;
+		tqspi->tx_dma_dev = tqspi->dev;
```
When there's no external DMA engine (e.g. tegra234 with internal DMA), the SPI controller device itself is appropriate.

**Minor observation on the error path in `tegra_qspi_dma_map_xfer`:**
```c
 	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);
```
The error path correctly unmaps `t->tx_dma` using `tqspi->tx_dma_dev`. This is a pre-existing pattern where the unmap happens unconditionally on the error path even if `t->tx_buf` was NULL (so tx_dma was never mapped). That's a pre-existing issue, not introduced by this patch, but worth noting.

**All `dma_alloc_coherent`, `dma_free_coherent`, `dma_map_single`, `dma_unmap_single` call sites have been updated consistently.** I verified each callsite against the upstream code and they all match.

**One question:** The commit message says "Pass the DMA engine's struct device pointer to the DMA API to make sure the correct DMA operations are used." This is good, but it might be worth adding a `Fixes:` tag if there is a specific commit that introduced the broken behavior, since this fixes real DMA/IOMMU faults. The cover letter mentions this fixes transfers on p3668/p3518 modules. A `Fixes:` tag would help stable backporters.

---
Generated by Claude Code Patch Reviewer