public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@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: Thu, 26 Mar 2026 07:12:00 +0100	[thread overview]
Message-ID: <20260326061200.GA3552@black.igk.intel.com> (raw)
In-Reply-To: <5d6d94b4-458f-473c-84df-c6fab7805dbe@linux.intel.com>

On Wed, Mar 25, 2026 at 02:12:48PM -0700, Kuppuswamy Sathyanarayanan wrote:
> 
> 
> On 3/24/2026 11:11 PM, Mika Westerberg wrote:
> > On Tue, Mar 24, 2026 at 02:45:25PM -0700, Kuppuswamy Sathyanarayanan wrote:
> >>> eb34da60edee ("PCI: pciehp: Disable hotplug interrupt during suspend")
> >>> cleared PCI_EXP_SLTCTL_HPIE so that when the link goes down, we
> >>> wouldn't get a PCI_EXP_SLTSTA_DLLSC interrupt and wake the system.
> >>>
> >>> I don't know the details of why the PCI_EXP_SLTSTA_DLLSC would cause
> >>> that wakeup.  I would think pciehp should field that, and it should be
> >>> able to figure out whether to bring the port out of D3hot.
> >>>
> >>> Anyway, with this patch it looks like we'll leave PCI_EXP_SLTCTL_HPIE
> >>> set, and potentially get that PCI_EXP_SLTSTA_DLLSC interrupt again?
> >>
> >> I have tested this patch on Catlow Lake. Enabling HPIE does not result in
> >> spurious wakeups as mentioned in Mika's patch.
> >>
> >> Mika, any comments?
> > 
> > What do you have connected to the slot?
> 
> A network card.

Okay.

Out of interest how do you hotplug it? :)

> > IIRC the interrupt triggers when presence change toggles (due to the link
> > going down).
> > 
> 
> I have tested the s3 mode. I was able to see message related to system entering
> suspend and then coming back again after (after user intervention). I also noted
> pcie_disable_interrupt() called before suspend and pcie_enable_interrupt() called
> after resume.

In case of S3 the BIOS also configures the hardware before entering
suspend. On client at least it's suspend-to-idle and any interrupt will
bring the CPU and the system out of it. It could be that that's the reason
you don't see any issue if this is server system and it goes into full S3?

  reply	other threads:[~2026-03-26  6:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-16 22:08 [PATCH v3] PCI: pciehp: Fix hotplug on Catlow Lake with unreliable PME status 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 [this message]
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

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=20260326061200.GA3552@black.igk.intel.com \
    --to=mika.westerberg@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=rafael@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox