pci <-> device node mapping

[linas at austin.ibm.com]

Hi Anton,

On Thu, Jun 19, 2003 at 09:23:05PM +1000, Anton Blanchard wrote:
>
> > 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 ...
>
> Im acutely aware of it, I spent ages trying to bring a large machine up
> with some broken SCSI adapters, disks and network cards. Im half
> considering stashing the OF name into pci_dev->slot_name (as well

That would be good.  You don't, perchance, have a patch that already
supplies this?

Linda Xie over here is doing some device driver work, where she gets
an RTAS event with a firmware location code in it.  Based on the location
code, she wants to be able to find the corresponding pci_dev structure.
What's the best way to do this?

I didn't quite understand the overall design she's working with.
She wants to do the mapping in the kernel, although its conceivable
the best solution might be to have some userspace deamon catch the
RTAS event, convert it to a domain/bus and feed it back to her driver.
I dunno, this is unfamiliar ground to me.

Without your patch, the only solution I know of is to do a string
compare to pci_dev->dev.name and hope to find the first N characters
match. Which struct me as a not very pretty way of doing thngs,
especially is someone ever mucks with dev.name.

--linas

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