From: "Grumbach, Emmanuel" <emmanuel.grumbach@intel.com>
To: "helgaas@kernel.org" <helgaas@kernel.org>,
"nika@nikableh.moe" <nika@nikableh.moe>
Cc: "markpearson@lenovo.com" <markpearson@lenovo.com>,
"bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"tglx@kernel.org" <tglx@kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"bhelgaas@google.com" <bhelgaas@google.com>
Subject: Re: [PATCH] x86/PCI: Disable D3cold on Intel BE200 Wi-Fi on Lenovo IdeaPad Pro 5 14IAH10
Date: Tue, 28 Jul 2026 20:14:36 +0000 [thread overview]
Message-ID: <ec2bc0c14bc036a5e81da6e1fab67a20efe53699.camel@intel.com> (raw)
In-Reply-To: <20260728200559.GA1391432@bhelgaas>
On Tue, 2026-07-28 at 15:05 -0500, Bjorn Helgaas wrote:
> [+cc Emmanuel, Mark]
>
> On Wed, Jul 22, 2026 at 04:13:15AM +0200, Nika Krasnova wrote:
> > On the Lenovo IdeaPad Pro 5 14IAH10, the Intel BE200 Wi-Fi
> > (8086:272b,
> > iwlwifi) fails to power back on from D3cold after a suspend-to-idle
> > (s2idle) cycle. On resume the platform reports a successful ACPI
> > D0
> > transition, but the device is left unpowered: config space reads
> > back
> > as 0xffffffff, the firmware reset times out, and the wiphy fails to
> > resume:
> >
> > iwlwifi 0000:01:00.0: power state changed by ACPI to D0
> > iwlwifi 0000:01:00.0: restore config 0x2c: 0xffffffff ->
> > 0x00f48086
> > ieee80211 phy0: PM: failed to resume async: error -110
We try to avoid resetting the firmware during suspend / resume. Out of
curiosity, can you try to reset it?
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
index 25f64299da1d..dfcd3ad60bd8 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
@@ -806,7 +806,7 @@ void iwl_mld_mac80211_stop(struct ieee80211_hw *hw,
bool suspend)
/* if the suspend flow fails the fw is in error. Stop it here,
and it
* will be started upon wakeup
*/
- if (!suspend ||
+ if (!suspend || true ||
(IS_ENABLED(CONFIG_PM_SLEEP) &&
iwl_mld_no_wowlan_suspend(mld)))
iwl_mld_stop_fw(mld);
Another thing.. Does Windows run the same suspend / resume sequence?
It also uses D3cold? I'd expect Lenovo to run thorough validation on
those flows on Windows and report possible bugs to us. I know that the
Windows driver does keep the firmware running.
> >
> > The device stays unusable until a full power cycle; an iwlwifi
> > module
> > reload and a PCI remove/rescan do not recover it, confirming the
> > device
> > is genuinely unpowered rather than in a bad software state.
>
> I guess this means "lspci -xs01:00.0" after resume shows all 0xff?
>
> > Setting the device's d3cold_allowed to 0 keeps it in D3hot across
> > suspend and resumes reliably, so the platform does not correctly
> > restore
> > power to the M.2 Wi-Fi slot on the s2idle resume path. This
> > mirrors the
> > untested-vendor-transition pattern already handled for the Asus
> > B1400
> > NVMe (see asus_disable_nvme_d3cold): the reference OS does not
> > appear to
> > exercise the D3cold->D0 path, so it is left untested.
> >
> > Add a DMI-matched fixup that forbids D3cold for the BE200 on this
> > model.
> > Match on the product rather than the BIOS version so the workaround
> > survives BIOS updates that do not address the issue.
> >
> > Signed-off-by: Nika Krasnova <nika@nikableh.moe>
> > Assisted-by: Claude:claude-opus-4-8
> > ---
> >
> > Not sure arch/x86/pci/fixup.c is the right home versus a PCI quirk
> > in
> > drivers/pci/quirks.c; would be happy to move it.
> >
> > The latest BIOS from Lenovo for this model (QLCN35WW, 2025-12-23)
> > is
> > installed and the failure is still present, so there is currently
> > no
> > firmware-level fix.
> >
> > Tested on the affected machine: with this patch applied and my
> > local
> > d3cold_allowed=0 udev workaround removed, the BE200 resumes from
> > s2idle
> > across repeated suspend/resume cycles with no iwlwifi errors.
> >
> > arch/x86/pci/fixup.c | 33 +++++++++++++++++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> > index b301c6c8df75..3117f313930e 100644
> > --- a/arch/x86/pci/fixup.c
> > +++ b/arch/x86/pci/fixup.c
> > @@ -995,6 +995,39 @@ static void asus_disable_nvme_d3cold(struct
> > pci_dev *pdev)
> > }
> > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x9a09,
> > asus_disable_nvme_d3cold);
> >
> > +/*
> > + * Disable D3cold on the Intel BE200 Wi-Fi on Lenovo IdeaPad Pro 5
> > 14IAH10
> > + *
> > + * On this platform the BE200 (8086:272b) fails to power back on
> > from D3cold
> > + * after an s2idle cycle: all config and CSR reads return
> > 0xffffffff, the
> > + * driver's firmware reset times out ("timeout waiting for FW
> > reset ACK
> > + * (inta_hw=0xffffffff)") and re-probe fails with -EIO. A module
> > reload and a
> > + * PCI remove/rescan cannot revive the device; only a full
> > platform power cycle
> > + * does. This looks like an untested transition by the vendor:
> > the reference
> > + * OS does not appear to exercise the D3cold->D0 path.
> > + *
> > + * Forbidding D3cold keeps the card in D3hot across suspend, which
> > resumes
> > + * reliably at the cost of a small amount of power while
> > suspended. Match on
> > + * the product only (not the BIOS version) so the workaround
> > survives BIOS
> > + * updates that do not address the issue.
> > + */
> > +static const struct dmi_system_id
> > lenovo_be200_broken_d3cold_table[] = {
> > + {
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR,
> > "LENOVO"),
> > + DMI_MATCH(DMI_PRODUCT_VERSION,
> > "IdeaPad Pro 5 14IAH10"),
> > + },
> > + },
> > + {}
> > +};
> > +
> > +static void lenovo_disable_be200_d3cold(struct pci_dev *pdev)
> > +{
> > + if (dmi_check_system(lenovo_be200_broken_d3cold_table) >
> > 0)
> > + pci_d3cold_disable(pdev);
> > +}
> > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x272b,
> > lenovo_disable_be200_d3cold);
> > +
> > #ifdef CONFIG_SUSPEND
> > /*
> > * Root Ports on some AMD SoCs advertise PME_Support for D3hot and
> > D3cold, but
> > --
> > 2.54.0
> >
next prev parent reply other threads:[~2026-07-28 20:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 2:13 Nika Krasnova
2026-07-28 20:05 ` Bjorn Helgaas
2026-07-28 20:14 ` Grumbach, Emmanuel [this message]
2026-07-29 12:52 ` Nika Krasnova
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ec2bc0c14bc036a5e81da6e1fab67a20efe53699.camel@intel.com \
--to=emmanuel.grumbach@intel.com \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=helgaas@kernel.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=markpearson@lenovo.com \
--cc=mingo@redhat.com \
--cc=nika@nikableh.moe \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®