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

[Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>]

On 9/25/2026 11:35 AM, Lukas Wunner wrote:
> 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.

I don't know, since my test only ever exercises the Port's own PME.  I will
collect that data and get back to you.

> 
> 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

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer