[PATCH] pci_dev to device_node fix

[Jake Moilanen]

> Anyway, I still don't see the problem. The PHB proper is not part of
> the PCI bus, or if it is, it will respond to a devfn normally.

Let me see if I can reiterate the problem a little clearer.  On a normal
pSeries box, they will have a "real" PHB.  When trying to read the PHB's
config space, the actual RTAS call would use devfn 0 for the PHB.  The
config cycles are done from the PHB.  So the assumption that the PHB
will have devfn 0 holds.

On a JS20, the PHB is a U3.  This is not a real PHB in terms of how we
think of it.  The config cycles are done directly from the bridges.  So
when we use devfn 0, we really want the first bridge.

So what I am trying to say, is that it is possible/legal for a device to
have a devfn of 0.  We can not make the assumption that the PHB will be
the one using devfn 0.  Since there is this overlap, we need a way need
another variable to tell us if the device is a PHB or not to
differentiate.

Thanks,
Jake


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