[PATCH] PCI: qcom: Power on pwrctrl devices for firmware-managed hosts

[PATCH] PCI: qcom: Power on pwrctrl devices for firmware-managed hosts

[Zhangfei Gao]

commit b921aa3f8dec ("PCI/pwrctrl: Switch to pwrctrl create, power
on/off, destroy APIs") switched PCI pwrctrl users to explicit create and
power control APIs, but only added the calls to the regular DesignWare
host initialization path.

Firmware-managed hosts bypass that path and probe the ECAM host bridge
directly. Endpoints already powered by firmware, such as NVMe devices,
remain discoverable. Endpoints that rely on Linux pwrctrl and pwrseq,
such as WCN7850, remain powered off and cannot be discovered.

Create and power on pwrctrl devices before probing the host bridge, and
release them on errors.

Fixes: b921aa3f8deca ("PCI/pwrctrl: Switch to pwrctrl create, power on/off, destroy APIs")
Signed-off-by: Zhangfei Gao <zhangfei.gao@oss.qualcomm.com>
---
 drivers/pci/controller/dwc/pcie-qcom.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index 0d56051b5de3..7313acd7e480 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -2308,11 +2308,27 @@ static int qcom_pcie_probe(struct platform_device *pdev)
 		bridge->ops = (struct pci_ops *)&pci_qcom_ecam_ops.pci_ops;
 		bridge->msi_domain = true;
 
+		ret = pci_pwrctrl_create_devices(dev);
+		if (ret)
+			goto err_fw_pwrctrl_destroy;
+
+		ret = pci_pwrctrl_power_on_devices(dev);
+		if (ret)
+			goto err_fw_pwrctrl_destroy;
+
 		ret = pci_host_probe(bridge);
 		if (ret)
-			goto err_pm_runtime_put;
+			goto err_fw_pwrctrl_power_off;
 
 		return 0;
+
+err_fw_pwrctrl_power_off:
+		pci_pwrctrl_power_off_devices(dev);
+err_fw_pwrctrl_destroy:
+		if (ret != -EPROBE_DEFER)
+			pci_pwrctrl_destroy_devices(dev);
+
+		goto err_pm_runtime_put;
 	}
 
 	pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
-- 
2.43.0

Re: [PATCH] PCI: qcom: Power on pwrctrl devices for firmware-managed hosts

[Bartosz Golaszewski]

On Thu, Nov 05, 2026 at 06:15:21PM +0800, Zhangfei Gao wrote:
> commit b921aa3f8dec ("PCI/pwrctrl: Switch to pwrctrl create, power
> on/off, destroy APIs") switched PCI pwrctrl users to explicit create and
> power control APIs, but only added the calls to the regular DesignWare
> host initialization path.
> 
> Firmware-managed hosts bypass that path and probe the ECAM host bridge
> directly. Endpoints already powered by firmware, such as NVMe devices,
> remain discoverable. Endpoints that rely on Linux pwrctrl and pwrseq,
> such as WCN7850, remain powered off and cannot be discovered.
> 
> Create and power on pwrctrl devices before probing the host bridge, and
> release them on errors.
> 
> Fixes: b921aa3f8deca ("PCI/pwrctrl: Switch to pwrctrl create, power on/off, destroy APIs")
> Signed-off-by: Zhangfei Gao <zhangfei.gao@oss.qualcomm.com>
> ---
 
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: [PATCH] PCI: qcom: Power on pwrctrl devices for firmware-managed hosts

[Manivannan Sadhasivam]

On Thu, Nov 05, 2026 at 06:15:21PM +0800, Zhangfei Gao wrote:
> commit b921aa3f8dec ("PCI/pwrctrl: Switch to pwrctrl create, power
> on/off, destroy APIs") switched PCI pwrctrl users to explicit create and
> power control APIs, but only added the calls to the regular DesignWare
> host initialization path.
> 
> Firmware-managed hosts bypass that path and probe the ECAM host bridge
> directly. Endpoints already powered by firmware, such as NVMe devices,
> remain discoverable. Endpoints that rely on Linux pwrctrl and pwrseq,
> such as WCN7850, remain powered off and cannot be discovered.
> 

NACK. For FW initialized platforms, FW should power on the Endpoints before
booting Linux.

- Mani

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

Re: [PATCH] PCI: qcom: Power on pwrctrl devices for firmware-managed hosts

[Bartosz Golaszewski]

On Thu, Nov 05, 2026 at 08:07:18PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Nov 05, 2026 at 06:15:21PM +0800, Zhangfei Gao wrote:
> > commit b921aa3f8dec ("PCI/pwrctrl: Switch to pwrctrl create, power
> > on/off, destroy APIs") switched PCI pwrctrl users to explicit create and
> > power control APIs, but only added the calls to the regular DesignWare
> > host initialization path.
> > 
> > Firmware-managed hosts bypass that path and probe the ECAM host bridge
> > directly. Endpoints already powered by firmware, such as NVMe devices,
> > remain discoverable. Endpoints that rely on Linux pwrctrl and pwrseq,
> > such as WCN7850, remain powered off and cannot be discovered.
> > 
> 
> NACK. For FW initialized platforms, FW should power on the Endpoints before
> booting Linux.
>

Ah, sorry for the earlier tag. I should have known this and pointed it
out.

Bart

Re: [PATCH] PCI: qcom: Power on pwrctrl devices for firmware-managed hosts

[Zhangfei Gao]

On Thu, Nov 5, 2026 at 10:37 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Thu, Nov 05, 2026 at 06:15:21PM +0800, Zhangfei Gao wrote:
> > commit b921aa3f8dec ("PCI/pwrctrl: Switch to pwrctrl create, power
> > on/off, destroy APIs") switched PCI pwrctrl users to explicit create and
> > power control APIs, but only added the calls to the regular DesignWare
> > host initialization path.
> >
> > Firmware-managed hosts bypass that path and probe the ECAM host bridge
> > directly. Endpoints already powered by firmware, such as NVMe devices,
> > remain discoverable. Endpoints that rely on Linux pwrctrl and pwrseq,
> > such as WCN7850, remain powered off and cannot be discovered.
> >
>
> NACK. For FW initialized platforms, FW should power on the Endpoints before
> booting Linux.

Thanks Mani for the clarification.

  To confirm, for a firmware-initialized PCIe host, is the platform
  firmware expected to perform the complete board-level Endpoint power
  sequence as well, rather than only initializing the PCIe controller?

  On this platform, WCN7850 requires PMAU0102-E GPIOs 6/7/8 to enable its
  power rails and GPIO10 for WLAN_EN. Should firmware assert these GPIOs
  before Linux probes the ECAM host bridge and keep the Endpoint powered,
  including across suspend/resume as appropriate?

  If so, we will drop this driver change and coordinate the required
  platform firmware update.

Thanks