PCI: designware: Explain why we don't program ATU for some platforms

Some platforms don't support ATU, e.g., pci-keystone.c.  These platforms
use their own address translation component rather than ATU, and they
provide the rd_other_conf and wr_other_conf methods to program the
translation component and perform the access.

Add a comment to explain why we don't program the ATU for these platforms.

[bhelgaas: changelog]
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index 21716827847a8ab02f1123a49ffc23141571ebc9..8bcaed18f0dd3eeb818e7f7a7c326df595c2fe9e 100644 (file)
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -517,6 +517,11 @@ int dw_pcie_host_init(struct pcie_port *pp)
        if (pp->ops->host_init)
                pp->ops->host_init(pp);
 
+       /*
+        * If the platform provides ->rd_other_conf, it means the platform
+        * uses its own address translation component rather than ATU, so
+        * we should not program the ATU here.
+        */
        if (!pp->ops->rd_other_conf)
                dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
                                          PCIE_ATU_TYPE_MEM, pp->mem_base,