[PATCH wireless v2 0/3] wifi: iwlwifi: recover a device that lost power in D3cold

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

On a Lenovo Yoga Pro 7 14IAH10 (Arrow Lake-H) the Intel BE200 does not
survive D3cold: _PR3 genuinely removes the M.2 module's rail and the card
does not restart when the rail and PERST# come back. After _ON both the
power-enable and PERST# GPIO pad registers read correct and the link still
never trains; config space reads 0xffffffff until reboot.

iwlwifi already has everything needed to recover it: the platform-level
device reset walks _PRR and evaluates _RST on what it returns, and the
driver already speaks the vendor _DSM that selects the product reset mode.
The problem is ordering. The mode is only ever selected from the removal
path, by which point the device no longer answers, and AML gates that _DSM
on reading the device's PCI ID back out of config space - so the selection
can never succeed at the one moment it matters.

  Patch 1  stop concluding "no CSME" (or "CSME present") from a register
           read that never reached the device. An independent bug, with a
           behaviour change of its own; see the patch.
  Patch 2  deselect the mode at probe. The driver selects it and never
           clears it on the product-reset path, and _RST does not clear it
           either.
  Patch 3  arm the mode in .suspend, disarm it in .resume, and if the
           disarm fails *and* the device reads all ones, ask for a product
           reset.

+57/-10 over three files. Patch 3's new arming is confined to discrete
parts, but its demotion of a failure log to debug level applies to
integrated parts too; patch 1 changes me_present handling on all BZ and
later hardware, and patch 2 adds a DSM evaluation to every probe.

Since v1:
https://lore.kernel.org/all/20260829095437.44716-1-navonjohnlukose@gmail.com/

- v1 selected the mode at probe and left it selected forever, which is a
  permanent change to platform state for a reset that may never happen.
  v2 arms in .suspend and disarms in .resume, and patch 2 clears what an
  earlier driver instance left behind.
- v2 requires two independent signals before it removes and resets
  anything: the disarm failing and CSR_HW_REV reading ~0. A failed DSM
  alone is not evidence of a dead device.
- Patch 1 is new. It is the me_present bug I said I would send separately;
  it is here because it is the reset ladder patch 3 reasons about, and it
  is wider than I described then. It applies alone.
- Corrections to v1 and to my analysis mail: this is Arrow Lake-H, not
  "several Meteor Lake laptops", and it is one machine tested by me. I
  also said twice that the test would key on config space
  (pci_device_is_present(), "not answering config cycles"); it does not.
  v2 makes no config access of its own, because a device in D3hot answers
  config cycles while its BARs are dark. Config space is still in the loop
  one layer down, in AML's own VDID read.
- iwl_trans_pcie_reset() is left alone. A draft suppressed the CSME
  downgrade while the mode was armed; that premise only holds for a device
  already off the bus. The consequence is under the --- of patch 3.

Notes for review:

- .suspend does not reset anything and does not touch the NIC or the
  firmware: it reads the PCI ID through AML and writes an integer into the
  ACPI namespace. The reset only happens from .resume, through the existing
  iwl_trans_pcie_reset() path, and only from the work item it queues.
- This is recovery, not avoidance. The alternative on the list is the DMI
  quirk patch 3 Links to, which disables D3cold for the affected machine
  and costs nothing per resume, where this keeps D3cold and pays ~7 s on
  the resumes that fail. I am not claiming this is the better trade; it is
  the one that does not need a DMI entry per machine, and it shows the
  hardware can recover. If you would rather take the quirk, patches 1 and
  2 still stand on their own.
- Arguably the better fix is in the PCI core: for a device with _PRR that
  comes back from D3cold not answering, evaluate _RST in place of the
  speculative retrain pcie_wait_for_link_delay() attempts. That would
  leave the device alive before any driver .resume runs, taking the ~7 s
  to ~4.5 s. But arming is a vendor DSM that has to be issued while the
  device is still alive, so the driver is involved either way. I would
  like to do the core half as a follow-up.
- This is not the missing D3cold->D0 recovery delay from "PCI: Apply
  mandatory recovery delay on return from D3cold":
  https://lore.kernel.org/all/20260708152650.536604-2-mario.limonciello@amd.com/
  That delay is real and this device is subject to it, but I left the card
  in the failed state and polled it for 60 s across ten PCI rescans:
  0xffffffff throughout, link never trained.

Testing: one machine, one BIOS, discrete only. Five s2idle cycles, four
with wifi connected at suspend and one with the radio down, and the device
recovered on all five; with the reset skipped and nothing else changed it
stayed absent until reboot. Methodology and the untested surface are under
the --- of patch 3.

Patches 1 and 2 carry Fixes: tags and Cc: stable. Patch 3 carries neither:
the device dying in D3cold is not a regression from any commit, the driver
simply never handled it, and I would rather not invent a SHA. It is still
a fix in the sense that matters, since the machine loses its WiFi until
reboot. Whether that belongs in wireless or wireless-next is your call.

Signed-off-by: Navon John Lukose <navonjohnlukose@gmail.com>

Navon John Lukose (3):
  wifi: iwlwifi: pcie: don't infer CSME presence from a failed read
  wifi: iwlwifi: pcie: deselect the product reset mode at probe
  wifi: iwlwifi: pcie: recover a device that lost power in D3cold

 drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 24 ++++++++++++
 .../intel/iwlwifi/pcie/gen1_2/internal.h      |  4 ++
 .../intel/iwlwifi/pcie/gen1_2/trans.c         | 39 ++++++++++++++-----
 3 files changed, 57 insertions(+), 10 deletions(-)

-- 
2.55.0