Re: [PATCH 4/4] phy: qcom-qmp-pcie: Split phy_ops into init/exit/reset/power_on

[Michael Burch <me@michaelburch.net>]

On Tue, Sep 15, 2026 at 11:04:24PM -0700, Qiang Yu wrote:
> -	skip_reset = qmp->skip_init && !qphy_checkbits(pcs, cfg->regs[QPHY_PCS_STATUS],
> +	qmp->skip_reset = qmp->skip_init && !qphy_checkbits(pcs, cfg->regs[QPHY_PCS_STATUS],
>  							    cfg->phy_status);

[...]

> +static int qmp_pcie_reset(struct phy *phy)
> +{
> +	struct qmp_pcie *qmp = phy_get_drvdata(phy);
> +	const struct qmp_phy_cfg *cfg = qmp->cfg;
> +	int ret;
> +
> +	if (qmp->skip_reset)
> +		return 0;

This keeps the skip from 910b828b22b7 ("phy: qcom: qmp-pcie: Skip PHY
reset if already up"). That skip stops v7.3-rc7 from booting on the
Dell XPS 13 9345 (X1E80100), and I've sent a revert [1].

UEFI boots from the NVMe behind pcie6a, so the PHY is already up when
Linux probes it and the no-csr reset is skipped. pcie-qcom still
asserts PERST# and resets the controller, so the link has to train
again, and it doesn't:

  qcom-pcie 1bf8000.pcie: Device found, but not active

910b828b22b7 only changes whether that reset runs, and reverting it
fixes boot.

With patch 1/4, X1E (qcom_pcie_init_2_7_0()) would run:

  qcom_pcie_perst_assert()
  phy_init()                        skip_reset = true
  reset_control_assert(res->rst)
  phy_reset()                       returns 0, PHY not reset
  reset_control_deassert(res->rst)
  phy_power_on()                    skip_init: no tables, no SERDES start

That is the same sequence as 910b828b22b7, so this series would bring
the failure back. It also doesn't follow the HPG order in the cover
letter: the controller reset is toggled, the PHY reset isn't.

Could qmp_pcie_reset() always toggle the reset that skip_init selects,
with qmp->skip_reset dropped? If link retention comes back, the
controller knows whether it is keeping the link, so it can skip both
its own reset and phy_reset() then.

[1] https://lore.kernel.org/r/20261013-qmp-pcie-skip-reset-revert-v1@michaelburch.net

Michael