Re: [PATCH v2 0/3] PCI/PM: Do not save the config space of an inaccessible device

[Darrell Gum <d@rrell.co>]

On Wed, 30 Sep 2026 11:19:11 -0300, Francisco Beltrán Millalén wrote:
> When a PCI device becomes inaccessible while the system is suspending,
[...]

Hi Francisco,

I tested this series on another MacBookPro14,3, together with your
Alpine Ridge SXFP quirk and the Apple native PME patch. On this
machine the combination takes S3 from never resuming to working, and
it fixes USB-C hotplug while the Thunderbolt xHCIs are
runtime-suspended.

Hardware: MacBookPro14,3 (15", 2017, T1), two Alpine Ridge 4C
controllers:

  upstream bridges    8086:1578   04:00.0, 7a:00.0
  downstream bridges  8086:15d3
  NHI                 8086:15d2   06:00.0, 7c:00.0
  xHCI                8086:15d4   07:00.0, 7d:00.0

The dGPU is a Radeon Pro 555 (1002:67ef, subsystem 106b:017a rev c7).

Kernel: 7.2.5 with the Omarchy distro patches (linux-omarchy
7.2.5-3), plus these, in this order:

  e18d1abc3bff ("PCI: Avoid saving config space state if inaccessible")
  this series, v2 1/3-3/3
  PCI: Extend Apple Thunderbolt power quirk to Alpine Ridge
  ACPI: PCI: take native PME control on Apple machines
  a5be7ad8f5f0 + a22e5e4f2ebb (amdgpu VI reset quirk, incl. 017a)

Everything applied with offsets only (no fuzz) on 7.2.5.
mem_sleep=deep, stock command line.

I applied and tested all of these together. I did not bisect them,
so beyond what the logs show directly I can't pin a result on one
patch.

Before (stock 7.2.5-3 on the same machine):

- pm_test=platform hard-hung 3 out of 3 times. That includes a fresh
  boot and runs with brcmfmac unloaded, and it did not recover after
  more than 3.5 minutes. pm_test=devices passed.
- Real S3 never resumed. Every attempt needed a forced power-off.
- With both TB xHCIs runtime-suspended (power/control=auto), plugging
  a USB 3 stick into any USB-C port produced no kernel messages at
  all. With power/control=on, it enumerated at SuperSpeed right away.

After (patched kernel):

- _OSC now reads "OS assumes control of [PCIeHotplug SHPCHotplug PME
  AER PCIeCapability LTR DPC]". PME is missing from that line on the
  stock kernel.
- Hotplug: with both xHCIs runtime-suspended, the same stick
  enumerated at SuperSpeed within about 1 s. 7d:00.0 resumed on its
  own and 07:00.0 stayed suspended. Nothing was forced.
- pm_test=platform passes. "quirk: cutting power to Thunderbolt
  controller..." is logged for both 04:00.0 and 7a:00.0.
- Real S3: every attempt resumed. That was about half a dozen real
  S3 cycles over one morning: rtcwake on AC, plus lid-close suspends
  on battery. amdgpu resumed in 1.2 s.
- With a device attached (lid-close S3 on battery, about 1 min
  asleep): a USB 3 stick was enumerated at SuperSpeed on 7d:00.0
  (behind 7a:00.0) before suspend. The quirk logged for both 7a:00.0
  and 04:00.0 with the stick attached. After resume the stick was
  still there with no USB disconnect logged, still at 5000 Mbps, and
  its filesystem mounted and listed fine. Unplugging it and plugging
  it back in about 2 min after resume re-enumerated it at SuperSpeed
  in about 3 s, with power/control=auto.
- On that cycle the xHCI of the other, empty controller logged
  "xhci_hcd 0000:07:00.0: xHC error in resume, USBSTS 0x401, Reinit"
  and recovered. I'm mentioning it only because it's on the path
  your quirk affects; I haven't looked into it further.
- noirq resume takes about 16 s (15.9 s on a real S3 cycle). About
  11 s of that is in each upstream bridge (04:00.0, 7a:00.0), then
  about 5 s in the NHIs (06:00.0, 7c:00.0). Another 14,3 owner
  reports the same split in s2idle (stock kernel plus a local
  Thunderbolt workaround), and says it drops to about 0.5 s with the
  ACPICA change proposed in
  https://github.com/open-acpica/acpica/pull/1235 . I haven't tried
  that here.

Not covered:

- The "plugging into USB-C no longer wakes it" trade-off is
  untested here.
- Only one S3 cycle had a device attached, and it was a USB stick.
  No real Thunderbolt devices and no SR-IOV.
- The stock kernel also lacked the amdgpu quirk, so the real-S3
  before/after mixes both changes. The cleaner Thunderbolt-side
  comparison is pm_test=platform: the devices stage, amdgpu included,
  already passed on stock.

Two workarounds that have nothing to do with Thunderbolt were in place
for every patched-kernel run, in case they show up in other reports:

- d3cold_allowed=0 on the NVMe SSD (02:00.0). On stock, the machine
  never even reached S3 without it. I have not retested without it on
  the patched kernel.
- brcmfmac (BCM43602, 03:00.0) unloaded before suspend and reloaded
  after. Left bound through a real S3, the Wi-Fi firmware state is
  lost.

Thanks for chasing this down. This is the first kernel on which this
machine resumes from S3 at all.

Tested-by: Darrell Gum <d@rrell.co>