drivers/iommu/dma-iommu.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
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.
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>
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>
>
>
Hi Leon,
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?
Thanks,
Peng
>
>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>
>>
>>
>
>
On Fri, Sep 18, 2026 at 10:12:24PM +0800, Peng Fan wrote:
> Hi Leon,
>
> 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?
Yes, for both questions.
Thanks
>
> Thanks,
> Peng
>
> >
> >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>
> >>
> >>
> >
> >
>
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
© 2016 - 2026 Red Hat, Inc.