From: Sinan Kaya <okaya@kernel.org>
To: "Kuppuswamy,
Sathyanarayanan" <sathyanarayanan.kuppuswamy@linux.intel.com>,
Lukas Wunner <lukas@wunner.de>,
Sathyanarayanan Kuppuswamy Natarajan
<sathyanarayanan.nkuppuswamy@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Linux PCI <linux-pci@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Raj, Ashok" <ashok.raj@intel.com>,
Keith Busch <kbusch@kernel.org>,
knsathya@kernel.org
Subject: Re: [PATCH v2 1/1] PCI: pciehp: Skip DLLSC handling if DPC is triggered
Date: Thu, 18 Mar 2021 11:35:55 -0400 [thread overview]
Message-ID: <1069dc19-35ac-be1a-b02a-3815503cb295@kernel.org> (raw)
In-Reply-To: <0a020128-80e8-76a7-6b94-e165d3c6f778@linux.intel.com>
On 3/17/2021 4:02 PM, Kuppuswamy, Sathyanarayanan wrote:
> My point is, there is no race in OS handlers (pciehp_ist() vs
> pcie_do_recovery())
> However, Sinan wrote in
>> 2018 that one of the issues with hotplug versus DPC is that pciehp
>> may turn off slot power and thereby foil DPC recovery. (Power off =
>> cold reset, whereas DPC recovery = warm reset.) This can occur
>> as well if DPC is handled by firmware.
It has been a while...
If I remember correctly, there is no race condition if the platform
handles DPC and HP interrupts on the same MSI vector.
If HP and DPC interrupts are handled as MSI-x interrupts, these can
fire out of order and can cause problems for each one.
I hope it helps.
next prev parent reply other threads:[~2021-03-18 15:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-13 3:32 [PATCH v2 1/1] PCI: pciehp: Skip DLLSC handling if DPC is triggered sathyanarayanan.kuppuswamy
2021-03-13 3:35 ` Kuppuswamy, Sathyanarayanan
2021-03-17 4:13 ` Lukas Wunner
2021-03-17 5:08 ` Dan Williams
2021-03-17 5:31 ` Lukas Wunner
2021-03-17 16:31 ` Dan Williams
2021-03-17 17:19 ` Sathyanarayanan Kuppuswamy Natarajan
2021-03-17 17:45 ` Dan Williams
2021-03-17 17:54 ` Sathyanarayanan Kuppuswamy Natarajan
2021-03-17 19:01 ` Lukas Wunner
2021-03-17 20:02 ` Kuppuswamy, Sathyanarayanan
2021-03-18 15:35 ` Sinan Kaya [this message]
2021-03-28 9:53 ` Lukas Wunner
2021-03-17 19:09 ` Lukas Wunner
2021-03-17 19:22 ` Raj, Ashok
2021-03-17 19:40 ` Lukas Wunner
2021-03-28 5:49 ` Kuppuswamy, Sathyanarayanan
2021-03-28 9:07 ` 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=1069dc19-35ac-be1a-b02a-3815503cb295@kernel.org \
--to=okaya@kernel.org \
--cc=ashok.raj@intel.com \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=kbusch@kernel.org \
--cc=knsathya@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=sathyanarayanan.nkuppuswamy@gmail.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.