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)
break;
> 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?
thanks,
greg k-h
** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc64-dev
mailing list