From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] PCI: pciehp: Fix hotplug on Catlow Lake with unreliable PME status
Date: Tue, 17 Feb 2026 09:01:25 -0800 [thread overview]
Message-ID: <70533ce4-265e-449c-bd63-06f2d7f5bdf1@linux.intel.com> (raw)
In-Reply-To: <aZCQsyL9RRessjMI@wunner.de>
On 2/14/2026 7:11 AM, Lukas Wunner wrote:
> On Sat, Feb 14, 2026 at 07:01:13AM +0100, Lukas Wunner wrote:
>> On Fri, Feb 13, 2026 at 03:14:28PM -0800, Kuppuswamy Sathyanarayanan wrote:
>>> On Intel Catlow Lake platforms, PCH PCIe root ports do not reliably
>>> update PME status registers (PME Status and PME Requester_ID in the
>>> Root Status register) during D3hot to D0 transitions, even though PME
>>> interrupts are delivered correctly.
>>
>> Hm, so in theory we could amend the PME driver to walk the bus below the
>> Root Port and see if anything has PME_Status set in the PMCSR register.
>>
>> But the PME interrupt is shared with hotplug, bandwidth control etc,
>> so we'd end up gratuitouly (and frequently) runtime resuming switches
>> below the Root Port to see if there's anything below which is requesting
>> wakeup.
>>
>> So just keeping the Root Port runtime resumed all the time, as this
>> patch does, is still a better approach IMO.
>>
>> I'm wondering though if this causes a power regression. Does keeping
>> the Root Port in D0 prevent the Package from entering a lower power
>> state? Or is this irrelevant because the PCH is a different chip
>> or tile?
>
> I've just realized that pcie_disable_interrupt() isn't called from
> pciehp_suspend() if pme_is_native() is true. Should disabling
> runtime PM cause a power regression, an alternative solution may be
> to make pcie_disable_interrupt() conditional on a new pme_is_broken()
> which checks for affected Catlow Lake PCH Root Ports.
>
> The pm_runtime_disable() approach is slightly preferred because
> it keeps pciehp code clean.
I think pcie_disable_interrupt() is called from pciehp_suspend() when
pme_is_native() is true. Looking at the code:
static void pciehp_disable_interrupt(struct pcie_device *dev)
{
/*
* Disable hotplug interrupt so that it does not trigger
* immediately when the downstream link goes down.
*/
if (pme_is_native(dev))
pcie_disable_interrupt(get_service_data(dev));
}
#ifdef CONFIG_PM_SLEEP
static int pciehp_suspend(struct pcie_device *dev)
{
/*
* If the port is already runtime suspended we can keep it that
* way.
*/
if (dev_pm_skip_suspend(&dev->port->dev))
return 0;
pciehp_disable_interrupt(dev);
return 0;
}
pciehp_suspend() calls pciehp_disable_interrupt(), which in turn calls
pcie_disable_interrupt() only if pme_is_native() is true. So the interrupt
is disabled during suspend specifically when PME is native, not the other
way around. Did I misread your statement?
>
> Thanks,
>
> Lukas
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
next prev parent reply other threads:[~2026-02-17 17:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 23:14 [PATCH v2] PCI: pciehp: Fix hotplug on Catlow Lake with unreliable PME status Kuppuswamy Sathyanarayanan
2026-02-14 6:01 ` Lukas Wunner
2026-02-14 15:11 ` Lukas Wunner
2026-02-17 17:01 ` Kuppuswamy Sathyanarayanan [this message]
2026-02-17 18:22 ` Lukas Wunner
2026-02-18 16:28 ` Kuppuswamy Sathyanarayanan
2026-02-17 16:54 ` Kuppuswamy Sathyanarayanan
2026-02-17 18:08 ` Rafael J. Wysocki
2026-02-18 16:27 ` Kuppuswamy Sathyanarayanan
2026-02-18 17:33 ` Rafael J. Wysocki
2026-02-19 8:04 ` Lukas Wunner
2026-02-19 11:09 ` Rafael J. Wysocki
2026-02-19 21:54 ` Kuppuswamy Sathyanarayanan
2026-03-09 18:04 ` Kuppuswamy Sathyanarayanan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=70533ce4-265e-449c-bd63-06f2d7f5bdf1@linux.intel.com \
--to=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.