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

[Lukas Wunner <lukas@wunner.de>]

On Fri, Aug 07, 2026 at 05:31:04PM -0700, Derek John Clark wrote:
> [   25.686128] rtsx_pci 0000:c2:00.0: pciehp: pdev subsystem vendor ID mismatch
[...]
> reg=0x525a10ec expected=0x14af1462

The subsystem vendor ID was 0x1462 (MSI) when the card reader was
enumerated on boot and it is 0x10ec (Realtek) on resume.

Likewise the subystem device ID was 0x14af on boot, 0x525a on resume.

It's another bug in the MSI BIOS (in addition to marking the Root Port
hotplug-capable):  The BIOS neglected to re-initialize the subsystem
vendor/device ID registers in config space on resume to the same
values that it set on boot.  The card reader was likely reset while
going through the system sleep transition and its config space
thus needs to be re-initialized.

What happens is that pciehp marks the card reader disconnected
because it assumes that it was replaced during system sleep.
It then synthesizes a Presence Detect Changed event:

https://elixir.bootlin.com/linux/v7.2-rc6/source/drivers/pci/hotplug/pciehp_core.c#L300

So the pciehp interrupt thread pciehp_ist() will remove the
rtsx_pci driver and de-enumerate the device.

Replacing or removing PCIe devices during system sleep happens
all the time (e.g. with Thunderbolt) and we haven't seen issues
with regards to that.  The likelihood is higher that the lockup
is caused by rtsx_pci.

Maybe rtsx_pci_remove() blocks somewhere and prevents forward
progress of the resume transition.  In particular, it calls
pm_runtime_get_sync() and cancel_delayed_work_sync(), which are
blocking calls, i.e. they wait for something else to happen.
You could try commenting those calls out and see if it avoids
the lockup:

https://elixir.bootlin.com/linux/v7.2-rc6/source/drivers/misc/cardreader/rtsx_pcr.c#L1608

Another possibility is a crash due to a NULL pointer deref or
GPF somewhere in that driver.  This is pretty difficult to debug
if there's no possibility to see any dmesg output.

Even if we manage to find the root cause of the lockup, as long as
the BIOS isn't fixed, the card reader will always be de-enumerated
and re-enumerated on resume and consequently the card will briefly
disappear.  This will make it impossible to use the card as root
filesystem.

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

If you go to sleep and resume without SD card, do you then see in dmesg
that the card reader was de-enumerated and re-enumerated?  Normally
there should be at least a "Card not present" / "Card present" message
from pciehp, if it sensed a replaced device.  ("Card" refers to PCIe card,
not SD card.)

Also, what's the subsystem vendor/device ID as seen with lspci after
a successful system sleep transition (successful = without SD card)?

Thanks,

Lukas