From: Lukas Wunner <lukas@wunner.de>
To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
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: Sat, 14 Feb 2026 16:11:47 +0100 [thread overview]
Message-ID: <aZCQsyL9RRessjMI@wunner.de> (raw)
In-Reply-To: <aZAPqQTiGQiDvX52@wunner.de>
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.
Thanks,
Lukas
next prev parent reply other threads:[~2026-02-14 15:20 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 [this message]
2026-02-17 17:01 ` Kuppuswamy Sathyanarayanan
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=aZCQsyL9RRessjMI@wunner.de \
--to=lukas@wunner.de \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
/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.