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

[Marek Szyprowski]

On 18.09.2026 16:12, Peng Fan wrote:
> On Fri, Sep 18, 2026 at 03:37:36PM +0300, Leon Romanovsky wrote:
>> 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.
> My intention with the second patch was to make the DMA_ATTR_MMIO handling
> consistent with iommu_dma_map_phys(), since MMIO cannot be bounced by
> SWIOTLB in either case.
>
> However, I don't have a dma_iova_link() user that requires an
> unaligned MMIO address, so no need to relax the existing restriction there.
>  
> I'll drop the second patch and keep this fix scoped to iommu_dma_map_phys()
> in v2. Does that sounds good to you?
>
> BTW, does patch 1 look good to you?


The first patch looks good, I will apply it as is. For the link case I think that
it needs to be properly documented that non-aligned mapping is not supported.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland