Re: [PATCH v3] PCI: pciehp: Fix hotplug on Catlow Lake with unreliable PME status

[Kuppuswamy Sathyanarayanan]

Hi Mika,

On 9/24/2026 10:19 PM, Mika Westerberg wrote:
> Hi,
> 
> On Thu, Sep 24, 2026 at 11:46:04AM -0700, Kuppuswamy Sathyanarayanan wrote:
>> Hi Bjorn/Mika,
>>
>> On 9/11/2026 10:01 AM, Kuppuswamy Sathyanarayanan wrote:
>>> Hi Mika, Bjorn, Lukas, Rafael,
>>>
>>
>> Gentle ping on my reply below.
>>
>> Bjorn, could you let me know which of the three directions you would like
>> me to take for v5?
>>
>> Mika, could you take a look at the acpi_pci_bridge_d3() findings and let
>> me know if they match your understanding?
> 
> I have already forgotten what this is about ;-) Maybe some refresher would
> help here.
> 
> If I understand right the root port has _PR3() but no _S0W so
> acpi_pci_bridge_d3() returns false for it? Then pci_bridge_d3_possible()
> returns false as well and the root port stays in D0? And that should make
> the hotplug PME work just fine but you are sayng that's not the case on
> Catlow Lake?

Sorry, my last mail was too long. It is the other way around on both
points.

For reference, I did a detailed recap of the overall problem, the D3cold 
evaluation, and the three potential design paths for v5 in my last email here:

https://lore.kernel.org/linux-pci/20260911170100.kuppuswamy.sathyanarayanan@xxxxxxxxx/

To recap the ACPI behavior:
The Root Port (\_SB.PC00.RP25) has _PS0, _PS3 and _PRW. It has no _PR0,
no _PR3, no _S0W and no HotPlugSupportInD3.

So acpi_pci_bridge_d3() returns true, not false. It never gets to the
HotPlugSupportInD3 check because it returns early here:

	if (adev) {
		if (acpi_dev_power_state_for_wake(adev) <= ACPI_STATE_D2)
			return false;	/* no _S0W, not taken */
		if (acpi_device_power_manageable(adev))
			return true;	/* _PS0 is enough, taken */
	}

pci_bridge_d3_possible() is therefore true and the port runtime suspends
to D3hot (sysfs shows power/control is "auto" for this port). Because there
is no _PR0 or _PR3, it never reaches D3cold.

Once the port is in D3hot, pciehp has cleared HPIE and depends on PME.
That is where Catlow breaks. The PME interrupt arrives, but PME Status in
Root Status is never set. pcie_pme_irq() returns IRQ_NONE, the port stays
in D3hot and the hot-add event is lost.

If the port stayed in D0 as you describe, runtime hotplug would work. v2
did that and it worked. But it costs about 10% PC6 residency, and
pciehp_suspend() still clears HPIE on the way into s2idle.

The question for you is whether this matches your reading. With no power
resource, there is no PERST# assertion and no presence detect toggle on
suspend. So leaving HPIE enabled should not bring back the spurious wakeup
that eb34da60edee fixed. If you agree, that is the justification I would
put in v5 for keeping HPIE enabled on these ports.

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer