Re: [PATCH 1/4] PCI: qcom: Move PHY init and add PHY reset call to align with HPG

From: Kathiravan Thirumoorthy

Date: Mon Sep 21 2026 - 05:17:16 EST



On 9/16/2026 11:34 AM, Qiang Yu wrote:
HPG requires the controller/PHY GDSCs powered up and all controller/PHY
clocks enabled first, then the controller's reset and the PHY's reset
toggled together as a group, PARF_DEVICE_TYPE set right after, and the
rest of the PARF/DBI config left until the PHY is ready.

Make use of phy_init() and phy_reset(), and change the call flow to:

qcom_pcie_host_init():
phy_init() (PHY GDSCs/regulators/clocks up)
qcom_pcie_ops::init:
enable controller clocks
assert controller reset
phy_reset() (toggle the PHY's own reset)
deassert controller reset
write PARF_DEVICE_TYPE
phy_power_on()
qcom_pcie_ops::post_init (rest of the PHY/PARF/DBI setup)

phy_init() moves into qcom_pcie_host_init() and phy_exit() into
qcom_pcie_host_deinit(), right before and right after they call
qcom_pcie_ops::init/qcom_pcie_ops::deinit.

Apply this to qcom_pcie_init_2_7_0()/_2_9_0()/_2_3_2()/_2_3_3().
qcom_pcie_init_2_3_3() was enabling clocks after the reset deassert; move
that ahead of the reset assert to match the same ordering. Also add or
move the PARF_DEVICE_TYPE write to right after the reset group in each of
those four functions.

For most platforms phy_init()/phy_exit()/phy_reset() are no-ops against
their phy_ops, so moving the calls around has no effect yet; the PHY's
clocks/reset actually start being driven this way once a later PHY driver
change implements phy_ops::init/phy_ops::exit/phy_ops::reset.
phy-qcom-pcie2.c does implement phy_init()/phy_exit(), but moving the call
site into qcom_pcie_host_init()/qcom_pcie_host_deinit() keeps them at the
same point relative to that platform's own clock/reset programming, so its
init sequence doesn't change either.

Signed-off-by: Qiang Yu<qiang.yu@xxxxxxxxxxxxxxxx>
---
drivers/pci/controller/dwc/pcie-qcom.c | 165 +++++++++++++++++++++++++--------
1 file changed, 126 insertions(+), 39 deletions(-)

Verified the PCIe enumeration in IPQ9574 and IPQ5424 and it works fine. So,

Tested-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@xxxxxxxxxxxxxxxx> #IPQ9574-RDP433, IPQ5424-RDP466