linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	Pierre Morel <pmorel@linux.ibm.com>,
	linux-s390@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH v6 2/5] PCI: Split out next_ari_fn() from next_fn()
Date: Tue, 28 Jun 2022 16:30:57 +0200	[thread overview]
Message-ID: <20220628143100.3228092-3-schnelle@linux.ibm.com> (raw)
In-Reply-To: <20220628143100.3228092-1-schnelle@linux.ibm.com>

In commit b1bd58e448f2 ("PCI: Consolidate "next-function" functions")
the next_fn() function subsumed the traditional and ARI based next
function determination. This got rid of some needlessly complex function
pointer handling but also reduced the separation between these very
different methods of finding the next function. With the next_fn()
cleaned up a bit we can re-introduce this separation by moving out the
ARI handling while sticking with direct function calls.

Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/pci/probe.c | 30 +++++++++++++++++-------------
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b05d0ed83a24..2c737dce757e 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2579,26 +2579,30 @@ struct pci_dev *pci_scan_single_device(struct pci_bus *bus, int devfn)
 }
 EXPORT_SYMBOL(pci_scan_single_device);
 
-static int next_fn(struct pci_bus *bus, struct pci_dev *dev, int fn)
+static int next_ari_fn(struct pci_bus *bus, struct pci_dev *dev, int fn)
 {
 	int pos;
 	u16 cap = 0;
 	unsigned int next_fn;
 
-	if (pci_ari_enabled(bus)) {
-		if (!dev)
-			return -ENODEV;
-		pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ARI);
-		if (!pos)
-			return -ENODEV;
+	if (!dev)
+		return -ENODEV;
+	pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ARI);
+	if (!pos)
+		return -ENODEV;
+
+	pci_read_config_word(dev, pos + PCI_ARI_CAP, &cap);
+	next_fn = PCI_ARI_CAP_NFN(cap);
+	if (next_fn <= fn)
+		return -ENODEV;	/* protect against malformed list */
 
-		pci_read_config_word(dev, pos + PCI_ARI_CAP, &cap);
-		next_fn = PCI_ARI_CAP_NFN(cap);
-		if (next_fn <= fn)
-			return -ENODEV;	/* protect against malformed list */
+	return next_fn;
+}
 
-		return next_fn;
-	}
+static int next_fn(struct pci_bus *bus, struct pci_dev *dev, int fn)
+{
+	if (pci_ari_enabled(bus))
+		return next_ari_fn(bus, dev, fn);
 
 	if (fn >= 7)
 		return -ENODEV;
-- 
2.32.0


  parent reply	other threads:[~2022-06-28 14:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-28 14:30 [PATCH v6 0/5] PCI: Rework pci_scan_slot() and isolated PCI functions Niklas Schnelle
2022-06-28 14:30 ` [PATCH v6 1/5] PCI: Clean up pci_scan_slot() Niklas Schnelle
2022-06-30 12:40   ` Pierre Morel
2022-06-30 13:48     ` Niklas Schnelle
2022-06-30 14:50       ` Pierre Morel
2022-07-11  8:52         ` Niklas Schnelle
2022-06-28 14:30 ` Niklas Schnelle [this message]
2022-06-30 12:44   ` [PATCH v6 2/5] PCI: Split out next_ari_fn() from next_fn() Pierre Morel
2022-06-28 14:30 ` [PATCH v6 3/5] PCI: Move jailhouse's isolated function handling to pci_scan_slot() Niklas Schnelle
2022-06-30 12:47   ` Pierre Morel
2022-06-28 14:30 ` [PATCH v6 4/5] PCI: Extend isolated function probing to s390 Niklas Schnelle
2022-06-30 12:45   ` Pierre Morel
2022-07-01 14:42     ` Niklas Schnelle
2022-07-22 21:13   ` Bjorn Helgaas
2022-06-28 14:31 ` [PATCH v6 5/5] s390/pci: allow zPCI zbus without a function zero Niklas Schnelle
2022-06-30 12:53   ` Pierre Morel
2022-07-22 21:07 ` [PATCH v6 0/5] PCI: Rework pci_scan_slot() and isolated PCI functions 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=20220628143100.3228092-3-schnelle@linux.ibm.com \
    --to=schnelle@linux.ibm.com \
    --cc=bhelgaas@google.com \
    --cc=jan.kiszka@siemens.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=pmorel@linux.ibm.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).