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

[Lukas Wunner]

On Sat, Aug 08, 2026 at 08:34:38PM -0700, Derek John Clark wrote:
> This was good instinct. I was able to drill down and find
> approximately where it is hanging.
> 
> rtsx_pci_remove() ->mfd_remove_devices() -> mfd_remove_devices_fn() ->
> platform_device_unregister() -> platform_device_del() -> device_del()
> -> bus_remove_device() -> device_release_driver() ->
> device_release_driver_internal() -> __device_release_driver() ->
> device_remove()
> 
> In device_remove() (drivers/base/dd.c) it gets past
> device_remove_groups() and hangs before completing this if block:
> 
> if (dev->bus && dev->bus->remove)
>     dev->bus->remove(dev);
> else if (dev->driver->remove)
>     dev->driver->remove(dev);

Okay, that ->remove callback should be rtsx_pci_sdmmc_drv_remove()
in drivers/mmc/host/rtsx_pci_sdmmc.c.  Can you maybe identify where
execution stops in that function?

Basically the rtsx_pci driver creates a child device of the PCI device
and the mmc host driver binds to that child device.  Removing the
mmc host driver fails here for some reason.

> > 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.)
> 
> i get card not present, then card present, then link up.
> 
> > Also, what's the subsystem vendor/device ID as seen with lspci after
> > a successful system sleep transition (successful = without SD card)?
> 
> it reflects the Realtek device VID/PID. I also tested resume after the
> 1 cycle with it re-inserted and it works fine after the first cycle,
> presumably because the device id matches on the second run and beyond

Right, when the device is re-enumerated after the first system sleep
transition, the Realtek subdevice vendor/device ID is cached and that
matches on all subsequent system sleep transitions.  So if we manage
to find and eliminate the cause of the hang, there'll only be the
inconvenience of the removal/re-enumeration on first sleep.

Thanks,

Lukas