Re: [PATCH v2] pci: quirks: Disable native PCIe hotplug on MSI Claw A8 root bridge

On Fri, Aug 7, 2026 at 1:53 AM Lukas Wunner <[email protected]> wrote:
>
> On Thu, Aug 06, 2026 at 09:48:08PM +0000, Derek J. Clark wrote:
> > The MSI Claw A8 (MS-1T8K) hard-locks on resume from s2idle whenever an
> > SD/MMC card is present in the onboard Realtek RTS525A card reader
> > (10ec:525a), which sits behind root port 0000:00:02.2.
>
> The RTS525A is known to falsely claim that it supports ASPM L0s,
> even though it only supports L1.  There is a patch pending to
> work around this hardware erratum, I'm wondering whether it
> makes the issue go away on the MSI Claw A8?
>
> https://lore.kernel.org/r/[email protected]/
>
Hi Lukas,

Sending again as i inadvertently hit reply instead of reply all.

The freeze still occurs with that patch applied, yes.

> > The reader's PCIe endpoint is fixed/soldered and not user-hotpluggable.
> > Firmware advertises this root port as PCIe hotplug-capable
>
> That looks like an oversight on the part of MSI.  Is there a BIOS update
> available which clears the Hot-Plug Capable bit in the Slot Capabilities
> Register?  (I'm *assuming* that bit is set -- I haven't seen any dmesg
> or lspci -vvv output in your e-mails, perhaps you could open a bug
> at bugzilla.kernel.org and upload it there.)
>

I'm on the latest firmware they have as of abuut a month ago. They
don't participate in LVFS AFAIK but I made sure to update before
switching to Linux.

I posted them here for the entire device tree for the SD card reader:
https://github.com/ValveSoftware/SteamOS/issues/2473#issuecomment-5222972815

> > When native hotplug is OS-owned,
> > resuming from s2idle races the port's hotplug/PME resume handling
> > against the RTS525A's own resume sequence when a card is present,
> > hard-locking the system.
>
> This sounds like a driver bug in rtsx_pci which needs to be root-caused
> and fixed, rather than worked around.
>
> pciehp (the OS-native PCIe hotplug driver) normally doesn't de-enumerate
> and re-enumerate devices on resume from system sleep.  It uses a heuristic
> to determine whether the device in the slot was replaced during system
> sleep and synthesizes a hotplug event if it believes there's now a different
> device in the slot.  Otherwise it just leaves the device in the slot alone.
> The replacement detection is in pciehp_device_replaced(),
> drivers/pci/hotplug/pciehp_hpc.c line 567.  You could try hacking
> that function to return false and see if it helps.
>

That worked! That strikes me as odd since the card is never replaced.

> The heuristic looks at the Vendor ID and Device ID in config space.
> I do recall that a different type of card readers, RTS5261, trigger
> a hotplug event when a regular UHS card is replaced with an SD Express
> card.  The card reader is hot-unplugged and the SD Express card appears
> as an NVMe drive with a different Device ID in config space:
>
> https://lore.kernel.org/r/[email protected]/
>
> That said, I'm not even sure RTS525A supports SD Express.
>
> What kind of card do you have inserted in the card reader, is it UHS
> or SD Express?  Does the issue go away if you eject the card before
> going to system sleep?
>

I've been using a SanDisk Ultra 32GB microSDHC UHS-I Card. And yes, it
only happens when the card is present.

> > +++ b/drivers/pci/quirks.c
> [...]
> > +/*
> > + * The MSI Claw A8 firmware advertises native PCIe hotplug support for
> > + * this root port, but native hotplug handling causes resume failures.
> > + * Prevent the PCIe port driver from claiming native hotplug ownership
> > + * of this port.
> > + */
> > +static void quirk_claw_a8_no_native_hotplug(struct pci_dev *pdev)
> > +{
> > +     if (!dmi_match(DMI_BOARD_NAME, "MS-1T8K"))
> > +             return;
> > +
> > +     if (pdev->bus->number != 0 ||
> > +         PCI_SLOT(pdev->devfn) != 2 ||
> > +         PCI_FUNC(pdev->devfn) != 2)
> > +             return;
> > +
> > +     pci_info(pdev, "disabling native PCIe hotplug\n");
> > +     pdev->is_hotplug_bridge = 0;
> > +     pdev->is_pciehp = 0;
> > +}
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, 0x150b,
> > +                      quirk_claw_a8_no_native_hotplug);
>
> Unfortunately this is just a workaround that happens to make the
> issue disappear, but we'd really want to identify the root cause
> first.
>
> If you boot with no_console_suspend, are you able to see any messages
> on suspend or resume that could help us understand what is going on?
>

Nothing of note. After amdgpu finishes its smu resume sequence the
console _ flashes and doesn't progress.

I did try adding some debug printing to pciehp_device_replaced() but
saw no output for that either. Since that didn't work I tried
replacing each true result in the function one at a time and found the
offending case

        if (pdev->hdr_type == PCI_HEADER_TYPE_NORMAL &&
            (pci_read_config_dword(pdev, PCI_SUBSYSTEM_VENDOR_ID, &reg) ||
-            reg != (pdev->subsystem_vendor | (pdev->subsystem_device << 16))))
-               return true;
+            reg != (pdev->subsystem_vendor | (pdev->subsystem_device
<< 16)))) {
+               pci_info(pdev, "pdev subsystem vendor ID mismatch");
+               return false;
+
+       }


[   25.686128] rtsx_pci 0000:c2:00.0: pciehp: pdev subsystem vendor ID mismatch

Any insight on why that might be occurring and what my next
troubleshooting steps should be are appreciated.

** Update: after my initial email & before I sent it back to the
entire ML I did another test and printed the reg vs expected values.
It seems the SD card reader ID is reflected when it is enumerated
during resume.

reg=0x525a10ec expected=0x14af1462

Thanks,

Derek

> Thanks,
>
> Lukas