Linux PCI subsystem development
 help / color / mirror / Atom feed
* [PATCH] pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register
@ 2026-08-26  9:11 Sumit Kumar
  2026-08-26  9:26 ` sashiko-bot
  2026-09-02 14:07 ` Manivannan Sadhasivam
  0 siblings, 2 replies; 6+ messages in thread
From: Sumit Kumar @ 2026-08-26  9:11 UTC (permalink / raw)
  To: Jingoo Han, Manivannan Sadhasivam, Lorenzo Pieralisi,
	Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas
  Cc: linux-pci, linux-kernel, Sumit Kumar

Outbound IATU apertures are configured with local device-side addresses.
When DMA engine transactions use destination addresses which fall within
an outbound IATU aperture range, they get unintentionally translated by
the IATU, causing the wrong address to be sent on the PCIe link.
This results in data corruption or IOMMU errors at the host if the
translated address is not mapped.

Set the DMA_BYPASS bit (bit 27) in PCIE_ATU_REGION_CTRL2 when programming
outbound IATU regions to ensure DMA transactions bypass IATU translation
and use their original addresses.

Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com>
---
pci: designware: Set DMA_BYPASS in outbound IATU to prevent HDMA
interception
---
 drivers/pci/controller/dwc/pcie-designware.c | 2 ++
 drivers/pci/controller/dwc/pcie-designware.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
index 593388f29bdd48381cb04710f445042aaf2be29f..9297d0e607e3a1caaeb585b23742f9a29607b7f2 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -577,6 +577,8 @@ int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
 		/* The data-less messages only for now */
 		val |= PCIE_ATU_INHIBIT_PAYLOAD | atu->code;
 	}
+	if (dw_pcie_ver_is_ge(pci, 460A))
+		val |= PCIE_ATU_DMA_BYPASS;
 	dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL2, val);
 
 	/*
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 0735ae94092404bc2976af67a58f6842cc5e5c50..668a5ba1c6f59aef1aaf15566b77a649bd282ce0 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -201,6 +201,7 @@
 #define PCIE_ATU_ENABLE			BIT(31)
 #define PCIE_ATU_BAR_MODE_ENABLE	BIT(30)
 #define PCIE_ATU_CFG_SHIFT_MODE_ENABLE	BIT(28)
+#define PCIE_ATU_DMA_BYPASS		BIT(27)
 #define PCIE_ATU_INHIBIT_PAYLOAD	BIT(22)
 #define PCIE_ATU_FUNC_NUM_MATCH_EN      BIT(19)
 #define PCIE_ATU_LOWER_BASE		0x008

---
base-commit: 45c13f3f9e3bb15fd89ff2864c6f627a3b4b4229
change-id: 20260826-dma_bypass-bbbf8a0c9af7

Best regards,
-- 
Sumit Kumar <sumit.kumar@oss.qualcomm.com>


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register
  2026-08-26  9:11 [PATCH] pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register Sumit Kumar
@ 2026-08-26  9:26 ` sashiko-bot
  2026-09-02 14:07 ` Manivannan Sadhasivam
  1 sibling, 0 replies; 6+ messages in thread
From: sashiko-bot @ 2026-08-26  9:26 UTC (permalink / raw)
  To: Sumit Kumar; +Cc: linux-pci

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditionally setting PCIE_ATU_DMA_BYPASS on all outbound iATU windows breaks built-in eDMA for platforms relying on iATU translation.
--

commit 0264996407d5cc39725b0bb26bca8b42a6f11d18
Author: Sumit Kumar <sumit.kumar@oss.qualcomm.com>

pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register

This commit unconditionally sets the DMA_BYPASS bit in PCIE_ATU_REGION_CTRL2
when programming outbound iATU regions for controllers >= 4.60A. This aims
to prevent unintentional address translation when DMA destination addresses
fall within an outbound iATU aperture.

> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> index 593388f29bdd4..9297d0e607e3a 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -577,6 +577,8 @@ int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
>  		/* The data-less messages only for now */
>  		val |= PCIE_ATU_INHIBIT_PAYLOAD | atu->code;
>  	}
> +	if (dw_pcie_ver_is_ge(pci, 460A))
> +		val |= PCIE_ATU_DMA_BYPASS;
>  	dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL2, val);

[Severity: High]
Does unconditionally setting PCIE_ATU_DMA_BYPASS on all outbound iATU
windows break built-in eDMA for platforms that rely on iATU translation?

When a standard PCI endpoint function driver allocates an outbound memory
window using pci_epc_mem_map(), it gets a local CPU physical address which
is then programmed into the DMA engine.

Because this patch unconditionally bypasses the iATU for DMA, these
platforms will send the raw CPU physical address over the PCIe link instead
of the intended PCIe bus address. Could this regression lead to host memory
corruption, IOMMU faults, or silent data corruption on platforms where the
eDMA expects the iATU to handle the CPU-to-PCI address translation?

To support bypassing safely, would this need to be conditionally enabled via
a platform quirk, or require implementing the .pci_address callback in
dw_pcie_edma_ops to translate the CPU address in software before programming
the eDMA channel?

>  
>  	/*

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826-dma_bypass-v1-1-3a53dc748ce2@oss.qualcomm.com?part=1

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register
  2026-08-26  9:11 [PATCH] pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register Sumit Kumar
  2026-08-26  9:26 ` sashiko-bot
@ 2026-09-02 14:07 ` Manivannan Sadhasivam
  2026-09-02 15:14   ` Krishna Chaitanya Chundru
  1 sibling, 1 reply; 6+ messages in thread
From: Manivannan Sadhasivam @ 2026-09-02 14:07 UTC (permalink / raw)
  To: Sumit Kumar
  Cc: Jingoo Han, Lorenzo Pieralisi, Krzysztof Wilczyński,
	Rob Herring, Bjorn Helgaas, linux-pci, linux-kernel

On Wed, Aug 26, 2026 at 02:41:20PM +0530, Sumit Kumar wrote:
> Outbound IATU apertures are configured with local device-side addresses.
> When DMA engine transactions use destination addresses which fall within
> an outbound IATU aperture range, they get unintentionally translated by
> the IATU, causing the wrong address to be sent on the PCIe link.
> This results in data corruption or IOMMU errors at the host if the
> translated address is not mapped.
> 

Why are you using the same device address in both DMA and iATU mapping? This
sounds like a mapping problem that you should fix instead.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register
  2026-09-02 14:07 ` Manivannan Sadhasivam
@ 2026-09-02 15:14   ` Krishna Chaitanya Chundru
  2026-09-02 16:17     ` Manivannan Sadhasivam
  0 siblings, 1 reply; 6+ messages in thread
From: Krishna Chaitanya Chundru @ 2026-09-02 15:14 UTC (permalink / raw)
  To: Manivannan Sadhasivam, Sumit Kumar
  Cc: Jingoo Han, Lorenzo Pieralisi, Krzysztof Wilczyński,
	Rob Herring, Bjorn Helgaas, linux-pci, linux-kernel



On 9/2/2026 7:37 PM, Manivannan Sadhasivam wrote:
> On Wed, Aug 26, 2026 at 02:41:20PM +0530, Sumit Kumar wrote:
>> Outbound IATU apertures are configured with local device-side addresses.
>> When DMA engine transactions use destination addresses which fall within
>> an outbound IATU aperture range, they get unintentionally translated by
>> the IATU, causing the wrong address to be sent on the PCIe link.
>> This results in data corruption or IOMMU errors at the host if the
>> translated address is not mapped.
>>
> Why are you using the same device address in both DMA and iATU mapping? This
> sounds like a mapping problem that you should fix instead.
issue happens, when host address(DMA destination address) matches with the
internal iova address programmed in iATU src address.
As we can cannot address in both,  we need to program iATU in DMA bypass mode,
so DMA transcations will not go through iATU window.

- Krishna Chaitanya.
>
> - Mani
>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register
  2026-09-02 15:14   ` Krishna Chaitanya Chundru
@ 2026-09-02 16:17     ` Manivannan Sadhasivam
  2026-09-08  6:19       ` Sumit Kumar
  0 siblings, 1 reply; 6+ messages in thread
From: Manivannan Sadhasivam @ 2026-09-02 16:17 UTC (permalink / raw)
  To: Krishna Chaitanya Chundru
  Cc: Sumit Kumar, Jingoo Han, Lorenzo Pieralisi,
	Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, linux-pci,
	linux-kernel

On Wed, Sep 02, 2026 at 08:44:57PM +0530, Krishna Chaitanya Chundru wrote:
> 
> 
> On 9/2/2026 7:37 PM, Manivannan Sadhasivam wrote:
> > On Wed, Aug 26, 2026 at 02:41:20PM +0530, Sumit Kumar wrote:
> >> Outbound IATU apertures are configured with local device-side addresses.
> >> When DMA engine transactions use destination addresses which fall within
> >> an outbound IATU aperture range, they get unintentionally translated by
> >> the IATU, causing the wrong address to be sent on the PCIe link.
> >> This results in data corruption or IOMMU errors at the host if the
> >> translated address is not mapped.
> >>
> > Why are you using the same device address in both DMA and iATU mapping? This
> > sounds like a mapping problem that you should fix instead.
> issue happens, when host address(DMA destination address) matches with the
> internal iova address programmed in iATU src address.
> As we can cannot address in both,  we need to program iATU in DMA bypass mode,
> so DMA transcations will not go through iATU window.
> 

This needs to be explained clearly in the commit message with an example
matching the DWC terminologies such as 'Target Address Registers'.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register
  2026-09-02 16:17     ` Manivannan Sadhasivam
@ 2026-09-08  6:19       ` Sumit Kumar
  0 siblings, 0 replies; 6+ messages in thread
From: Sumit Kumar @ 2026-09-08  6:19 UTC (permalink / raw)
  To: Manivannan Sadhasivam, Krishna Chaitanya Chundru
  Cc: Jingoo Han, Lorenzo Pieralisi, Krzysztof Wilczyński,
	Rob Herring, Bjorn Helgaas, linux-pci, linux-kernel



On 9/2/2026 9:47 PM, Manivannan Sadhasivam wrote:
> On Wed, Sep 02, 2026 at 08:44:57PM +0530, Krishna Chaitanya Chundru wrote:
>>
>> On 9/2/2026 7:37 PM, Manivannan Sadhasivam wrote:
>>> On Wed, Aug 26, 2026 at 02:41:20PM +0530, Sumit Kumar wrote:
>>>> Outbound IATU apertures are configured with local device-side addresses.
>>>> When DMA engine transactions use destination addresses which fall within
>>>> an outbound IATU aperture range, they get unintentionally translated by
>>>> the IATU, causing the wrong address to be sent on the PCIe link.
>>>> This results in data corruption or IOMMU errors at the host if the
>>>> translated address is not mapped.
>>>>
>>> Why are you using the same device address in both DMA and iATU mapping? This
>>> sounds like a mapping problem that you should fix instead.
>> issue happens, when host address(DMA destination address) matches with the
>> internal iova address programmed in iATU src address.
>> As we can cannot address in both,  we need to program iATU in DMA bypass mode,
>> so DMA transcations will not go through iATU window.
>>
> This needs to be explained clearly in the commit message with an example
> matching the DWC terminologies such as 'Target Address Registers'.
>
> - Mani
>
updated in v2.
- Sumit

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-09-08  6:19 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-26  9:11 [PATCH] pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register Sumit Kumar
2026-08-26  9:26 ` sashiko-bot
2026-09-02 14:07 ` Manivannan Sadhasivam
2026-09-02 15:14   ` Krishna Chaitanya Chundru
2026-09-02 16:17     ` Manivannan Sadhasivam
2026-09-08  6:19       ` Sumit Kumar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox