[PATCH 1/2] ppc64: Block config accesses during BIST #3

[Benjamin Herrenschmidt]

> 3) in pci_bus_to_host don't worry about searching for the hose, Ben and
>    I agree the pci code will always have bus->sysdata when calling
>    config routines.  (pci_bus sysdata is copied form parent, and to pci_dev)

Right, I have this patch I haven't sent yet ... Or maybe I did, bk is
dead today, I can't verify...

> 6) There is a hose per phb not per bus.   You are not including the bus
>    number in your block table.  With a EADS bridge, you are blocking the
>    other slots on the same phb.

Right. I need that for using the patch for pmac dead devices too.

> The real problem with number 6 is that (as mentioned in 5) the bus->sysdata
> is not always correct. 

It starts it's life beeing the PHB "parent" node. Then, it's updated to
be the actual P2P bridge node, or for a PHB, stays on the parent node.

> We currently use bus->sysdata 2 or 3 places in
> arch code, and then later explicitly copy the sysdata down from the phb
> (which I think is redundant with 2.6 pci code).   Actually we never use
> bus-sysdata except for host bridges (bus->self == NULL) but it is still
> copied to the pci devs on hotplug etc so it has to be compatable with 
> dev->sysdata aka a OF device node.  

With the simplified pci_bus_to_host(), we use bus->sysdata->phb, which
should be fine at all times.

> The cleanest is to add this to struct pci_bus but we could also use a word
> in struct device_node (call to_OF_node on bus->self, sysdata if NULL) if
> needed.   We could also search a list of (bus, mask) pairs or something, but
> we don't use many of the 256 possible buses on each PHB.

Maybe the best solution is to put an arch hook in there for the locking
instead of the generic code finally....

Ben.