[PATCH] pci_dev to device_node fix

[Benjamin Herrenschmidt]

On Tue, 2004-03-16 at 09:00, Jake Moilanen wrote:
> > 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.

Well, as I told you, a PHB may ... or may not have a config space,
and that config space may or may not be at devfn 0. For example,
on Macs, the PHB usually has a non-0 devfn. (devnum 10 iirc)

> 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.

Not exactly. What I did on pmac was just to have each bridge visible,
just no PHB, there is abolutely no _need_ to have the PHB itself be
visible as a PCI device. I don't see why we would get the first
HT<->PCI bridge on devfn 0. They have their own devnums's (1 to 7
on pmacs).

> 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
--
Benjamin Herrenschmidt <benh at kernel.crashing.org>


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