Re: [PATCH 0/4] PCI: qcom: Align PHY init sequence with HPG

[Bjorn Helgaas <helgaas@kernel.org>]

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?