PCI hotplug + EEH issues

[Benjamin Herrenschmidt]

>What's changed in 2.5 that has made this harder?  I agree that Linux
>fights with connecting arch data into the pci_dev when that arch data is
>needed for the config reads.  A more natural approach would be to
>abandon the pci driver bus walk and do our own by manufacturing the
>pci_dev/bus tree from the device tree.  In fact, we could create the
>entire pci_dev tree without doing a single config read!

Heh, that's would be interesting ;) The current pci driver bus
walk has some other side effects, at least on pmac, I don't know
if you are affected at all though. For example, it will temporarily
disable both IO and MEM forwarding on any PCI<->PCI bridge during the
scan of devices below that brige. On thing like pmac where the
interrupt controller may hang behind a PCI<->PCI bridge, that means
there is a small window of time where taking an interrupt will cause
a crash during the PCI bus scan. A similar issue happen with the
BAR scanning code, as in order to get the size, the kernel obviously
has to disable the decoding on that BAR by writing F's to it, then
get the size, then write back the original address.

So the above may end up beeing a problem, either if an interrupt
can happen touching a device that we have disabled because of one
of the above, or some other system service (HV ? RTAS ?).

Using only OF to populate the PCI tree would solve that problem,
though I would have to have PCI domains in the kernel to do that
properly on pmac. Unfortunately, it will also break older pmac's
where OF was so broken it wouldn't probe behind PCI<->PCI bridges
properly...

How close is the OF code between ppc32 and ppc64 ? would it make
some sense to clean up the internal representation of the device
tree (which is, at least on ppc32, still closely tied to what I
did with BootX) and move most of the OF interface code to some
common location we could share ?

Ben.


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