From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Lukas Wunner <lukas@wunner.de>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] PCI: pciehp: Fix hotplug on Catlow Lake with unreliable PME status
Date: Fri, 25 Sep 2026 10:38:08 -0700 [thread overview]
Message-ID: <c5754240-1768-44a2-869c-6b159fd54907@linux.intel.com> (raw)
In-Reply-To: <20260925051922.GU106095@black.igk.intel.com>
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@intel.com/
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
next prev parent reply other threads:[~2026-09-25 17:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 22:08 Kuppuswamy Sathyanarayanan
2026-03-23 12:53 ` Lukas Wunner
2026-03-23 23:24 ` Bjorn Helgaas
2026-03-24 21:45 ` Kuppuswamy Sathyanarayanan
2026-03-24 23:46 ` Bjorn Helgaas
2026-03-25 5:56 ` Lukas Wunner
2026-03-25 23:21 ` Bjorn Helgaas
2026-03-25 6:11 ` Mika Westerberg
2026-03-25 21:12 ` Kuppuswamy Sathyanarayanan
2026-03-26 6:12 ` Mika Westerberg
2026-03-26 21:23 ` Kuppuswamy Sathyanarayanan
2026-03-27 11:16 ` Mika Westerberg
2026-04-03 19:37 ` Kuppuswamy Sathyanarayanan
2026-04-07 7:08 ` Mika Westerberg
2026-09-11 17:01 ` Kuppuswamy Sathyanarayanan
2026-09-24 18:46 ` Kuppuswamy Sathyanarayanan
2026-09-25 5:19 ` Mika Westerberg
2026-09-25 17:38 ` Kuppuswamy Sathyanarayanan [this message]
2026-09-25 18:35 ` Lukas Wunner
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=c5754240-1768-44a2-869c-6b159fd54907@linux.intel.com \
--to=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®