HPG requires the controller/PHY GDSCs to be powered up and all
clocks enabled, then the controller's reset and the PHY's reset
toggled together as one group, with PARF_DEVICE_TYPE set right
after. This series adds the callbacks needed on both sides to
realize that sequence: a phy_reset() call the controller makes as
part of its own reset, and matching phy_ops::init/phy_ops::reset on
the PHY side.

Patches 1-2 move phy_init()/phy_exit() into the RC and EP
controllers' own init/deinit paths, add a phy_reset() call grouped
with each controller's own reset, and move the PARF_DEVICE_TYPE
write to right after that reset group.

Patches 3-4 update the two PHY drivers these controllers can use
(phy-qcom-qmp-pcie[-multiphy].c) to implement phy_ops::init/reset,
matching phy_ops::power_on to what's left once
phy_ops::init/phy_ops::reset are pulled out.

phy_init()/phy_reset() are no-ops against a phy_ops without
phy_ops::init/phy_ops::reset, so patches 1-2 don't change behavior
on any platform by themselves; patches 3-4 are what actually change
the sequence for the platforms using those two PHY drivers. Other
PHY drivers this series doesn't touch (phy-qcom-qmp-pcie-msm8996.c,
phy-qcom-uniphy-pcie-28lp.c, phy-qcom-pcie2.c) are either unaffected
(no phy_ops::init/phy_ops::reset) or only see their
phy_init()/phy_exit() call site moved without a sequence change.

Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
Qiang Yu (4):
      PCI: qcom: Move PHY init and add PHY reset call to align with HPG
      PCI: qcom-ep: Move PHY init and drive PHY reset to align with HPG
      phy: qcom-qmp-pcie-multiphy: Split phy_ops into init/exit/reset/power_on
      phy: qcom-qmp-pcie: Split phy_ops into init/exit/reset/power_on

 drivers/pci/controller/dwc/pcie-qcom-ep.c         |  26 +--
 drivers/pci/controller/dwc/pcie-qcom.c            | 165 ++++++++++++++-----
 drivers/phy/qualcomm/phy-qcom-qmp-pcie-multiphy.c |  94 ++++-------
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c          | 184 ++++++++++------------
 4 files changed, 257 insertions(+), 212 deletions(-)
---
base-commit: e6e35979777d646fe3c7c94dca7dd32fb25d45f4
change-id: 20260915-align_pcie_init_sequence_0916-571190abea56

Best regards,
--  
Qiang Yu <qiang.yu@oss.qualcomm.com>

On Tue, Sep 15, 2026 at 11:04:20PM -0700, Qiang Yu wrote:
> HPG requires the controller/PHY GDSCs to be powered up and all
> clocks enabled, then the controller's reset and the PHY's reset
> toggled together as one group, with PARF_DEVICE_TYPE set right
> after. This series adds the callbacks needed on both sides to
> realize that sequence: a phy_reset() call the controller makes as
> part of its own reset, and matching phy_ops::init/phy_ops::reset on
> the PHY side.

This observation is not related to this series; it's a question about
PCI host controller initialization ordering in general because it
seems like this is a perennial issue.  Is there anything we can do to
converge on some sort of generic standard or typical ordering across
drivers?

For example, while looking at a patch that changed ordering in a
different driver (not qcom), I asked Gemini for some guidance and it
came up with the following ordering recommendations, which seem
pretty generic:

  - assert downstream PERST# so physical lanes remain quiet while
    setting up the host

  - assert local resets (core & PHY)

  - enable and stabilize power (IP core, I/O rails, PHYs)

  - enable and stabilize clocks, including refclk and T_PERST_CLK

  - initialize PHYs

    - deassert PHY reset or allow register access to PHY

    - wait for PHY PLL lock to refclk

    - program PHY parameters & calibration

    - verify PHY ready

  - deassert local core reset

  - configure RC (device type, MPS, max link speed, width, etc)

  - deassert downstream PERST#

  - enable LTSSM

If this could be made generic enough, maybe something like it could be
included in Documentation/PCI/controller/pci-controller-drivers.rst?

On Wed, Sep 16, 2026 at 10:55:04AM -0500, Bjorn Helgaas wrote:
> On Tue, Sep 15, 2026 at 11:04:20PM -0700, Qiang Yu wrote:
> > HPG requires the controller/PHY GDSCs to be powered up and all
> > clocks enabled, then the controller's reset and the PHY's reset
> > toggled together as one group, with PARF_DEVICE_TYPE set right
> > after. This series adds the callbacks needed on both sides to
> > realize that sequence: a phy_reset() call the controller makes as
> > part of its own reset, and matching phy_ops::init/phy_ops::reset on
> > the PHY side.
> 
> This observation is not related to this series; it's a question about
> PCI host controller initialization ordering in general because it
> seems like this is a perennial issue.  Is there anything we can do to
> converge on some sort of generic standard or typical ordering across
> drivers?
> 
> For example, while looking at a patch that changed ordering in a
> different driver (not qcom), I asked Gemini for some guidance and it
> came up with the following ordering recommendations, which seem
> pretty generic:
> 
>   - assert downstream PERST# so physical lanes remain quiet while
>     setting up the host
> 
>   - assert local resets (core & PHY)
> 
>   - enable and stabilize power (IP core, I/O rails, PHYs)
> 
>   - enable and stabilize clocks, including refclk and T_PERST_CLK
> 
>   - initialize PHYs
> 
>     - deassert PHY reset or allow register access to PHY
> 
>     - wait for PHY PLL lock to refclk
> 
>     - program PHY parameters & calibration
> 
>     - verify PHY ready
> 
>   - deassert local core reset
> 
>   - configure RC (device type, MPS, max link speed, width, etc)
> 
>   - deassert downstream PERST#
> 
>   - enable LTSSM
> 
> If this could be made generic enough, maybe something like it could be
> included in Documentation/PCI/controller/pci-controller-drivers.rst?

Some of these sequences could be generalised, but the problem is, pretty much
each controller sequence follow a hardware reference manual and those
recommend a specific sequence. So if we diverge from that recommended sequence,
then getting help from the hardware team for any issue would be tricky. Atleast,
this is the case with Qcom controllers.

- Mani

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