Re: [PATCH] PCI: pciehp: Disable link and turn off slot power while removing

[Mario Limonciello <mario.limonciello@amd.com>]

On 5/6/26 12:55, Lukas Wunner wrote:
> On Wed, May 06, 2026 at 11:43:50AM -0500, Mario Limonciello wrote:
>> When a hotplug slot is removed, pciehp still leaves both the slot and link
>> active. If a device is still physically connected, platform firmware
>> may continue to poll the link. On some systems with Thunderbolt 3 devices
>> connected this prevents the system from shutting down until the device is
>> disconnected.
> 
> "On some systems" is a little vague.  Which ones?  What is platform firmware
> doing there exactly, is this something in AML?

In this case it was a Strix Halo OEM design that I don't have visiblity 
a layer lower.

But issue is specific to Thunderbolt 3 devices, doesn't happen with USB4 
devices with an active PCIe tunnel for some reason.

This doesn't reproduce on the reference designs we tried.

I /might/ be able to get some traces though from a USB4 analyzer with 
OEM design.

> 
>> To fix this add code to pciehp_power_off_slot() to reverse the init
>> sequence from pciehp_power_on_slot() (power on, then enable link becomes
>> disable link, then power off).
> 
> Unfortunately it's not as easy as that.  You're essentially reverting
> commit b1811d2455f3 ("PCI: pciehp: Don't disable the link permanently
> during removal"), so you'll regress those products for which the commit
> deliberately removed link disablement on slot poweroff.

Thanks for that pointer.  Unfortuantely the Link: tag for the discussion 
is HTTP 403.

> 
> Moreover there are products where Presence Detect is hardwired to zero,
> see commit 80696f991424 ("PCI: pciehp: Tolerate Presence Detect hardwired
> to zero").  So we have to rely on a link change to detect that a new device
> has been plugged in after slot poweroff.  That won't work if the link is
> disabled.
> 

How would you feel about turning off link detect somewhere specific to 
the shutdown path?