Re: [PATCH 3/3] arm64: tegra: Add iommu and dma properties for Tegra194 QSPI

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Hardware misrepresentation: QSPI node falsely claims GPCDMA's SMMU Stream ID to mask a driver bug
--

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

arm64: tegra: Add iommu and dma properties for Tegra194 QSPI

This commit adds DMA and IOMMU properties to the QSPI controller nodes for
Tegra194. The commit message indicates these are required to prevent flash
storage transfers from timing out.

> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index 1d659454a6f9f..0e0a20befe9e6 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -923,6 +923,10 @@ spi@3270000 {
>  				 <&bpmp TEGRA194_CLK_QSPI0_PM>;
>  			clock-names = "qspi", "qspi_out";
>  			resets = <&bpmp TEGRA194_RESET_QSPI0>;
> +			iommus = <&smmu TEGRA194_SID_GPCDMA_0>;

Does assigning the GPCDMA's Stream ID to the QSPI node misrepresent the
hardware topology?

TEGRA194_SID_GPCDMA_0 physically belongs to the external GPCDMA controller,
which is the actual bus master performing the DMA transfers. Device trees
must strictly describe hardware. 

It appears this configuration might be masking a driver bug in
drivers/spi/spi-tegra210-quad.c, where tegra_qspi_dma_map_xfer() maps buffers
against the QSPI device rather than the DMA engine's device pointer. Faking
the same Stream ID places both devices in the same SMMU group, which avoids
translation faults but breaks IOMMU isolation.

Should the driver be fixed to map memory using the DMA provider's device
pointer instead of adding the iommus and dma-coherent properties to the QSPI
nodes?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515-tegra194-qspi-iommu-v1-0-57dfb63cd3d6@gmail.com?part=3