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

[Thorsten Leemhuis]

On 8/24/26 14:46, Thorsten Leemhuis wrote:
> On 8/18/26 13:13, Manivannan Sadhasivam wrote:
>> + Krishna
> 
> Hmm, nothing happened here. Or did it and I just missed it?
> 
> Krishna, it seemed Mani thought you might haven an idea what's wrong. Do
> you do by chance?

That did help afaics. Happens.
> If not, I guess Franzelverbier might need to bisect this.

Franzelverbier: looks like we are stuck here. So I guess this is
unlikely to go anywhere unless you git bisect this (after verifying if
the problem sill happens with latest mainline/-next).

Ciao, Thorsten
>> On Fri, Jul 31, 2026 at 02:22:25PM +0200, franzelverbier wrote:
>>> 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
>>
> 
>