PCI Probe Question

[Greg KH]

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?

> Scanning the pci_bus corresponding to a phb reveals 3  slots within 8
> devfn values.

What is a "phb"?

> Consider a phb with 3 slots at devfn values 58, 5a, and
> 5e.  A dlpar add of the first slot would call scan_slot() with 58, and
> scan_slot() adds redudant pci_dev's for the 5a and 5e to the devices
> list of the phb bus.

So you are trying to individually add the different pci devices within
the same device?  Hm, that's not very nice.  So you are not really
talking about a physical slot here, right?  You can divide up a physical
device among partitions?

Also, how could this be a multifunction device?

> For this case, we already know the devfn value we're interested in.  The
> device_node structure for the new slot has it.   If we call
> pci_scan_device() directly, we avoid the redundant devices problem.
>
> Thoughts?

If you convince me you really have to do this, why duplicate the
existing pci code in your driver?  How about just creating a
pci_scan_single_device() function for the pci core that does that logic
(and make pci_scan_slot() call it.)

That would make your code simpler, and we would not have to export
pci_fixup_device().

thanks,

greg k-h

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