public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Shaohua Li <shaohua.li@intel.com>
Cc: Ashok Raj <ashok.raj@intel.com>,
	linux-kernel@vger.kernel.org, akpm@osdl.org, ak@suse.de,
	muli@il.ibm.com, asit.k.mallick@intel.com,
	suresh.b.siddha@intel.com, anil.s.keshavamurthy@intel.com,
	arjan@linux.intel.com
Subject: Re: [patch 2/8] [Intel IOMMU] Some generic search functions required to lookup device relationships.
Date: Tue, 10 Apr 2007 06:03:34 -0700	[thread overview]
Message-ID: <20070410130334.GA9682@suse.de> (raw)
In-Reply-To: <1176192698.6781.13.camel@sli10-conroe.sh.intel.com>

On Tue, Apr 10, 2007 at 04:11:38PM +0800, Shaohua Li wrote:
> On Mon, 2007-04-09 at 20:46 -0700, Greg KH wrote:
> > On Mon, Apr 09, 2007 at 02:55:54PM -0700, Ashok Raj wrote:
> > > +/*
> > > + * find the upstream PCIE-to-PCI bridge of a PCI device
> > > + * if the device is PCIE, return NULL
> > > + * if the device isn't connected to a PCIE bridge (that is its parent is a
> > > + * legacy PCI bridge and the bridge is directly connected to bus 0), return its
> > > + * parent
> > > + */
> > > +struct pci_dev *
> > > +pci_find_upstream_pcie_bridge(struct pci_dev *pdev)
> > > +{
> > > +	struct pci_dev *tmp = NULL;
> > > +
> > > +	if (pdev->is_pcie)
> > > +		return NULL;
> > > +	while (1) {
> > > +		if (!pdev->bus->self)
> > > +			break;
> > > +		pdev = pdev->bus->self;
> > > +		/* a p2p bridge */
> > > +		if (!pdev->is_pcie) {
> > > +			tmp = pdev;
> > > +			continue;
> > > +		}
> > > +		/* PCI device should connect to a PCIE bridge */
> > > +		BUG_ON(pdev->pcie_type != PCI_EXP_TYPE_PCI_BRIDGE);
> > > +		return pdev;
> > > +	}
> > > +
> > > +	return tmp;
> > > +}
> > 
> > No locking while you walk up the bus list?
> hmm, iommu driver didn't support pci hotplug in current stage. But we
> can add lock here.

Please do, as PCI-E hotplug is much more common than PCI hotplug these
days (think ExpressCard in millions of laptops...)

> > > --- linux-2.6.21-rc5.orig/include/linux/pci.h	2007-04-03 04:30:51.000000000 -0700
> > > +++ linux-2.6.21-rc5/include/linux/pci.h	2007-04-03 06:58:58.000000000 -0700
> > > @@ -126,6 +126,7 @@
> > >  	unsigned short	subsystem_device;
> > >  	unsigned int	class;		/* 3 bytes: (base,sub,prog-if) */
> > >  	u8		hdr_type;	/* PCI header type (`multi' flag masked out) */
> > > +	u8		pcie_type;	/* PCI-E device/port type */
> > >  	u8		rom_base_reg;	/* which config register controls the ROM */
> > >  	u8		pin;  		/* which interrupt pin this device uses */
> > >  
> > > @@ -168,6 +169,7 @@
> > >  	unsigned int 	msi_enabled:1;
> > >  	unsigned int	msix_enabled:1;
> > >  	unsigned int	is_managed:1;
> > > +	unsigned int	is_pcie:1;
> > 
> > Do you really need both fields?  Wouldn't just the pcie_type one work
> > (with some NOT_PCIE type being set for it if it isn't I suppose.)
> There are some encodings are reserved for future. Just don't want to use
> reserved bits, as we don't know which one is proper for NOT_PCIE.

What are the current encodings?  I don't have my copy of the pci spec
availble at the moment...

thanks,

greg k-h

  reply	other threads:[~2007-04-10 13:09 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-09 21:55 [patch 0/8] [Intel IOMMU] Support for Intel Virtualization Technology for Directed I/O Ashok Raj
2007-04-09 21:55 ` [patch 1/8] [Intel IOMMU] ACPI support " Ashok Raj
2007-04-10  3:39   ` Len Brown
2007-04-10 16:26     ` Ashok Raj
2007-04-09 21:55 ` [patch 2/8] [Intel IOMMU] Some generic search functions required to lookup device relationships Ashok Raj
2007-04-10  3:46   ` Greg KH
2007-04-10  8:11     ` Shaohua Li
2007-04-10 13:03       ` Greg KH [this message]
2007-04-11  1:40         ` Shaohua Li
2007-04-11  4:36           ` Greg KH
2007-04-11  6:10         ` Shaohua Li
2007-04-09 21:55 ` [patch 3/8] [Intel IOMMU] Generic hardware support for Intel IOMMU Ashok Raj
2007-04-09 21:55 ` [patch 4/8] [Intel IOMMU] Supporting Zero Length Reads in " Ashok Raj
2007-04-09 21:55 ` [patch 5/8] [Intel IOMMU] Graphics driver workarounds to provide unity map Ashok Raj
2007-04-10  8:33   ` Christoph Hellwig
2007-04-10  9:07     ` David Miller
2007-04-10  9:12       ` Andi Kleen
2007-04-11  2:40         ` Wang Zhenyu
2007-04-10 16:29       ` Arjan van de Ven
2007-04-09 21:55 ` [patch 6/8] [Intel IOMMU] Doc updates for Intel Virtualization Technology for Directed I/O Ashok Raj
2007-04-09 21:55 ` [patch 7/8] [Intel IOMMU] Support for legacy ISA devices Ashok Raj
2007-04-09 21:56 ` [patch 8/8] [Intel IOMMU] Preserve some Virtual Address when devices cannot address entire range Ashok Raj
2007-04-10  7:49 ` [patch 0/8] [Intel IOMMU] Support for Intel Virtualization Technology for Directed I/O Andi Kleen
2007-04-10  7:57   ` Shaohua Li
2007-04-10  8:09     ` Muli Ben-Yehuda
2007-04-10  8:20       ` Shaohua Li
2007-04-10 16:31   ` Ashok Raj
2007-04-10  8:21 ` Jeff Garzik
2007-04-10  8:27   ` Shaohua Li
2007-04-10  8:34     ` Jeff Garzik
2007-04-10 16:43       ` Ashok Raj

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=20070410130334.GA9682@suse.de \
    --to=gregkh@suse.de \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=arjan@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=asit.k.mallick@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=muli@il.ibm.com \
    --cc=shaohua.li@intel.com \
    --cc=suresh.b.siddha@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