Re: [PATCH RFC 0/2] iommu/dma: Fix DMA_ATTR_MMIO swiotlb rejection

[Leon Romanovsky <leon@kernel.org>]

On Wed, Sep 16, 2026 at 11:23:32PM +0800, Peng Fan (OSS) wrote:
> Commit f9374de14c0e8 ("iommu/dma: implement DMA_ATTR_MMIO for
> iommu_dma_(un)map_phys()") and commit c288d657dd515 ("iommu/dma: implement
> DMA_ATTR_MMIO for dma_iova_link().") added DMA_ATTR_MMIO support to skip
> swiotlb bouncing and cache flushing for MMIO resources. However, both
> implementations placed the DMA_ATTR_MMIO check inside the swiotlb bounce block,
> causing non-page-aligned MMIO mappings to be rejected outright instead of
> skipping the bounce and proceeding to create the IOVA mapping.
> 
> This breaks dma_map_resource() for any non-page-aligned device register when
> behind an IOMMU: DMA controllers that map peripheral FIFO addresses
> (e.g. SPI controller TX/RX data registers) through an IOMMU for per-channel
> isolation.
> 
> Both patches move the DMA_ATTR_MMIO check before the swiotlb block so MMIO,
> resources skip the entire bounce path and fall through directly to the IOMMU
> mapping function.

While I understand the rationale behind the first patch, why do we need the
second one? Do we want to allow unaligned addresses for the _link_ as well?
Current users don't need it.

Thanks

> 
> Tested on NXP i.MX95 with ARM SMMUv3 where the fsl-edma DMA controller maps
> SPI peripheral FIFO registers (non-page-aligned) via dma_map_resource()
> through per-channel IOMMU domains. Only the iommu_dma_map_phys() path was
> exercised; the dma_iova_link() fix is by code inspection of the same pattern.
> 
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Peng Fan (2):
>       iommu/dma: skip swiotlb bounce for DMA_ATTR_MMIO in iommu_dma_map_phys
>       iommu/dma: skip swiotlb bounce for DMA_ATTR_MMIO in dma_iova_link()
> 
>  drivers/iommu/dma-iommu.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> ---
> base-commit: e6e35979777d646fe3c7c94dca7dd32fb25d45f4
> change-id: 20260916-iommu-dma-fix-9f55af1beb46
> 
> Best regards,
> --  
> Peng Fan <peng.fan@nxp.com>
> 
>