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

[Lukas Wunner <lukas@wunner.de>]

On Fri, Sep 25, 2026 at 10:38:08AM -0700, Kuppuswamy Sathyanarayanan wrote:
> 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 a device below the Root Port (instead of the Root Port itself)
signals PME, does the Root Port misbehave in the same way?
I.e. is the PME Status bit clear in that case as well?

If so, the proper solution might be to add a quirk to the PME driver,
not the PCIe hotplug driver.

pcie_pme_irq() checks PME Status and bails out if it's not set.
That would need an amendment such that Root Ports with broken PME
would always assume it's set if they receive a PME.  I think that
would be safe because even though PME is shared with other interrupts
such as hotplug, I think it's the only interrupt source once the port
is in D3hot.

There's another check for PME Status in pcie_pme_work_fn().
This one is tricky because it uses the PME Status bit to jump
out of the for-loop.  Does the Root Port at least set the
Requester ID to an appropriate value?  If so maybe that can be
used as an indicator whether the loop should be terminated.

Or maybe the PME Pending bit can be used in lieu of PME Status?

Thanks,

Lukas