Re: [PATCH] x86/PCI: Disable D3cold on Intel BE200 Wi-Fi on Lenovo IdeaPad Pro 5 14IAH10

[Navon John Lukose <navonjohnlukose@gmail.com>]

I hit this on a Lenovo Yoga Pro 7 14IAH10 (BIOS QGCN35WW), same BE200 and
the same SUBSYS_00F48086 as your lspci dump, with an identical signature.
I think I can explain why your AML trace looks clean and the link still
does not train, and why Emmanuel's firmware-reset hunk made no difference.

Short version: PERST# alone does not restart this card once the rail has
been removed, and the reset that does is already implemented in iwlwifi -
it is just armed too late to ever run.

On my machine:

_PR3 -> PXP._OFF genuinely removes the module's rail; PON() then restores
power, waits PEP0, enables the source clock and releases PERST#. I checked
the pins directly via the ACPI GPIO accessors: after resume the power
enable reads 1 and PERST# is deasserted. So the firmware does everything
your trace says it does, and the card still does not come back. What does
bring it back is a third, WLAN-specific reset line reached only through
_PRR -> <pwrres>._RST.

That _RST is gated:

  Method (_RST) {
      If (RSTY == One) { ...toggle the WLAN reset... }   /* product reset */
      Else             { DCTR |= 0x8000; }               /* just an FLR   */
  }

Disarmed, it degrades to an FLR, i.e. asking a device with no power to
reset itself over a bus it is not on. That is the fallback that has been
running all along.

RSTY is set over the vendor _DSM by iwl_trans_pcie_set_product_reset(),
which iwlwifi already calls with EN_PROD_RESET|EN_WIFI_FLR|EN_BT_OFF_ON
for discrete parts. But it is only called from iwl_trans_pcie_removal_wk(),
once the device is already being torn down, and the _DSM dispatch is gated
on the firmware reading the device's PCI ID back out of config space:

  Method (WIST) { Switch (ToInteger (VDID)) { Case (0x272B8086) {...} } }

With the rail off VDID reads 0xffffffff, WIST() returns 0, and the arming
fails:

  scheduling reset (mode=6)
  ACPI _DSM not available (-19), cannot do product reset

So it can never be armed at the moment it is needed. I confirmed this
directly: with the device dead, evaluating the set-mode _DSM returns
success but RSTY stays 0.

Arming at probe instead, while the device still answers, makes the whole
existing path work. I will post two small iwlwifi patches for this as a
separate series and link it here. With them my card dies in D3cold on
every s2idle exactly as before, and comes back on its own in about 5s,
repeatedly.

Control: with the reset skipped but everything else identical, the device
stays absent (2/2), and recovers immediately once a real reset is issued.
So the reset is doing the work, not the remove/rescan.

Emmanuel - to your question, this is not a firmware reset during
suspend/resume. It only fires when the device is provably not answering
config cycles, which today is the case where the driver instead spends
~2s on handshakes with absent hardware and produces a bogus
ADVANCED_SYSASSERT dump.

Nika - I could not decode LTSM 0x32B either. Worth noting your sibling
port 00:06.2 reads 0x33/0x40 with its link up, so 0x01 does look like a
state the port never occupies while trained - but that is just my
observation, not a decode.

Caveats, so nobody wastes time: tested on one machine and one BIOS, on the
discrete (!integrated) path only. I have no integrated/CNVi hardware. The
recovery costs ~4.3s of Sleep() inside the platform's _RST, which is
firmware and not something we can shorten. And this is recovery rather
than avoidance - it keeps D3cold and pays a per-resume cost, where the
quirk in this thread avoids the problem entirely. I have not measured what
the rail actually saves, so I am not claiming it is the better trade, only
that the hardware can recover.

Thanks,
Navon