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

[Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>]

On 9/2/2026 9:30 PM, Thorsten Leemhuis wrote:
> 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.
Sorry, for very late reply here. I totally missed this.
>> 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.
equalization settings are applicable from gen3 onwards and can change from
platform to platform, the EQ presets values
depends on the pcie trace length, May be in your platform there are different
presets programmed by OEM.
Can you remove the eq-presets-8gts from the pcie controller node once and try
if that solving the issue.
>>>>
>>>> 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?
The pci pwrctrl/pwrseq are enabling power to the endpoints before controller
starts link training.
So there will not be any race conditions here.

wifi devices has some limitation in gen1 and some times it takes time to link
up. if there is delay
in the link training pci sw starts enumerating and it detects root only at
that time, as the bridge is not
plug capable pci sw will not allocate sufficient bar memory for the endpoint
that gets detected little
late. Due to that you might see bar allocation issue.

I would suggest try to link up in gen 2 by using max-link-speed = <2> instead
of gen 1 here.

- Krishna Chaitanya.
>>>> 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
>>