mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Matthew Wilcox <matthew@wil.cx>,
	Matt Domsch <Matt_Domsch@dell.com>,
	lkml <linux-kernel@vger.kernel.org>,
	gregkh@suse.de, linux-pci@atrey.karlin.mff.cuni.cz
Subject: [PATCH] PCI: limit pci_get_bus_and_slot to domain 0
Date: Thu, 28 Jun 2007 16:04:21 -0700	[thread overview]
Message-ID: <20070628160421.141c4178.randy.dunlap@oracle.com> (raw)
In-Reply-To: <4682AD9B.9060105@zytor.com>

On Wed, 27 Jun 2007 14:34:03 -0400 H. Peter Anvin wrote:

> Alan Cox wrote:
> > On Wed, 27 Jun 2007 10:54:30 -0600
> > Matthew Wilcox <matthew@wil.cx> wrote:
> > 
> >> On Wed, Jun 27, 2007 at 12:41:41PM -0400, H. Peter Anvin wrote:
> >>> Note that EDD has no way of referencing anything but the zero domain 
> >>> (which is presumably the one which is addressed by I/O ports CF8/CFC on 
> >>> the BSP.)  So in this particular case I would say pci_get_bus_and_slot() 
> >>> is fine.
> >> Except that you're not guaranteed to get the bus that's in domain zero.
> > 
> > Which is trivial to fix
> 
> Yes, and that's probably the only sane definition of that API.

Is this what you mean?
---

From: Randy Dunlap <randy.dunlap@oracle.com>

Limit pci_get_bus_and_slot() to domain (segment) 0 since domain is not
specified in the function call and defaulting to domain 0 is the only
reasonable thing to do (rather than returning a device from some other
unknown domain).

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 drivers/pci/search.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- linux-2622-rc6mm1.orig/drivers/pci/search.c
+++ linux-2622-rc6mm1/drivers/pci/search.c
@@ -173,12 +173,14 @@ struct pci_dev * pci_get_slot(struct pci
 }
 
 /**
- * pci_get_bus_and_slot - locate PCI device from a given PCI slot
+ * pci_get_bus_and_slot - locate PCI device from a given PCI bus & slot
  * @bus: number of PCI bus on which desired PCI device resides
  * @devfn: encodes number of PCI slot in which the desired PCI
  * device resides and the logical device number within that slot
  * in case of multi-function devices.
  *
+ * Note: the bus/slot search is limited to PCI domain (segment) 0.
+ *
  * Given a PCI bus and slot/function number, the desired PCI device
  * is located in system global list of PCI devices.  If the device
  * is found, a pointer to its data structure is returned.  If no
@@ -191,7 +193,8 @@ struct pci_dev * pci_get_bus_and_slot(un
 	struct pci_dev *dev = NULL;
 
 	while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
-		if (dev->bus->number == bus && dev->devfn == devfn)
+		if (pci_domain_nr(dev->bus) == 0 &&
+		   (dev->bus->number == bus && dev->devfn == devfn))
 			return dev;
 	}
 	return NULL;

  reply	other threads:[~2007-06-28 23:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-26 20:26 EDD build error Randy Dunlap
2007-06-26 22:16 ` Torsten Duwe
2007-06-26 22:33   ` Randy Dunlap
2007-06-26 22:44     ` Torsten Duwe
2007-06-26 23:14       ` Randy Dunlap
     [not found] ` <20070627024505.GA30197@humbolt.us.dell.com>
2007-06-27 11:30   ` pci.h stubs (was: EDD build error) Matthew Wilcox
2007-06-27 13:55     ` Alan Cox
2007-06-27 14:03       ` Matthew Wilcox
2007-06-27 14:32         ` Alan Cox
2007-06-27 14:32           ` Matthew Wilcox
2007-06-27 15:07             ` Alan Cox
2007-06-27 16:41       ` pci.h stubs H. Peter Anvin
2007-06-27 16:54         ` Matthew Wilcox
2007-06-27 17:25           ` Alan Cox
2007-06-27 18:34             ` H. Peter Anvin
2007-06-28 23:04               ` Randy Dunlap [this message]
2007-06-28 23:48                 ` [PATCH] PCI: limit pci_get_bus_and_slot to domain 0 H. Peter Anvin
2007-06-28 23:25   ` [PATCH] pci.h stubs (for EDD build error) Randy Dunlap

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=20070628160421.141c4178.randy.dunlap@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=Matt_Domsch@dell.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=matthew@wil.cx \
    /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

Powered by JetHome