PCI: pciehp: spurious "device replaced" on resume, Acer Nitro ANV16S-41 NVIDIA dGPU (same as MSI Claw A8)

[Vanchez Rodriges <vrsmilemen4@gmail.com>]

Hi,

This is the same problem as in the MSI Claw A8 thread, on a different
laptop:
https://lore.kernel.org/all/20260806214808.1202819-1-derekjohn.clark@gmail.com/

I am not subscribed to that thread, so I start a new one. Here the
device is the NVIDIA dGPU, not a card reader.

Hardware:
- Acer Nitro ANV16S-41, board BRZ_SKF, BIOS V1.14 (2026-04-02)
- Root port 00:01.1 [1022:14ed], HotPlug+ Surprise+
- 01:00.0 NVIDIA [10de:2d18] (RTX 5070 Laptop)
- 01:00.1 NVIDIA HDA [10de:22eb]
- Kernel: Ubuntu 7.0.0-43 (based on 7.0.14), s2idle

What happens:
- At boot the firmware writes Subsystem 1025:1969 into the GPU. The
  kernel caches 0x1969 at enumeration.
- After the first D3cold cycle (runtime PM, before any system sleep) the
  register at 0x2c reads 1025:1883. sysfs subsystem_device still says
  0x1969.
- On resume pciehp_device_replaced() sees the mismatch:

    pcieport 0000:00:01.1: pciehp: device replaced during system sleep
    pciehp: Slot(0): Card not present

  and the resume hangs. pm_trace points to device_resume() for
  0000:01:00.1. No pstore, no lockup or hung task report.

What I checked:
- It hangs with and without the NVIDIA driver (module_blacklist), with
  pm_async 1 and 0, and with the GPU kept in D0 (power/control = on).
- In ACPI (SSDT), the power resource of the root port, PG00._ON, writes
  the subsystem value through a register at 0x40 of the GPU
  (PEGP.SSSV = DSSV), only in the path after power-on and reset. Writing
  0x40 from the OS with setpci does not change 0x2c.
- If the kernel caches 0x1883 instead, the problem is gone. I tested
  this two ways: GPU removed and rescanned after one D3cold cycle, and
  GPU re-enumerated by pciehp after a resume. Both sleep and wake fine.

Workaround that works now: a oneshot unit before systemd-udev-trigger
removes 01:00.1 and 01:00.0, waits for 00:01.1 to reach D3cold, then
rescans the bridge. After that the kernel caches 0x1883. Two lid-close
cycles passed (25 s and about 1.5 h), with the NVIDIA driver loaded.

So this looks like the same firmware behaviour as on the MSI Claw.
Lukas, your quirk_msi_claw_cardreader() in that thread
(https://lore.kernel.org/all/any5ciFCjh-0cGkB@wunner.de/) matches only
the Realtek device, so it does not help here. The same kind of
SUSPEND_LATE quirk for this GPU would be: NVIDIA 0x2d18 with cached
subsystem 1025:1969, set subsystem_device to 0x1883 (the value the card
reports after power loss, not the vendor/device ID as on the Claw).
I have not built a kernel with it, so this is untested.

Your other patch for the removal path
(https://lore.kernel.org/all/any3vMJMpxdK8Ekp@wunner.de/) is also
relevant: here the hang is in device_resume() of 01:00.1 (snd_hda_intel)
while pciehp removes the slot. I have not checked where exactly it
blocks.

Other ANV16S-41 owners report the same hang on wake, for example with
RTX 5060, so the IDs may differ per model.

I can send the ACPI dump, lspci -xxxx before and after D3cold, or a
full dmesg if that helps.

Thanks