[REGRESSION] PCIe/qcom: on-board WCN7850 link stuck in Polling on X1E80100 (Surface Pro 11)

[franzelverbier <info@humanlearning.ch>]

Hi,

On a Microsoft Surface Pro 11 (Snapdragon X Elite, X1E80100, board
x1e80100-microsoft-denali-oled), the on-board WCN7850 Wi-Fi PCIe link
no longer trains on linux-next. It works on 6.17.

  Good: v6.17
  Bad:  next-20260721, next-20260723

#regzbot introduced: v6.17..next-20260721
#regzbot title: PCIe/qcom: WCN7850 link stuck in Polling on X1E80100

The device sits behind PCIe controller 1c08000.pci (pcie4,
qcom,pcie-x1e80100, gen3x2) and has no PERST# GPIO -- it is
power-sequenced via wcn7850-pmu / pwrseq.

Symptom
=======

  qcom-pcie 1c08000.pci: Device found, but not active
  qcom-pcie 1c08000.pci: PCI host bridge to bus 0004:00

dw_pcie_wait_for_link() finds the LTSSM in POLL_ACTIVE/POLL_COMPLIANCE
and returns -EIO. The endpoint 0004:01:00.0 is never enumerated, ath12k
never probes, and there is no wlan interface. On 6.17 the same
controller trains at ~0.6 s and ath12k probes normally.

Ruled out: the chip is powered, and power control is bound
==========================================================

- Bluetooth on the same WCN7850 (UART) comes up fine, so the PMU and
  regulators are on.

- pwrseq_qcom_wcn is loaded, and pci-pwrctrl-pwrseq is bound to the
  platform device 1c08000.pci:pcie@0:wifi@0 (compatible pci17cb,1107 is
  present in pwrseq_pwrctrl_of_match[]). The vddaon-supply
  validate_device() check passes.

Ruled out: not a device-tree regression
=======================================

The wifi@0, &pcie4 and &pcie4_phy nodes are equivalent between the 6.17
and 7.2 device trees -- same supplies, same compatibles. The only
difference in wifi@0 is "disable-rfkill;" (6.17), which is
post-enumeration ath12k behaviour and cannot affect link training.

What changed
============

qcom_pcie_host_init() was reworked around the pci-pwrctrl framework,
and qcom_pcie_start_link() now calls qcom_pcie_common_set_equalization()
-- absent in 6.17 -- before enabling the LTSSM.

Finding 1: Gen3 equalization prevents link training
===================================================

Forcing the port to Gen1 makes the link train and ath12k probe:

  &pcie4 { max-link-speed = <1>; status = "okay"; };

  qcom-pcie 1c08000.pci: PCIe Gen.1 x2 link up
  ath12k_wifi7_pci 0004:01:00.0: Wi-Fi 7 Hardware name: wcn7850 hw2.0

qcom_pcie_common_set_equalization() only programs GEN3_EQ_* for speeds
>= 8GT, so max-link-speed=<1> skips it entirely, reproducing the 6.17
behaviour of no EQ programming.

Note this is not a wrong preset value. The presets come from DT via
of_pci_get_equalization_presets() and are applied by the DWC host core.
In hamoa.dtsi:

  pcie4  (pci@1c08000, gen3x2, on-board WCN7850)
    eq-presets-8gts = /bits/ 16 <0x5555 0x5555>;

  pcie6a (pci@1bf8000, NVMe, gen4x4)
    eq-presets-8gts = /bits/ 16 <0x5555 0x5555 0x5555 0x5555>;

Both use the same per-lane preset 0x5555. The NVMe port trains at Gen4
fine; only the WCN7850 port fails. So the WCN7850 endpoint specifically
cannot complete Gen3 equalization with these presets on this
controller, while an NVMe SSD on the same SoC can.

The board DTS (x1-microsoft-denali.dtsi, also in mainline) leaves
&pcie4 as status = "okay" with no per-port override, so it inherits the
SoC preset.

Finding 2: an LTSSM re-kick does not recover the link
=====================================================

Even at Gen1, the link does not train on the first attempt at boot
(~4 s); in one instance it only came up much later via a pciehp slot
event. An experimental retry in qcom_pcie_start_link() toggling
PARF_LTSSM.LTSSM_EN (clear/set) for up to 30 s never recovered the
link.

That suggests the endpoint needs a full power/reset re-sequence
(pwrseq) to leave the failed state, not just an LTSSM restart -- i.e.
the pwrseq power-on may be racing link bring-up at boot for PERST-less
on-board devices.

When the link does come up late (fragmented CMA, tight PCI windows),
secondary symptoms appear that are absent on a clean boot-time
bring-up:

  ath12k ... qmi dma allocation failed
  BAR 0 ... failed to assign
  rfkill ... Hard blocked: yes

Questions
=========

1. Are the qcom_pcie_common_set_equalization() Gen3 EQ presets expected
   to be safe for a gen3x2 PHY driving an on-board WCN7850? They
   prevent link training here, and skipping them (Gen1) works.

2. Is pci-pwrctrl/pwrseq power-on racing link training at boot for
   on-board devices with no PERST# GPIO, such that the endpoint is not
   ready on the first LTSSM attempt and cannot be recovered by an LTSSM
   re-kick?

I have not bisected to a single commit yet -- the range above is v6.17
to next-20260721. I am happy to bisect, test patches, or dump any
register on this hardware; rebuilding is a short loop here.

Environment
===========

linux-next next-20260723, CONFIG_PCIE_QCOM=y, CONFIG_CMA_SIZE_MBYTES=128,
ath12k, board x1e80100-microsoft-denali-oled, Arch Linux ARM (aarch64).

Thanks,
franzelverbier