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

[Farhan Ali <alifm@linux.ibm.com>]

Hi Bjorn,

Thanks for cc'ing me.

On 10/8/2026 3:58 PM, Bjorn Helgaas wrote:
> [+cc Lukas, Farhan, Andreas, Mika, Yehezkel]
>
> On Wed, Sep 30, 2026 at 11:19:13AM -0300, Francisco Beltrán Millalén wrote:
>> pci_save_state() reads the standard header into dev->saved_config_space
>> and marks it valid without checking that the device answered.  If the
>> device is not accessible, every read returns all ones, the previous
>> snapshot is overwritten, and pci_restore_state() writes the all-ones
>> values back once the device answers again.  On a bridge that sets every
>> writable bit of the Bridge Control register, Secondary Bus Reset
>> included, and sets the primary, secondary and subordinate bus numbers
>> to 0xff, which cuts off everything below it.
>>
>> On a MacBookPro14,3 this happens to the upstream bridge of a
>> Thunderbolt controller that drops off the bus while the system is
>> suspending: after resume the bridge answers again, but with bus numbers
>> ff/ff/ff and Secondary Bus Reset asserted, and the xHCI controllers
>> behind it are removed.
> Apparently this is a reproducible issue on MacBookPro14,3.  That makes
> me a little hesitant because we're not actually dealing with the fact
> that the Thunderbolt controller isn't responsive during suspend.
>
> It seems worthwhile to me to skip pci_save_state() if the device isn't
> accessible, but I don't think it's a real solution to whatever is
> going on with Thunderbolt, and I don't think we should mention it here
> as though it is.

When I had initially looked into this, I had proposed adding the 
accessibility check in pci_save_state() as well [1]. Though Lukas had 
some valid concerns around the additional overhead from adding it in 
pci_save_state(). But maybe its worth re-visiting again?

Thanks

Farhan

[1] https://lore.kernel.org/all/aOQX6ZTMvekd6gWy@wunner.de/