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

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

[franzelverbier]

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

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

[Thorsten Leemhuis]

On 7/31/26 14:22, franzelverbier wrote:
> 
> 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
> 
> 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.

Thx for the report. Nobody replied, so either the right people didn't
see this or they had no idea what's wrong. So I guess you have to
recheck if 7.2 and -next are still affected and then bisect.

FWIW, I see quite a few regression reports and none sounded related.
Only the following one a little bit (there is no fix for it yet afaik)
-- but I fear I might send you in the wrong direction, so you might want
to ignore that I mentioned it:
https://bugzilla.kernel.org/show_bug.cgi?id=221801#c14

Ciao, Thorsten


> 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
> 

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

[Manivannan Sadhasivam]

+ Krishna

- Mani

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

-- 
மணிவண்ணன் சதாசிவம்

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

[Thorsten Leemhuis]

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?

If not, I guess Franzelverbier might need to bisect this.

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
> 

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
>>
> 
> 

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

[Krishna Chaitanya Chundru]

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
>>