linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shlomo Pongratz <shlomopongratz@gmail.com>
To: linux-pci@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, andrew.maier@eideticom.com,
	logang@deltatee.com, bhelgaas@google.com, jgg@nvidia.com,
	Shlomo Pongratz <shlomop@pliops.com>
Subject: [PATCH V3 1/1] Intel Sky Lake-E host root ports check.
Date: Tue, 29 Mar 2022 13:43:21 +0300	[thread overview]
Message-ID: <20220329104321.4712-2-shlomop@pliops.com> (raw)
In-Reply-To: <20220329104321.4712-1-shlomop@pliops.com>

On commit 7b94b53db34f ("PCI/P2PDMA: Add Intel Sky Lake-E Root Ports B, C, D to the whitelist")
Andrew Maier added the Sky Lake-E additional devices
2031, 2032 and 2033 root ports to the already existing 2030 device.

The Intel devices 2030, 2031, 2032 and 2033 which are ports A, B, C and D,
and if all exist they will occupy slots 0 till 3 in that order.

Now if for example device 2030 is missing then there will no device on slot 0, but
other devices can reside on other slots according to there port.
For this reason the test that insisted that the bridge should be on slot 0 was modified
to support bridges that are not on slot 0.

Signed-off-by: Shlomo Pongratz <shlomop@pliops.com>
---
 drivers/pci/p2pdma.c | 42 +++++++++++++++++++++++++++++++++++++-----
 1 file changed, 37 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index 30b1df3c9d2f..c088d4ab64f4 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -307,6 +307,7 @@ static const struct pci_p2pdma_whitelist_entry {
 	unsigned short device;
 	enum {
 		REQ_SAME_HOST_BRIDGE	= 1 << 0,
+		IS_ROOT_PORT		= 1 << 1,
 	} flags;
 } pci_p2pdma_whitelist[] = {
 	/* Intel Xeon E5/Core i7 */
@@ -316,15 +317,38 @@ static const struct pci_p2pdma_whitelist_entry {
 	{PCI_VENDOR_ID_INTEL,	0x2f00, REQ_SAME_HOST_BRIDGE},
 	{PCI_VENDOR_ID_INTEL,	0x2f01, REQ_SAME_HOST_BRIDGE},
 	/* Intel SkyLake-E */
-	{PCI_VENDOR_ID_INTEL,	0x2030, 0},
-	{PCI_VENDOR_ID_INTEL,	0x2031, 0},
-	{PCI_VENDOR_ID_INTEL,	0x2032, 0},
-	{PCI_VENDOR_ID_INTEL,	0x2033, 0},
+	{PCI_VENDOR_ID_INTEL,	0x2030, IS_ROOT_PORT},
+	{PCI_VENDOR_ID_INTEL,	0x2031, IS_ROOT_PORT},
+	{PCI_VENDOR_ID_INTEL,	0x2032, IS_ROOT_PORT},
+	{PCI_VENDOR_ID_INTEL,	0x2033, IS_ROOT_PORT},
 	{PCI_VENDOR_ID_INTEL,	0x2020, 0},
 	{PCI_VENDOR_ID_INTEL,	0x09a2, 0},
 	{}
 };
 
+/*
+ * The functionality of thisunction can be integrated into
+ * __host_bridge_whitelist function but this will make the code
+ * less readable
+ */
+static bool pci_is_root_port(struct pci_dev *root)
+{
+	const struct pci_p2pdma_whitelist_entry *entry;
+	unsigned short vendor, device;
+
+	vendor = root->vendor;
+	device = root->device;
+
+	for (entry = pci_p2pdma_whitelist; entry->vendor; entry++) {
+		if (vendor != entry->vendor || device != entry->device)
+			continue;
+
+		if (entry->flags & IS_ROOT_PORT)
+			return true;
+	}
+	return false;
+}
+
 /*
  * This lookup function tries to find the PCI device corresponding to a given
  * host bridge.
@@ -333,6 +357,11 @@ static const struct pci_p2pdma_whitelist_entry {
  * bus->devices list and that the devfn is 00.0. These assumptions should hold
  * for all the devices in the whitelist above.
  *
+ * The method above will work in most cases but not for all.
+ * Note that the Intel devices 2030, 2031, 2032 and 2033 are ports A, B, C and D.
+ * Consider on a bus X only port C has devices connected to it so in the PCI scan only
+ * device 8086:2032 on 0000:X:02.0 will be found as bridges with no children are ignored
+ *
  * This function is equivalent to pci_get_slot(host->bus, 0), however it does
  * not take the pci_bus_sem lock seeing __host_bridge_whitelist() must not
  * sleep.
@@ -350,7 +379,9 @@ static struct pci_dev *pci_host_bridge_dev(struct pci_host_bridge *host)
 
 	if (!root)
 		return NULL;
-	if (root->devfn != PCI_DEVFN(0, 0))
+
+	/* Intel Sky Lake-E host root ports can be on no zero slot */
+	if (root->devfn != PCI_DEVFN(0, 0) && !pci_is_root_port(root))
 		return NULL;
 
 	return root;
@@ -372,6 +403,7 @@ static bool __host_bridge_whitelist(struct pci_host_bridge *host,
 	for (entry = pci_p2pdma_whitelist; entry->vendor; entry++) {
 		if (vendor != entry->vendor || device != entry->device)
 			continue;
+
 		if (entry->flags & REQ_SAME_HOST_BRIDGE && !same_host_bridge)
 			return false;
 
-- 
2.17.1


  reply	other threads:[~2022-03-29 10:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29 10:43 [PATCH V3 0/1] Intel Sky Lake-E host root ports check Shlomo Pongratz
2022-03-29 10:43 ` Shlomo Pongratz [this message]
2022-03-29 23:42   ` [PATCH V3 1/1] " Jason Gunthorpe
2022-03-29 23:42   ` 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=20220329104321.4712-2-shlomop@pliops.com \
    --to=shlomopongratz@gmail.com \
    --cc=andrew.maier@eideticom.com \
    --cc=bhelgaas@google.com \
    --cc=jgg@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=shlomop@pliops.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;
as well as URLs for NNTP newsgroup(s).