From: Matthew W Carlis <mattc@purestorage.com>
To: sathyanarayanan.kuppuswamy@linux.intel.com
Cc: bhelgaas@google.com, helgaas@kernel.org, kbusch@kernel.org,
linux-pci@vger.kernel.org, lukas@wunner.de,
mattc@purestorage.com, mika.westerberg@linux.intel.com
Subject: [PATCH 1/1] PCI/portdrv: Allow DPC if the OS controls AER natively.
Date: Mon, 8 Jan 2024 12:46:42 -0700 [thread overview]
Message-ID: <20240108194642.30460-1-mattc@purestorage.com> (raw)
In-Reply-To: <ed47c116-78eb-40d7-a5e7-0c23e1e6712f@linux.intel.com>
Hello again, sorry for the delayed response.. I have been on PTO. The above patch
doesn't fix the problem in our systems as host->native_dpc is not set due to
not using or having support for Error Disconnect Recovery (EDR). I wonder if
host->native_dpc is a misleading name a way... Misleading in the sense that
setting host->native_aer implies firmware intends the OS to control AER, whereas
host->native_dpc being set appears to have an additional requirement on the
use/support of EDR in addition to DPC. When I was working on the patch as
submitted I had been thinking about all of these fields & my thinking was
as follows.. The kernel requires host->native_aer in order to control AER, but
it could control DPC whether host->native_dpc is set or unset. Therefore, if
the kernel will control AER it should also control DPC on any capable devices.
Of course there is also the requirement of having built with CONFIG_PCIE_AER
& CONFIG_PCIE_DPC. Please advise if my understanding of all this is incorrect..
Thanks,
-Matt
I included an update to the patch submitted in chain which should remove the
build error that occured when CONFIG_PCIE_AER was not set. Including it
in case my understanding of EDR/DPC/etc is correct.
diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c
index 14a4b89a3b83..2fc006f12988 100644
--- a/drivers/pci/pcie/portdrv.c
+++ b/drivers/pci/pcie/portdrv.c
@@ -257,12 +257,18 @@ static int get_port_device_capability(struct pci_dev *dev)
}
/*
+ * _OSC AER Control is required by the OS & requires OS to control AER,
+ * but _OSC DPC Control isn't required by the OS to control DPC; however
+ * it does require the OS to control DPC. _OSC DPC Control also requres
+ * _OSC EDR Control (Error Disconnect Recovery) (PCI Firmware - DPC ECN rev3.2)
+ * PCI_Express_Base 6.1, 6.2.11 Determination of DPC Control recommends
+ * platform fw or OS always link control of DPC to AER.
+ *
* With dpc-native, allow Linux to use DPC even if it doesn't have
* permission to use AER.
*/
if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
- pci_aer_available() &&
- (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
+ pci_aer_available() && (pcie_ports_dpc_native || host->native_aer))
services |= PCIE_PORT_SERVICE_DPC;
if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
next prev parent reply other threads:[~2024-01-08 19:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-23 21:22 [PATCH 1/1] PCI/portdrv: Allow DPC if the OS controls AER natively Matthew W Carlis
2023-12-23 21:22 ` Matthew W Carlis
2023-12-25 17:53 ` kernel test robot
2023-12-25 20:36 ` kernel test robot
2023-12-26 0:02 ` Matthew W Carlis
2023-12-28 21:23 ` Bjorn Helgaas
2024-01-02 15:41 ` Kuppuswamy Sathyanarayanan
2024-01-08 19:46 ` Matthew W Carlis [this message]
2024-01-08 19:53 ` Kuppuswamy Sathyanarayanan
2024-01-09 0:15 ` Matthew W Carlis
2024-01-10 16:41 ` Kuppuswamy Sathyanarayanan
2024-01-10 17:13 ` Kuppuswamy Sathyanarayanan
2024-01-10 20:01 ` Matthew W Carlis
2024-01-10 19:59 ` Matthew W Carlis
2024-01-22 19:32 ` Bjorn Helgaas
2024-01-23 2:37 ` Kuppuswamy Sathyanarayanan
2024-01-23 15:59 ` Bjorn Helgaas
2024-01-23 23:18 ` Matthew W Carlis
2024-01-24 20:29 ` Bjorn Helgaas
2024-02-21 23:11 ` Bjorn Helgaas
2024-02-21 23:33 ` Bjorn Helgaas
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=20240108194642.30460-1-mattc@purestorage.com \
--to=mattc@purestorage.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=kbusch@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--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