[PATCH 0/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[PATCH 0/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[Krishna Chaitanya Chundru]

This series addresses issues with ECAM enablement in the DesignWare PCIe
host controller when used with vendor drivers that rely on the DBI base
for internal accesses.

The first patch fixes the ECAM logic by introducing a custom PCI ops
implementation that avoids overwriting the DBI base, ensuring compatibility
with vendor drivers that expect a stable DBI address.

The second patch reverts Qualcomm-specific ECAM preparation logic that
is no longer needed due to the updated design.

Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
Krishna Chaitanya Chundru (2):
      PCI: dwc: Fix ECAM enablement when used with vendor drivers
      PCI: dwc: qcom: Revert "PCI: qcom: Prepare for the DWC ECAM enablement"

 drivers/pci/controller/dwc/pcie-designware-host.c | 28 ++++++++--
 drivers/pci/controller/dwc/pcie-qcom.c            | 68 -----------------------
 2 files changed, 24 insertions(+), 72 deletions(-)
---
base-commit: 9b332cece987ee1790b2ed4c989e28162fa47860
change-id: 20251015-ecam_fix-641d1d5ed71d

Best regards,
-- 
Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>

[PATCH 1/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[Krishna Chaitanya Chundru]

When the vendor configuration space is 256MB aligned, the DesignWare
PCIe host driver enables ECAM access and sets the DBI base to the start
of the config space. This causes vendor drivers to incorrectly program
iATU regions, as they rely on the DBI address for internal accesses.

To fix this, avoid overwriting the DBI base when ECAM is enabled.
Instead, introduce a custom ECAM PCI ops implementation that accesses
the DBI region directly for bus 0 and uses ECAM for other buses.

Fixes: f6fd357f7afb ("PCI: dwc: Prepare the driver for enabling ECAM mechanism using iATU 'CFG Shift Feature'")
Reported-by: Ron Economos <re@w6rz.net>
Closes: https://lore.kernel.org/all/eac81c57-1164-4d74-a1b4-6f353c577731@w6rz.net/
Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
 drivers/pci/controller/dwc/pcie-designware-host.c | 28 +++++++++++++++++++----
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 20c9333bcb1c4812e2fd96047a49944574df1e6f..e92513c5bda51bde3a7157033ddbd73afa370d78 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -23,6 +23,7 @@
 #include "pcie-designware.h"
 
 static struct pci_ops dw_pcie_ops;
+static struct pci_ops dw_pcie_ecam_ops;
 static struct pci_ops dw_child_pcie_ops;
 
 #define DW_PCIE_MSI_FLAGS_REQUIRED (MSI_FLAG_USE_DEF_DOM_OPS		| \
@@ -471,9 +472,6 @@ static int dw_pcie_create_ecam_window(struct dw_pcie_rp *pp, struct resource *re
 	if (IS_ERR(pp->cfg))
 		return PTR_ERR(pp->cfg);
 
-	pci->dbi_base = pp->cfg->win;
-	pci->dbi_phys_addr = res->start;
-
 	return 0;
 }
 
@@ -529,7 +527,7 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
 		if (ret)
 			return ret;
 
-		pp->bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
+		pp->bridge->ops = &dw_pcie_ecam_ops;
 		pp->bridge->sysdata = pp->cfg;
 		pp->cfg->priv = pp;
 	} else {
@@ -842,12 +840,34 @@ void __iomem *dw_pcie_own_conf_map_bus(struct pci_bus *bus, unsigned int devfn,
 }
 EXPORT_SYMBOL_GPL(dw_pcie_own_conf_map_bus);
 
+static void __iomem *dw_pcie_ecam_conf_map_bus(struct pci_bus *bus, unsigned int devfn, int where)
+{
+	struct pci_config_window *cfg = bus->sysdata;
+	struct dw_pcie_rp *pp = cfg->priv;
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	unsigned int busn = bus->number;
+
+	if (busn > 0)
+		return pci_ecam_map_bus(bus, devfn, where);
+
+	if (PCI_SLOT(devfn) > 0)
+		return NULL;
+
+	return pci->dbi_base + where;
+}
+
 static struct pci_ops dw_pcie_ops = {
 	.map_bus = dw_pcie_own_conf_map_bus,
 	.read = pci_generic_config_read,
 	.write = pci_generic_config_write,
 };
 
+static struct pci_ops dw_pcie_ecam_ops = {
+	.map_bus = dw_pcie_ecam_conf_map_bus,
+	.read = pci_generic_config_read,
+	.write = pci_generic_config_write,
+};
+
 static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
 {
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);

-- 
2.34.1

Re: [PATCH 1/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[Ron Economos]

On 10/17/25 04:40, Krishna Chaitanya Chundru wrote:
> When the vendor configuration space is 256MB aligned, the DesignWare
> PCIe host driver enables ECAM access and sets the DBI base to the start
> of the config space. This causes vendor drivers to incorrectly program
> iATU regions, as they rely on the DBI address for internal accesses.
>
> To fix this, avoid overwriting the DBI base when ECAM is enabled.
> Instead, introduce a custom ECAM PCI ops implementation that accesses
> the DBI region directly for bus 0 and uses ECAM for other buses.
>
> Fixes: f6fd357f7afb ("PCI: dwc: Prepare the driver for enabling ECAM mechanism using iATU 'CFG Shift Feature'")
> Reported-by: Ron Economos <re@w6rz.net>
> Closes: https://lore.kernel.org/all/eac81c57-1164-4d74-a1b4-6f353c577731@w6rz.net/
> Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
>   drivers/pci/controller/dwc/pcie-designware-host.c | 28 +++++++++++++++++++----
>   1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 20c9333bcb1c4812e2fd96047a49944574df1e6f..e92513c5bda51bde3a7157033ddbd73afa370d78 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -23,6 +23,7 @@
>   #include "pcie-designware.h"
>   
>   static struct pci_ops dw_pcie_ops;
> +static struct pci_ops dw_pcie_ecam_ops;
>   static struct pci_ops dw_child_pcie_ops;
>   
>   #define DW_PCIE_MSI_FLAGS_REQUIRED (MSI_FLAG_USE_DEF_DOM_OPS		| \
> @@ -471,9 +472,6 @@ static int dw_pcie_create_ecam_window(struct dw_pcie_rp *pp, struct resource *re
>   	if (IS_ERR(pp->cfg))
>   		return PTR_ERR(pp->cfg);
>   
> -	pci->dbi_base = pp->cfg->win;
> -	pci->dbi_phys_addr = res->start;
> -
>   	return 0;
>   }
>   
> @@ -529,7 +527,7 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
>   		if (ret)
>   			return ret;
>   
> -		pp->bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
> +		pp->bridge->ops = &dw_pcie_ecam_ops;
>   		pp->bridge->sysdata = pp->cfg;
>   		pp->cfg->priv = pp;
>   	} else {
> @@ -842,12 +840,34 @@ void __iomem *dw_pcie_own_conf_map_bus(struct pci_bus *bus, unsigned int devfn,
>   }
>   EXPORT_SYMBOL_GPL(dw_pcie_own_conf_map_bus);
>   
> +static void __iomem *dw_pcie_ecam_conf_map_bus(struct pci_bus *bus, unsigned int devfn, int where)
> +{
> +	struct pci_config_window *cfg = bus->sysdata;
> +	struct dw_pcie_rp *pp = cfg->priv;
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	unsigned int busn = bus->number;
> +
> +	if (busn > 0)
> +		return pci_ecam_map_bus(bus, devfn, where);
> +
> +	if (PCI_SLOT(devfn) > 0)
> +		return NULL;
> +
> +	return pci->dbi_base + where;
> +}
> +
>   static struct pci_ops dw_pcie_ops = {
>   	.map_bus = dw_pcie_own_conf_map_bus,
>   	.read = pci_generic_config_read,
>   	.write = pci_generic_config_write,
>   };
>   
> +static struct pci_ops dw_pcie_ecam_ops = {
> +	.map_bus = dw_pcie_ecam_conf_map_bus,
> +	.read = pci_generic_config_read,
> +	.write = pci_generic_config_write,
> +};
> +
>   static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
>   {
>   	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>
Works good on the SiFive FU740 controller.

Tested-by: Ron Economos <re@w6rz.net>

Re: [PATCH 1/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[Bjorn Helgaas]

On Fri, Oct 17, 2025 at 05:10:53PM +0530, Krishna Chaitanya Chundru wrote:
> When the vendor configuration space is 256MB aligned, the DesignWare
> PCIe host driver enables ECAM access and sets the DBI base to the start
> of the config space. This causes vendor drivers to incorrectly program
> iATU regions, as they rely on the DBI address for internal accesses.
> 
> To fix this, avoid overwriting the DBI base when ECAM is enabled.
> Instead, introduce a custom ECAM PCI ops implementation that accesses
> the DBI region directly for bus 0 and uses ECAM for other buses.
> 
> Fixes: f6fd357f7afb ("PCI: dwc: Prepare the driver for enabling ECAM mechanism using iATU 'CFG Shift Feature'")
> Reported-by: Ron Economos <re@w6rz.net>
> Closes: https://lore.kernel.org/all/eac81c57-1164-4d74-a1b4-6f353c577731@w6rz.net/
> Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
>  drivers/pci/controller/dwc/pcie-designware-host.c | 28 +++++++++++++++++++----
>  1 file changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 20c9333bcb1c4812e2fd96047a49944574df1e6f..e92513c5bda51bde3a7157033ddbd73afa370d78 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -23,6 +23,7 @@
>  #include "pcie-designware.h"
>  
>  static struct pci_ops dw_pcie_ops;
> +static struct pci_ops dw_pcie_ecam_ops;
>  static struct pci_ops dw_child_pcie_ops;
>  
>  #define DW_PCIE_MSI_FLAGS_REQUIRED (MSI_FLAG_USE_DEF_DOM_OPS		| \
> @@ -471,9 +472,6 @@ static int dw_pcie_create_ecam_window(struct dw_pcie_rp *pp, struct resource *re
>  	if (IS_ERR(pp->cfg))
>  		return PTR_ERR(pp->cfg);
>  
> -	pci->dbi_base = pp->cfg->win;
> -	pci->dbi_phys_addr = res->start;
> -
>  	return 0;
>  }
>  
> @@ -529,7 +527,7 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
>  		if (ret)
>  			return ret;
>  
> -		pp->bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
> +		pp->bridge->ops = &dw_pcie_ecam_ops;
>  		pp->bridge->sysdata = pp->cfg;
>  		pp->cfg->priv = pp;
>  	} else {
> @@ -842,12 +840,34 @@ void __iomem *dw_pcie_own_conf_map_bus(struct pci_bus *bus, unsigned int devfn,
>  }
>  EXPORT_SYMBOL_GPL(dw_pcie_own_conf_map_bus);
>  
> +static void __iomem *dw_pcie_ecam_conf_map_bus(struct pci_bus *bus, unsigned int devfn, int where)
> +{
> +	struct pci_config_window *cfg = bus->sysdata;
> +	struct dw_pcie_rp *pp = cfg->priv;
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	unsigned int busn = bus->number;
> +
> +	if (busn > 0)
> +		return pci_ecam_map_bus(bus, devfn, where);

Is there a way to avoid the "root bus is bus 00" assumption here?  It
looks like something like this might work (it inverts the condition
to take care of the root bus special case first):

  if (bus == pp->bridge->bus) {
    if (PCI_SLOT(devfn) > 0)
      return NULL;

    return pci->dbi_base + where;
  }

  return pci_ecam_map_bus(bus, devfn, where);

> +	if (PCI_SLOT(devfn) > 0)
> +		return NULL;

This essentially says only one function (00.0) can be on the root bus.
I assume that someday that will be relaxed and there may be multiple
Root Ports and maybe RCiEPs on the root bus, so it would be nice if we
didn't have to have this check.

What happens without it?  Does the IP return the ~0 data that the PCI
core would interpret as "there's no device here"?

Regardless, I love this series because it removes quite a bit of code
and seems so much cleaner.

> +	return pci->dbi_base + where;
> +}
> +
>  static struct pci_ops dw_pcie_ops = {
>  	.map_bus = dw_pcie_own_conf_map_bus,
>  	.read = pci_generic_config_read,
>  	.write = pci_generic_config_write,
>  };
>  
> +static struct pci_ops dw_pcie_ecam_ops = {
> +	.map_bus = dw_pcie_ecam_conf_map_bus,
> +	.read = pci_generic_config_read,
> +	.write = pci_generic_config_write,
> +};
> +
>  static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
>  {
>  	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> 
> -- 
> 2.34.1
> 

Re: [PATCH 1/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[Manivannan Sadhasivam]

On Fri, Oct 17, 2025 at 02:10:05PM -0500, Bjorn Helgaas wrote:
> On Fri, Oct 17, 2025 at 05:10:53PM +0530, Krishna Chaitanya Chundru wrote:
> > When the vendor configuration space is 256MB aligned, the DesignWare
> > PCIe host driver enables ECAM access and sets the DBI base to the dw_pcie_ecam_conf_map_busstart
> > of the config space. This causes vendor drivers to incorrectly program
> > iATU regions, as they rely on the DBI address for internal accesses.
> > 
> > To fix this, avoid overwriting the DBI base when ECAM is enabled.
> > Instead, introduce a custom ECAM PCI ops implementation that accesses
> > the DBI region directly for bus 0 and uses ECAM for other buses.
> > 
> > Fixes: f6fd357f7afb ("PCI: dwc: Prepare the driver for enabling ECAM mechanism using iATU 'CFG Shift Feature'")
> > Reported-by: Ron Economos <re@w6rz.net>
> > Closes: https://lore.kernel.org/all/eac81c57-1164-4d74-a1b4-6f353c577731@w6rz.net/
> > Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
> > Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> > ---
> >  drivers/pci/controller/dwc/pcie-designware-host.c | 28 +++++++++++++++++++----
> >  1 file changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> > index 20c9333bcb1c4812e2fd96047a49944574df1e6f..e92513c5bda51bde3a7157033ddbd73afa370d78 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > @@ -23,6 +23,7 @@
> >  #include "pcie-designware.h"
> >  
> >  static struct pci_ops dw_pcie_ops;
> > +static struct pci_ops dw_pcie_ecam_ops;
> >  static struct pci_ops dw_child_pcie_ops;
> >  
> >  #define DW_PCIE_MSI_FLAGS_REQUIRED (MSI_FLAG_USE_DEF_DOM_OPS		| \
> > @@ -471,9 +472,6 @@ static int dw_pcie_create_ecam_window(struct dw_pcie_rp *pp, struct resource *re
> >  	if (IS_ERR(pp->cfg))
> >  		return PTR_ERR(pp->cfg);
> >  
> > -	pci->dbi_base = pp->cfg->win;
> > -	pci->dbi_phys_addr = res->start;
> > -
> >  	return 0;
> >  }
> >  
> > @@ -529,7 +527,7 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
> >  		if (ret)
> >  			return ret;
> >  
> > -		pp->bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
> > +		pp->bridge->ops = &dw_pcie_ecam_ops;
> >  		pp->bridge->sysdata = pp->cfg;
> >  		pp->cfg->priv = pp;
> >  	} else {
> > @@ -842,12 +840,34 @@ void __iomem *dw_pcie_own_conf_map_bus(struct pci_bus *bus, unsigned int devfn,
> >  }
> >  EXPORT_SYMBOL_GPL(dw_pcie_own_conf_map_bus);
> >  
> > +static void __iomem *dw_pcie_ecam_conf_map_bus(struct pci_bus *bus, unsigned int devfn, int where)
> > +{
> > +	struct pci_config_window *cfg = bus->sysdata;
> > +	struct dw_pcie_rp *pp = cfg->priv;
> > +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > +	unsigned int busn = bus->number;
> > +
> > +	if (busn > 0)
> > +		return pci_ecam_map_bus(bus, devfn, where);
> 
> Is there a way to avoid the "root bus is bus 00" assumption here?  It
> looks like something like this might work (it inverts the condition
> to take care of the root bus special case first):
> 
>   if (bus == pp->bridge->bus) {
>     if (PCI_SLOT(devfn) > 0)
>       return NULL;
> 
>     return pci->dbi_base + where;
>   }
> 
>   return pci_ecam_map_bus(bus, devfn, where);
> 

I guess it will work.

> > +	if (PCI_SLOT(devfn) > 0)
> > +		return NULL;
> 
> This essentially says only one function (00.0) can be on the root bus.
> I assume that someday that will be relaxed and there may be multiple
> Root Ports and maybe RCiEPs on the root bus, so it would be nice if we
> didn't have to have this check.
> 
> What happens without it?  Does the IP return the ~0 data that the PCI
> core would interpret as "there's no device here"?
> 

I hope the read returns ~0, but the idea is to catch the invalid access before
trying to read/write. In case of multi Root Port design, I don't think we have a
way to identify it. So maybe it is safe to remove this check.

- Mani

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

Re: [PATCH 1/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[Krishna Chaitanya Chundru]

On 10/18/2025 8:39 AM, Manivannan Sadhasivam wrote:
> On Fri, Oct 17, 2025 at 02:10:05PM -0500, Bjorn Helgaas wrote:
>> On Fri, Oct 17, 2025 at 05:10:53PM +0530, Krishna Chaitanya Chundru wrote:
>>> When the vendor configuration space is 256MB aligned, the DesignWare
>>> PCIe host driver enables ECAM access and sets the DBI base to the dw_pcie_ecam_conf_map_busstart
>>> of the config space. This causes vendor drivers to incorrectly program
>>> iATU regions, as they rely on the DBI address for internal accesses.
>>>
>>> To fix this, avoid overwriting the DBI base when ECAM is enabled.
>>> Instead, introduce a custom ECAM PCI ops implementation that accesses
>>> the DBI region directly for bus 0 and uses ECAM for other buses.
>>>
>>> Fixes: f6fd357f7afb ("PCI: dwc: Prepare the driver for enabling ECAM mechanism using iATU 'CFG Shift Feature'")
>>> Reported-by: Ron Economos <re@w6rz.net>
>>> Closes: https://lore.kernel.org/all/eac81c57-1164-4d74-a1b4-6f353c577731@w6rz.net/
>>> Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
>>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>>> ---
>>>   drivers/pci/controller/dwc/pcie-designware-host.c | 28 +++++++++++++++++++----
>>>   1 file changed, 24 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
>>> index 20c9333bcb1c4812e2fd96047a49944574df1e6f..e92513c5bda51bde3a7157033ddbd73afa370d78 100644
>>> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
>>> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
>>> @@ -23,6 +23,7 @@
>>>   #include "pcie-designware.h"
>>>   
>>>   static struct pci_ops dw_pcie_ops;
>>> +static struct pci_ops dw_pcie_ecam_ops;
>>>   static struct pci_ops dw_child_pcie_ops;
>>>   
>>>   #define DW_PCIE_MSI_FLAGS_REQUIRED (MSI_FLAG_USE_DEF_DOM_OPS		| \
>>> @@ -471,9 +472,6 @@ static int dw_pcie_create_ecam_window(struct dw_pcie_rp *pp, struct resource *re
>>>   	if (IS_ERR(pp->cfg))
>>>   		return PTR_ERR(pp->cfg);
>>>   
>>> -	pci->dbi_base = pp->cfg->win;
>>> -	pci->dbi_phys_addr = res->start;
>>> -
>>>   	return 0;
>>>   }
>>>   
>>> @@ -529,7 +527,7 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
>>>   		if (ret)
>>>   			return ret;
>>>   
>>> -		pp->bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
>>> +		pp->bridge->ops = &dw_pcie_ecam_ops;
>>>   		pp->bridge->sysdata = pp->cfg;
>>>   		pp->cfg->priv = pp;
>>>   	} else {
>>> @@ -842,12 +840,34 @@ void __iomem *dw_pcie_own_conf_map_bus(struct pci_bus *bus, unsigned int devfn,
>>>   }
>>>   EXPORT_SYMBOL_GPL(dw_pcie_own_conf_map_bus);
>>>   
>>> +static void __iomem *dw_pcie_ecam_conf_map_bus(struct pci_bus *bus, unsigned int devfn, int where)
>>> +{
>>> +	struct pci_config_window *cfg = bus->sysdata;
>>> +	struct dw_pcie_rp *pp = cfg->priv;
>>> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>>> +	unsigned int busn = bus->number;
>>> +
>>> +	if (busn > 0)
>>> +		return pci_ecam_map_bus(bus, devfn, where);
>>
>> Is there a way to avoid the "root bus is bus 00" assumption here?  It
>> looks like something like this might work (it inverts the condition
>> to take care of the root bus special case first):
>>
>>    if (bus == pp->bridge->bus) {
>>      if (PCI_SLOT(devfn) > 0)
>>        return NULL;
>>
>>      return pci->dbi_base + where;
>>    }
>>
>>    return pci_ecam_map_bus(bus, devfn, where);
>>
> 
> I guess it will work.
> 
>>> +	if (PCI_SLOT(devfn) > 0)
>>> +		return NULL;
>>
>> This essentially says only one function (00.0) can be on the root bus.
>> I assume that someday that will be relaxed and there may be multiple
>> Root Ports and maybe RCiEPs on the root bus, so it would be nice if we
>> didn't have to have this check.
>>
>> What happens without it?  Does the IP return the ~0 data that the PCI
>> core would interpret as "there's no device here"?
>>
> 
> I hope the read returns ~0, but the idea is to catch the invalid access before
> trying to read/write. In case of multi Root Port design, I don't think we have a
> way to identify it. So maybe it is safe to remove this check.
>
For multi root port we may need to revisit this, currently along with
dbi there are some other registers iATU, elbi etc. So there might be
chances to read these registers like iATU as part of enumeration and
these can return non ~0 values which will have adverse effects.
So we should have this check for now.

- Krishna Chaitanya.

> - Mani
> 

Re: [PATCH 1/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[Krishna Chaitanya Chundru]

On 10/18/2025 2:55 PM, Krishna Chaitanya Chundru wrote:
> 
> 
> On 10/18/2025 8:39 AM, Manivannan Sadhasivam wrote:
>> On Fri, Oct 17, 2025 at 02:10:05PM -0500, Bjorn Helgaas wrote:
>>> On Fri, Oct 17, 2025 at 05:10:53PM +0530, Krishna Chaitanya Chundru 
>>> wrote:
>>>> When the vendor configuration space is 256MB aligned, the DesignWare
>>>> PCIe host driver enables ECAM access and sets the DBI base to the 
>>>> dw_pcie_ecam_conf_map_busstart
>>>> of the config space. This causes vendor drivers to incorrectly program
>>>> iATU regions, as they rely on the DBI address for internal accesses.
>>>>
>>>> To fix this, avoid overwriting the DBI base when ECAM is enabled.
>>>> Instead, introduce a custom ECAM PCI ops implementation that accesses
>>>> the DBI region directly for bus 0 and uses ECAM for other buses.
>>>>
>>>> Fixes: f6fd357f7afb ("PCI: dwc: Prepare the driver for enabling ECAM 
>>>> mechanism using iATU 'CFG Shift Feature'")
>>>> Reported-by: Ron Economos <re@w6rz.net>
>>>> Closes: 
>>>> https://lore.kernel.org/all/eac81c57-1164-4d74-a1b4-6f353c577731@w6rz.net/
>>>> Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
>>>> Signed-off-by: Krishna Chaitanya Chundru 
>>>> <krishna.chundru@oss.qualcomm.com>
>>>> ---
>>>>   drivers/pci/controller/dwc/pcie-designware-host.c | 28 
>>>> +++++++++++++++++++----
>>>>   1 file changed, 24 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c 
>>>> b/drivers/pci/controller/dwc/pcie-designware-host.c
>>>> index 
>>>> 20c9333bcb1c4812e2fd96047a49944574df1e6f..e92513c5bda51bde3a7157033ddbd73afa370d78 100644
>>>> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
>>>> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
>>>> @@ -23,6 +23,7 @@
>>>>   #include "pcie-designware.h"
>>>>   static struct pci_ops dw_pcie_ops;
>>>> +static struct pci_ops dw_pcie_ecam_ops;
>>>>   static struct pci_ops dw_child_pcie_ops;
>>>>   #define DW_PCIE_MSI_FLAGS_REQUIRED 
>>>> (MSI_FLAG_USE_DEF_DOM_OPS        | \
>>>> @@ -471,9 +472,6 @@ static int dw_pcie_create_ecam_window(struct 
>>>> dw_pcie_rp *pp, struct resource *re
>>>>       if (IS_ERR(pp->cfg))
>>>>           return PTR_ERR(pp->cfg);
>>>> -    pci->dbi_base = pp->cfg->win;
>>>> -    pci->dbi_phys_addr = res->start;
>>>> -
>>>>       return 0;
>>>>   }
>>>> @@ -529,7 +527,7 @@ static int dw_pcie_host_get_resources(struct 
>>>> dw_pcie_rp *pp)
>>>>           if (ret)
>>>>               return ret;
>>>> -        pp->bridge->ops = (struct pci_ops 
>>>> *)&pci_generic_ecam_ops.pci_ops;
>>>> +        pp->bridge->ops = &dw_pcie_ecam_ops;
>>>>           pp->bridge->sysdata = pp->cfg;
>>>>           pp->cfg->priv = pp;
>>>>       } else {
>>>> @@ -842,12 +840,34 @@ void __iomem *dw_pcie_own_conf_map_bus(struct 
>>>> pci_bus *bus, unsigned int devfn,
>>>>   }
>>>>   EXPORT_SYMBOL_GPL(dw_pcie_own_conf_map_bus);
>>>> +static void __iomem *dw_pcie_ecam_conf_map_bus(struct pci_bus *bus, 
>>>> unsigned int devfn, int where)
>>>> +{
>>>> +    struct pci_config_window *cfg = bus->sysdata;
>>>> +    struct dw_pcie_rp *pp = cfg->priv;
>>>> +    struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>>>> +    unsigned int busn = bus->number;
>>>> +
>>>> +    if (busn > 0)
>>>> +        return pci_ecam_map_bus(bus, devfn, where);
>>>
>>> Is there a way to avoid the "root bus is bus 00" assumption here?  It
>>> looks like something like this might work (it inverts the condition
>>> to take care of the root bus special case first):
>>>
>>>    if (bus == pp->bridge->bus) {
>>>      if (PCI_SLOT(devfn) > 0)
>>>        return NULL;
>>>
>>>      return pci->dbi_base + where;
>>>    }
>>>
>>>    return pci_ecam_map_bus(bus, devfn, where);
>>>
>>
>> I guess it will work.
>>
>>>> +    if (PCI_SLOT(devfn) > 0)
>>>> +        return NULL;
>>>
>>> This essentially says only one function (00.0) can be on the root bus.
>>> I assume that someday that will be relaxed and there may be multiple
>>> Root Ports and maybe RCiEPs on the root bus, so it would be nice if we
>>> didn't have to have this check.
>>>
>>> What happens without it?  Does the IP return the ~0 data that the PCI
>>> core would interpret as "there's no device here"?
>>>
>>
>> I hope the read returns ~0, but the idea is to catch the invalid 
>> access before
>> trying to read/write. In case of multi Root Port design, I don't think 
>> we have a
>> way to identify it. So maybe it is safe to remove this check.
>>
> For multi root port we may need to revisit this, currently along with
> dbi there are some other registers iATU, elbi etc. So there might be
> chances to read these registers like iATU as part of enumeration and
> these can return non ~0 values which will have adverse effects.
> So we should have this check for now.
> 
One more issue is some controllers may pass only 4k memory as dbi memory
so we might get unmapped address access issues also.
- Krishna Chaitanya.
> - Krishna Chaitanya.
> 
>> - Mani
>>

Re: [PATCH 1/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[Manivannan Sadhasivam]

On Sat, Oct 18, 2025 at 03:00:32PM +0530, Krishna Chaitanya Chundru wrote:
> 
> 
> On 10/18/2025 2:55 PM, Krishna Chaitanya Chundru wrote:
> > 
> > 
> > On 10/18/2025 8:39 AM, Manivannan Sadhasivam wrote:
> > > On Fri, Oct 17, 2025 at 02:10:05PM -0500, Bjorn Helgaas wrote:
> > > > On Fri, Oct 17, 2025 at 05:10:53PM +0530, Krishna Chaitanya
> > > > Chundru wrote:
> > > > > When the vendor configuration space is 256MB aligned, the DesignWare
> > > > > PCIe host driver enables ECAM access and sets the DBI base
> > > > > to the dw_pcie_ecam_conf_map_busstart
> > > > > of the config space. This causes vendor drivers to incorrectly program
> > > > > iATU regions, as they rely on the DBI address for internal accesses.
> > > > > 
> > > > > To fix this, avoid overwriting the DBI base when ECAM is enabled.
> > > > > Instead, introduce a custom ECAM PCI ops implementation that accesses
> > > > > the DBI region directly for bus 0 and uses ECAM for other buses.
> > > > > 
> > > > > Fixes: f6fd357f7afb ("PCI: dwc: Prepare the driver for
> > > > > enabling ECAM mechanism using iATU 'CFG Shift Feature'")
> > > > > Reported-by: Ron Economos <re@w6rz.net>
> > > > > Closes: https://lore.kernel.org/all/eac81c57-1164-4d74-a1b4-6f353c577731@w6rz.net/
> > > > > Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
> > > > > Signed-off-by: Krishna Chaitanya Chundru
> > > > > <krishna.chundru@oss.qualcomm.com>
> > > > > ---
> > > > >   drivers/pci/controller/dwc/pcie-designware-host.c | 28
> > > > > +++++++++++++++++++----
> > > > >   1 file changed, 24 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git
> > > > > a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > index 20c9333bcb1c4812e2fd96047a49944574df1e6f..e92513c5bda51bde3a7157033ddbd73afa370d78
> > > > > 100644
> > > > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > > @@ -23,6 +23,7 @@
> > > > >   #include "pcie-designware.h"
> > > > >   static struct pci_ops dw_pcie_ops;
> > > > > +static struct pci_ops dw_pcie_ecam_ops;
> > > > >   static struct pci_ops dw_child_pcie_ops;
> > > > >   #define DW_PCIE_MSI_FLAGS_REQUIRED
> > > > > (MSI_FLAG_USE_DEF_DOM_OPS        | \
> > > > > @@ -471,9 +472,6 @@ static int
> > > > > dw_pcie_create_ecam_window(struct dw_pcie_rp *pp, struct
> > > > > resource *re
> > > > >       if (IS_ERR(pp->cfg))
> > > > >           return PTR_ERR(pp->cfg);
> > > > > -    pci->dbi_base = pp->cfg->win;
> > > > > -    pci->dbi_phys_addr = res->start;
> > > > > -
> > > > >       return 0;
> > > > >   }
> > > > > @@ -529,7 +527,7 @@ static int
> > > > > dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
> > > > >           if (ret)
> > > > >               return ret;
> > > > > -        pp->bridge->ops = (struct pci_ops
> > > > > *)&pci_generic_ecam_ops.pci_ops;
> > > > > +        pp->bridge->ops = &dw_pcie_ecam_ops;
> > > > >           pp->bridge->sysdata = pp->cfg;
> > > > >           pp->cfg->priv = pp;
> > > > >       } else {
> > > > > @@ -842,12 +840,34 @@ void __iomem
> > > > > *dw_pcie_own_conf_map_bus(struct pci_bus *bus, unsigned int
> > > > > devfn,
> > > > >   }
> > > > >   EXPORT_SYMBOL_GPL(dw_pcie_own_conf_map_bus);
> > > > > +static void __iomem *dw_pcie_ecam_conf_map_bus(struct
> > > > > pci_bus *bus, unsigned int devfn, int where)
> > > > > +{
> > > > > +    struct pci_config_window *cfg = bus->sysdata;
> > > > > +    struct dw_pcie_rp *pp = cfg->priv;
> > > > > +    struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > > > > +    unsigned int busn = bus->number;
> > > > > +
> > > > > +    if (busn > 0)
> > > > > +        return pci_ecam_map_bus(bus, devfn, where);
> > > > 
> > > > Is there a way to avoid the "root bus is bus 00" assumption here?  It
> > > > looks like something like this might work (it inverts the condition
> > > > to take care of the root bus special case first):
> > > > 
> > > >    if (bus == pp->bridge->bus) {
> > > >      if (PCI_SLOT(devfn) > 0)
> > > >        return NULL;
> > > > 
> > > >      return pci->dbi_base + where;
> > > >    }
> > > > 
> > > >    return pci_ecam_map_bus(bus, devfn, where);
> > > > 
> > > 
> > > I guess it will work.
> > > 
> > > > > +    if (PCI_SLOT(devfn) > 0)
> > > > > +        return NULL;
> > > > 
> > > > This essentially says only one function (00.0) can be on the root bus.
> > > > I assume that someday that will be relaxed and there may be multiple
> > > > Root Ports and maybe RCiEPs on the root bus, so it would be nice if we
> > > > didn't have to have this check.
> > > > 
> > > > What happens without it?  Does the IP return the ~0 data that the PCI
> > > > core would interpret as "there's no device here"?
> > > > 
> > > 
> > > I hope the read returns ~0, but the idea is to catch the invalid
> > > access before
> > > trying to read/write. In case of multi Root Port design, I don't
> > > think we have a
> > > way to identify it. So maybe it is safe to remove this check.
> > > 
> > For multi root port we may need to revisit this, currently along with
> > dbi there are some other registers iATU, elbi etc. So there might be
> > chances to read these registers like iATU as part of enumeration and
> > these can return non ~0 values which will have adverse effects.
> > So we should have this check for now.
> > 
> One more issue is some controllers may pass only 4k memory as dbi memory
> so we might get unmapped address access issues also.

Oh yes. The single Root Port controllers might supply only 4KiB of the DBI
space, so without the check, the driver could read/write past the mapped space.

Good catch!

- Mani

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

Re: [PATCH 1/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[Krishna Chaitanya Chundru]

On 10/18/2025 12:40 AM, Bjorn Helgaas wrote:
> On Fri, Oct 17, 2025 at 05:10:53PM +0530, Krishna Chaitanya Chundru wrote:
>> When the vendor configuration space is 256MB aligned, the DesignWare
>> PCIe host driver enables ECAM access and sets the DBI base to the start
>> of the config space. This causes vendor drivers to incorrectly program
>> iATU regions, as they rely on the DBI address for internal accesses.
>>
>> To fix this, avoid overwriting the DBI base when ECAM is enabled.
>> Instead, introduce a custom ECAM PCI ops implementation that accesses
>> the DBI region directly for bus 0 and uses ECAM for other buses.
>>
>> Fixes: f6fd357f7afb ("PCI: dwc: Prepare the driver for enabling ECAM mechanism using iATU 'CFG Shift Feature'")
>> Reported-by: Ron Economos <re@w6rz.net>
>> Closes: https://lore.kernel.org/all/eac81c57-1164-4d74-a1b4-6f353c577731@w6rz.net/
>> Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>> ---
>>   drivers/pci/controller/dwc/pcie-designware-host.c | 28 +++++++++++++++++++----
>>   1 file changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
>> index 20c9333bcb1c4812e2fd96047a49944574df1e6f..e92513c5bda51bde3a7157033ddbd73afa370d78 100644
>> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
>> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
>> @@ -23,6 +23,7 @@
>>   #include "pcie-designware.h"
>>   
>>   static struct pci_ops dw_pcie_ops;
>> +static struct pci_ops dw_pcie_ecam_ops;
>>   static struct pci_ops dw_child_pcie_ops;
>>   
>>   #define DW_PCIE_MSI_FLAGS_REQUIRED (MSI_FLAG_USE_DEF_DOM_OPS		| \
>> @@ -471,9 +472,6 @@ static int dw_pcie_create_ecam_window(struct dw_pcie_rp *pp, struct resource *re
>>   	if (IS_ERR(pp->cfg))
>>   		return PTR_ERR(pp->cfg);
>>   
>> -	pci->dbi_base = pp->cfg->win;
>> -	pci->dbi_phys_addr = res->start;
>> -
>>   	return 0;
>>   }
>>   
>> @@ -529,7 +527,7 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
>>   		if (ret)
>>   			return ret;
>>   
>> -		pp->bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
>> +		pp->bridge->ops = &dw_pcie_ecam_ops;
>>   		pp->bridge->sysdata = pp->cfg;
>>   		pp->cfg->priv = pp;
>>   	} else {
>> @@ -842,12 +840,34 @@ void __iomem *dw_pcie_own_conf_map_bus(struct pci_bus *bus, unsigned int devfn,
>>   }
>>   EXPORT_SYMBOL_GPL(dw_pcie_own_conf_map_bus);
>>   
>> +static void __iomem *dw_pcie_ecam_conf_map_bus(struct pci_bus *bus, unsigned int devfn, int where)
>> +{
>> +	struct pci_config_window *cfg = bus->sysdata;
>> +	struct dw_pcie_rp *pp = cfg->priv;
>> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>> +	unsigned int busn = bus->number;
>> +
>> +	if (busn > 0)
>> +		return pci_ecam_map_bus(bus, devfn, where);
> 
> Is there a way to avoid the "root bus is bus 00" assumption here?  It
> looks like something like this might work (it inverts the condition
> to take care of the root bus special case first):
> 
>    if (bus == pp->bridge->bus) {
>      if (PCI_SLOT(devfn) > 0)
>        return NULL;
> 
>      return pci->dbi_base + where;
>    }
> 
>    return pci_ecam_map_bus(bus, devfn, where);
> This is working fine Bjorn, shall I send v2 with this change.

- Krishna Chaitanya.
>> +	if (PCI_SLOT(devfn) > 0)
>> +		return NULL;
> 
> This essentially says only one function (00.0) can be on the root bus.
> I assume that someday that will be relaxed and there may be multiple
> Root Ports and maybe RCiEPs on the root bus, so it would be nice if we
> didn't have to have this check.
> 
> What happens without it?  Does the IP return the ~0 data that the PCI
> core would interpret as "there's no device here"?
> 
> Regardless, I love this series because it removes quite a bit of code
> and seems so much cleaner.
> 
>> +	return pci->dbi_base + where;
>> +}
>> +
>>   static struct pci_ops dw_pcie_ops = {
>>   	.map_bus = dw_pcie_own_conf_map_bus,
>>   	.read = pci_generic_config_read,
>>   	.write = pci_generic_config_write,
>>   };
>>   
>> +static struct pci_ops dw_pcie_ecam_ops = {
>> +	.map_bus = dw_pcie_ecam_conf_map_bus,
>> +	.read = pci_generic_config_read,
>> +	.write = pci_generic_config_write,
>> +};
>> +
>>   static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
>>   {
>>   	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>>
>> -- 
>> 2.34.1
>>

Re: [PATCH 1/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[Bjorn Helgaas]

On Tue, Oct 21, 2025 at 05:42:39PM +0530, Krishna Chaitanya Chundru wrote:
> On 10/18/2025 12:40 AM, Bjorn Helgaas wrote:
> > On Fri, Oct 17, 2025 at 05:10:53PM +0530, Krishna Chaitanya Chundru wrote:

> > > +static void __iomem *dw_pcie_ecam_conf_map_bus(struct pci_bus *bus, unsigned int devfn, int where)
> > > +{
> > > +	struct pci_config_window *cfg = bus->sysdata;
> > > +	struct dw_pcie_rp *pp = cfg->priv;
> > > +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > > +	unsigned int busn = bus->number;
> > > +
> > > +	if (busn > 0)
> > > +		return pci_ecam_map_bus(bus, devfn, where);
> > 
> > Is there a way to avoid the "root bus is bus 00" assumption here?  It
> > looks like something like this might work (it inverts the condition
> > to take care of the root bus special case first):
> > 
> >    if (bus == pp->bridge->bus) {
> >      if (PCI_SLOT(devfn) > 0)
> >        return NULL;
> > 
> >      return pci->dbi_base + where;
> >    }
> > 
> >    return pci_ecam_map_bus(bus, devfn, where);
> > This is working fine Bjorn, shall I send v2 with this change.

Yes, please :)

[PATCH 2/2] PCI: dwc: qcom: Revert "PCI: qcom: Prepare for the DWC ECAM enablement"

[Krishna Chaitanya Chundru]

Commit f6fd357f7afb ("PCI: dwc: Prepare the driver for enabling ECAM
mechanism using iATU 'CFG Shift Feature'") enabled ECAM access by
using the config space start as DBI address.

However, this approach breaks vendor drivers that rely on the DBI
address for internal accesses, especially when the vendor config space
is 256MB aligned.

To resolve this, a new design avoids using the DBI as the start of
config space and instead introduces a custom ECAM PCI ops
implementation. As a result, the qcom specific ECAM preparation
logic is no longer necessary and is being reverted.

Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
 drivers/pci/controller/dwc/pcie-qcom.c | 68 ----------------------------------
 1 file changed, 68 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index 805edbbfe7eba496bc99ca82051dee43d240f359..6948824642dcdcb1f59730479b5a3d196ebf66ee 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -55,7 +55,6 @@
 #define PARF_AXI_MSTR_WR_ADDR_HALT_V2		0x1a8
 #define PARF_Q2A_FLUSH				0x1ac
 #define PARF_LTSSM				0x1b0
-#define PARF_SLV_DBI_ELBI			0x1b4
 #define PARF_INT_ALL_STATUS			0x224
 #define PARF_INT_ALL_CLEAR			0x228
 #define PARF_INT_ALL_MASK			0x22c
@@ -65,16 +64,6 @@
 #define PARF_DBI_BASE_ADDR_V2_HI		0x354
 #define PARF_SLV_ADDR_SPACE_SIZE_V2		0x358
 #define PARF_SLV_ADDR_SPACE_SIZE_V2_HI		0x35c
-#define PARF_BLOCK_SLV_AXI_WR_BASE		0x360
-#define PARF_BLOCK_SLV_AXI_WR_BASE_HI		0x364
-#define PARF_BLOCK_SLV_AXI_WR_LIMIT		0x368
-#define PARF_BLOCK_SLV_AXI_WR_LIMIT_HI		0x36c
-#define PARF_BLOCK_SLV_AXI_RD_BASE		0x370
-#define PARF_BLOCK_SLV_AXI_RD_BASE_HI		0x374
-#define PARF_BLOCK_SLV_AXI_RD_LIMIT		0x378
-#define PARF_BLOCK_SLV_AXI_RD_LIMIT_HI		0x37c
-#define PARF_ECAM_BASE				0x380
-#define PARF_ECAM_BASE_HI			0x384
 #define PARF_NO_SNOOP_OVERRIDE			0x3d4
 #define PARF_ATU_BASE_ADDR			0x634
 #define PARF_ATU_BASE_ADDR_HI			0x638
@@ -98,7 +87,6 @@
 
 /* PARF_SYS_CTRL register fields */
 #define MAC_PHY_POWERDOWN_IN_P2_D_MUX_EN	BIT(29)
-#define PCIE_ECAM_BLOCKER_EN			BIT(26)
 #define MST_WAKEUP_EN				BIT(13)
 #define SLV_WAKEUP_EN				BIT(12)
 #define MSTR_ACLK_CGC_DIS			BIT(10)
@@ -146,9 +134,6 @@
 /* PARF_LTSSM register fields */
 #define LTSSM_EN				BIT(8)
 
-/* PARF_SLV_DBI_ELBI */
-#define SLV_DBI_ELBI_ADDR_BASE			GENMASK(11, 0)
-
 /* PARF_INT_ALL_{STATUS/CLEAR/MASK} register fields */
 #define PARF_INT_ALL_LINK_UP			BIT(13)
 #define PARF_INT_MSI_DEV_0_7			GENMASK(30, 23)
@@ -326,47 +311,6 @@ static void qcom_ep_reset_deassert(struct qcom_pcie *pcie)
 	qcom_perst_assert(pcie, false);
 }
 
-static void qcom_pci_config_ecam(struct dw_pcie_rp *pp)
-{
-	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
-	struct qcom_pcie *pcie = to_qcom_pcie(pci);
-	u64 addr, addr_end;
-	u32 val;
-
-	writel_relaxed(lower_32_bits(pci->dbi_phys_addr), pcie->parf + PARF_ECAM_BASE);
-	writel_relaxed(upper_32_bits(pci->dbi_phys_addr), pcie->parf + PARF_ECAM_BASE_HI);
-
-	/*
-	 * The only device on the root bus is a single Root Port. If we try to
-	 * access any devices other than Device/Function 00.0 on Bus 0, the TLP
-	 * will go outside of the controller to the PCI bus. But with CFG Shift
-	 * Feature (ECAM) enabled in iATU, there is no guarantee that the
-	 * response is going to be all F's. Hence, to make sure that the
-	 * requester gets all F's response for accesses other than the Root
-	 * Port, configure iATU to block the transactions starting from
-	 * function 1 of the root bus to the end of the root bus (i.e., from
-	 * dbi_base + 4KB to dbi_base + 1MB).
-	 */
-	addr = pci->dbi_phys_addr + SZ_4K;
-	writel_relaxed(lower_32_bits(addr), pcie->parf + PARF_BLOCK_SLV_AXI_WR_BASE);
-	writel_relaxed(upper_32_bits(addr), pcie->parf + PARF_BLOCK_SLV_AXI_WR_BASE_HI);
-
-	writel_relaxed(lower_32_bits(addr), pcie->parf + PARF_BLOCK_SLV_AXI_RD_BASE);
-	writel_relaxed(upper_32_bits(addr), pcie->parf + PARF_BLOCK_SLV_AXI_RD_BASE_HI);
-
-	addr_end = pci->dbi_phys_addr + SZ_1M - 1;
-
-	writel_relaxed(lower_32_bits(addr_end), pcie->parf + PARF_BLOCK_SLV_AXI_WR_LIMIT);
-	writel_relaxed(upper_32_bits(addr_end), pcie->parf + PARF_BLOCK_SLV_AXI_WR_LIMIT_HI);
-
-	writel_relaxed(lower_32_bits(addr_end), pcie->parf + PARF_BLOCK_SLV_AXI_RD_LIMIT);
-	writel_relaxed(upper_32_bits(addr_end), pcie->parf + PARF_BLOCK_SLV_AXI_RD_LIMIT_HI);
-
-	val = readl_relaxed(pcie->parf + PARF_SYS_CTRL);
-	val |= PCIE_ECAM_BLOCKER_EN;
-	writel_relaxed(val, pcie->parf + PARF_SYS_CTRL);
-}
-
 static int qcom_pcie_start_link(struct dw_pcie *pci)
 {
 	struct qcom_pcie *pcie = to_qcom_pcie(pci);
@@ -1320,7 +1264,6 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
 {
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
 	struct qcom_pcie *pcie = to_qcom_pcie(pci);
-	u16 offset;
 	int ret;
 
 	qcom_ep_reset_assert(pcie);
@@ -1329,17 +1272,6 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
 	if (ret)
 		return ret;
 
-	if (pp->ecam_enabled) {
-		/*
-		 * Override ELBI when ECAM is enabled, as when ECAM is enabled,
-		 * ELBI moves under the 'config' space.
-		 */
-		offset = FIELD_GET(SLV_DBI_ELBI_ADDR_BASE, readl(pcie->parf + PARF_SLV_DBI_ELBI));
-		pci->elbi_base = pci->dbi_base + offset;
-
-		qcom_pci_config_ecam(pp);
-	}
-
 	ret = qcom_pcie_phy_power_on(pcie);
 	if (ret)
 		goto err_deinit;

-- 
2.34.1

Re: [PATCH 0/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[Bjorn Helgaas]

On Fri, Oct 17, 2025 at 05:10:52PM +0530, Krishna Chaitanya Chundru wrote:
> This series addresses issues with ECAM enablement in the DesignWare PCIe
> host controller when used with vendor drivers that rely on the DBI base
> for internal accesses.
> 
> The first patch fixes the ECAM logic by introducing a custom PCI ops
> implementation that avoids overwriting the DBI base, ensuring compatibility
> with vendor drivers that expect a stable DBI address.
> 
> The second patch reverts Qualcomm-specific ECAM preparation logic that
> is no longer needed due to the updated design.
> 
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> Krishna Chaitanya Chundru (2):
>       PCI: dwc: Fix ECAM enablement when used with vendor drivers
>       PCI: dwc: qcom: Revert "PCI: qcom: Prepare for the DWC ECAM enablement"
> 
>  drivers/pci/controller/dwc/pcie-designware-host.c | 28 ++++++++--
>  drivers/pci/controller/dwc/pcie-qcom.c            | 68 -----------------------
>  2 files changed, 24 insertions(+), 72 deletions(-)
> ---
> base-commit: 9b332cece987ee1790b2ed4c989e28162fa47860
> change-id: 20251015-ecam_fix-641d1d5ed71d

I hope we can remove the assumption that the root bus is bus 0, but in
the meantime I added these to pci/for-linus so we can build and test
them.

They're after the pci-v6.18-fixes-2 tag I just asked Linus to pull, so
they won't be in v6.18-rc2, but should make it for -rc3.

Bjorn

Re: [PATCH 0/2] PCI: dwc: Fix ECAM enablement when used with vendor drivers

[Krishna Chaitanya Chundru]

On 10/18/2025 3:28 AM, Bjorn Helgaas wrote:
> On Fri, Oct 17, 2025 at 05:10:52PM +0530, Krishna Chaitanya Chundru wrote:
>> This series addresses issues with ECAM enablement in the DesignWare PCIe
>> host controller when used with vendor drivers that rely on the DBI base
>> for internal accesses.
>>
>> The first patch fixes the ECAM logic by introducing a custom PCI ops
>> implementation that avoids overwriting the DBI base, ensuring compatibility
>> with vendor drivers that expect a stable DBI address.
>>
>> The second patch reverts Qualcomm-specific ECAM preparation logic that
>> is no longer needed due to the updated design.
>>
>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>> ---
>> Krishna Chaitanya Chundru (2):
>>        PCI: dwc: Fix ECAM enablement when used with vendor drivers
>>        PCI: dwc: qcom: Revert "PCI: qcom: Prepare for the DWC ECAM enablement"
>>
>>   drivers/pci/controller/dwc/pcie-designware-host.c | 28 ++++++++--
>>   drivers/pci/controller/dwc/pcie-qcom.c            | 68 -----------------------
>>   2 files changed, 24 insertions(+), 72 deletions(-)
>> ---
>> base-commit: 9b332cece987ee1790b2ed4c989e28162fa47860
>> change-id: 20251015-ecam_fix-641d1d5ed71d
> 
> I hope we can remove the assumption that the root bus is bus 0, but in
Yes we can remove this assumption.
> the meantime I added these to pci/for-linus so we can build and test
> them.
> 
> They're after the pci-v6.18-fixes-2 tag I just asked Linus to pull, so
> they won't be in v6.18-rc2, but should make it for -rc3.
> 
Thanks Bjorn.

- Krishna Chaitanya.
> Bjorn