PCI Probe Question

Greg KH gregkh at us.ibm.com
Wed Jan 28 07:39:39 EST 2004

On Tue, Jan 27, 2004 at 07:38:31PM +1100, Paul Mackerras wrote:
> Greg KH writes:
> > On Mon, Jan 26, 2004 at 07:11:49PM -0600, John Rose wrote:
> > > How feasible is the generic portion of the patch below?
> > >
> > > Currently, the PCI probe code exports pci_scan_slot() for use by hotplug
> > > (or dlpar) modules.  This turns out to be a problem, because
> > > pci_scan_slot() scans forward for 8 devfn values, starting at the one
> > > passed in.  We need pci_scan_device() to be available for module use.
> >
> > Wait, what's wrong with scanning for all 8 devfn values?  That's what we
> > have to do, right?
> Hmmm, I don't think you want to scan all 8 values if it is a
> single-function device, since it may well respond at all 8 function
> addresses, or even do weird things if you access func != 0.

Hence the following code in pci_scan_slot():
                 * If this is a single function device,
                 * don't scan past the first function.
                if (!dev->multifunction)

> Well, the thing is that we have PCI-PCI bridges which are
> multifunction devices, that is, you get 4 bridges in the one PCI
> device.  Each bridge typically has only one slot behind it, since the
> bridge is where the hotplugging is done.  And the hypervisor likes to
> be able to hand out each slot to a different partition.  So your
> partition might get to access function 2 of the PCI-PCI bridge device
> but not function 0.

Ick, ick, ick.  How do you all handle this in your boot up code then?

> Hope that makes it a little clearer.

Yes, thanks.  I think my proposed change will still work for you, right?


greg k-h

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/

More information about the Linuxppc64-dev mailing list