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

On Sat, Aug 8, 2026 at 11:22 PM Lukas Wunner <[email protected]> wrote:
>
> 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.

Hi Lukas,

I was able to drill down further. When the mmc device gets to
blk_report_disk_dead() in block/genhd.c there is an xa_for_each loop.
On the second loop of that it seems to hang in bdev_mark_dead(). That
sets a callback that runs fs_bdev_mark_dead() which then runs
sync_filesystem(). This is all hit because the "surprise" bool is set
to false unconditionally in __del_gendisk().

Commenting out this from __del_gendisk():
if (!test_bit(GD_DEAD, &disk->state))
 blk_report_disk_dead(disk, false);

Avoids the hang.

I'm not sure how much further we want to go down into this as we've
moved quite far out of the driver space and are now well into the
block subsystem. I'm working on a proof of concept that would allow
the driver to inform the mmc core that this was a surprise, but I'm
not sure how that would land. From what I've read the mmc core was
intentionally detached from higher level drivers, though a few
notification methods do exist. If I get that fully working I'll post
it here but it will probably be a few days as I've run into some other
obligations this week.

> > > 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.

I suppose that is true, but in that case we still wouldn't be able to
use it as the root fs since it gets removed/re-added during a suspend.
Would the quirk I submitted not have this compromise?

> Thanks,
>
> Lukas