pci <-> device node mapping

[Randy Swanberg]

Upstream bridges must know what range of bus ID's to claim and forward
downstream.  So reserving ranges at the upstream bridge allows subordinate
bridges to be dynamically added without forcing reconfiguration of the
upstream bridges.

Randy Swanberg

[ linas at austin.ibm.com wrote: ]

On Thu, Jun 19, 2003 at 01:18:38AM +1000, Anton Blanchard wrote:
>
> In theory you could hotplug in cards with pci-pci bridges, like the 4
> port pcnet32. So to make life easy they space them out a lot.

Ahh, OK, I had this crazy idea that ... never mind. Is there a technical
reason for assigned busid's in contiguous order for bridges on cards?
Why not just grab the 'next unused id' instead of reserving 32 per slot?

I have one RFE, and that is to make sure there is enough info there to
be able to correlate the firmware device location string w/ the pci
info.

The other day, I had a hard time matching the id that the LPAR HMC uses
(e.g. P2-I2/E1) with the actual hard drive on a scsi controller (e.g.
/dev/hdg). Much of the trouble came from trying to match the entries in
/proc/scsi to /proc/pci; I had to compare PCI busids, irq's and do some
clever guesswork to match one to the other. If there's a userland tool
that does this, we over here aren't aware of it ...

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