Re: [PATCH 1/1] PCI: Disable D3cold for Killer BE200-family WiFi on MSI Claw A1M

["Grumbach, Emmanuel" <emmanuel.grumbach@intel.com>]

On Mon, 2026-10-26 at 20:09 +0100, Denis Benato wrote:
> 26 ott 2026 19:48:16 Bjorn Helgaas <helgaas@kernel.org>:
> 
> > On Sun, Oct 25, 2026 at 11:18:13PM +0000, Denis Benato wrote:
> > > During s2idle the platform removes power from the WiFi slot
> > > (D3cold).
> > > The Killer BE1750 (Intel BE200, 8086:272b) installed in the MSI
> > > Claw A1M
> > > fails to resume from that state: the PCIe link does not retrain
> > > ("pcieport 0000:00:1c.0: Data Link Layer Link Active not set in
> > > 100 msec") and every device register reads back as 0xffffffff, so
> > > the
> > > card disappears from the bus and the machine must be power-
> > > cycled.
> > > 
> > > Keeping the device in D3hot with the link in L1.2 during system
> > > sleep
> > > makes suspend and resume work reliably: the package still reaches
> > > >99%
> > > S0ix residency and the card survives every cycle (verified over
> > > multiple
> > > suspend/resume tests with an RTC-timed wake).
> > > 
> > > Disable D3cold for the BE200-family device on this board. This
> > > mirrors
> > > the udev-level workaround distributions already ship for the
> > > AX200/AX210
> > > (8086:2725), which suffers from the same class of problem, and
> > > moves it
> > > into the kernel where it belongs.
> > 
> > If 2725 has the same problem, should we make the quirk apply to it
> > also?
> > 
> 
> 

I'll take the risk to hijack a bit this thread to say that we have a
register that was added in BE200 to tell the wifi driver what happened
to the device during the suspend. It is called the scratch register. We
write an initial value into that register and upon _iwl_pci_resume we
read it. If we see that the original value is no longer there at means
that parts of the device have been reset. This allows us to know if we
can still expect to have a firmware to talk to upon resume. See:

                /*   
                 * Scratch value was altered, this means the device was powered
                 * off, we need to reset it completely.
                 * Note: MAC (bits 0:7) will be cleared upon suspend even with
                 * wowlan, but not bits [15:8]. So if we have bits set in lower
                 * word, assume the device is alive.
                 * Alternatively, if the scratch value is 0xFFFFFFFF, then we
                 * no longer have access to the device and consider it powered
                 * off.
                 * For older devices, just try silently to grab the NIC.
                 */
                if (trans->mac_cfg->device_family >= IWL_DEVICE_FAMILY_BZ) {
                        u32 scratch = iwl_trans_pcie_read32(trans, CSR_FUNC_SCRATCH);

                        if (!(scratch & CSR_FUNC_SCRATCH_POWER_OFF_MASK) ||
                            scratch == ~0U) {
                                IWL_DEBUG_WOWLAN(trans,
                                                 "Scratch 0x%08x indicates device was powered off\n",
                                                 scratch);
                                device_was_powered_off = true;
                        }    
                } 

Not sure this information helps though..

> Hi Bjorn,
> 
> Probably yes, but I don't own that hardware, only saw gaming distros
> are shipping an udev rule to do just that.
> 
> > I suppose this is a firmware problem with whatever is supposed to
> > turn
> > the power back on?  Are there any firmware updates available?
> > 
> 
> Not that I know of. I have updated my bios (only update available)
> but the issue is still there.
> 
> > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220223
> > > Signed-off-by: Denis Benato <denis.benato@linux.dev>
> > > ---
> > > drivers/pci/quirks.c | 21 +++++++++++++++++++++
> > > 1 file changed, 21 insertions(+)
> > > 
> > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > > index 7572b358b50f..60156e6c3e49 100644
> > > --- a/drivers/pci/quirks.c
> > > +++ b/drivers/pci/quirks.c
> > > @@ -6593,3 +6593,24 @@ static void
> > > pci_mask_replay_timer_timeout(struct pci_dev *pdev)
> > > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750,
> > > pci_mask_replay_timer_timeout);
> > > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755,
> > > pci_mask_replay_timer_timeout);
> > > #endif
> > > +
> > > +/*
> > > + * MSI Claw A1M: during s2idle the platform removes power from
> > > the WiFi slot
> > > + * (D3cold). The Killer BE1750 (Intel BE200, 8086:272b) fails to
> > > resume from
> > > + * that state: the PCIe link does not retrain ("Data Link Layer
> > > Link Active
> > > + * not set in 100 msec") and every device register reads back as
> > > 0xffffffff,
> > > + * so the card disappears from the bus and the machine must be
> > > power-cycled.
> > > + *
> > > + * Keeping the device in D3hot with the link in L1.2 during
> > > system sleep makes
> > > + * suspend and resume work reliably: the package still reaches
> > > >99% S0ix
> > > + * residency and the card survives.
> > 
> > From just this patch, I don't think we can assert the L1.2 link
> > state,
> > can we?  AFAICS, this patch just prevents the use of D3cold.
> 
> From this patch no, but that is the description of what happens on my
> msi claw when I enter sleep with this patch, checked via s0ixselftest
> tool.
> 
> This is surely better than the previous work around of detaching the
> driver and re-attaching it leaving the device in d0.
> 
> > 
> > > + */
> > > +static void quirk_msi_claw_be200_d3cold(struct pci_dev *pdev)
> > > +{
> > > +   if (!dmi_match(DMI_BOARD_NAME, "MS-1T41"))
> > > +       return;
> > > +
> > > +   pci_d3cold_disable(pdev);
> > > +   pci_info(pdev, "disabling D3cold: slot power removal during
> > > s2idle prevents resume on this system");
> > > +}
> > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x272b,
> > > quirk_msi_claw_be200_d3cold);
> > > --
> > > 2.55.0
> > >