PCI hotplug + EEH issues

[Anton Blanchard]

> Cool!  Do you have a patch?  I'd like to see this working :)

Yep, I'll clean it up and mail it out. I spoke to Greg KH and we
should be able to get a few things cleaned up (like moving to
driverfs which will allow us to have a hierarchy to represent pci-pci
bridges etc).

> I've hated this too.  There's got to be a better way to handle it, but
> I'm guessing is that you moved the logic into the Linux pci read funcs?
> I didn't want to special case that code, but I guess it doesn't need to
> be fast either.

Yeah since we only need it during pci probing, it doesnt have to go
real fast.

> I have a fix coded for bug 1197.  I'll attach the patch below.

Looks good, I'll put it into 2.5 tomorrow.

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

The config read/write now gets pci_bus *bus, int devfn, int where. This
means there is yet another mapping we need to take care of.

At the moment Im trying to take a step back and make sure we havent missed
an easier way of doing this. As I was working through it I realised we
have to do a bunch of config writes early to initialise the BARs on
some machines.

BTW I am suprised that POWER4 OF does not initialise the BARs.

> I've been meaning to try coding this to see how it goes but haven't
> found the time.  I'm also not sure what function we would lose nor am I
> sure how much smaller the code will get.  We'd of course be dependent on
> firmware getting it right, but so far I haven't found any counter
> examples -- even with unsupported adapters.  Thoughts?

Not sure, I havent thought about this idea much. I'll ask Paul tomorrow.

> Personally, I'd like to rework a lot about the way we do eeh.  For
> instance, I don't think we need to encode the mmio addresses since it
> doesn't appear we will get a faster way to query eeh status, nor do we
> get false positives anyway (at least from the little instrumenting code
> I have in there I haven't seen any).  Since false positives never/rarely
> happen we can code up handling of an eeh failure to be as slow as we
> want  And the RTAS call will guarantee slowness anyway :).

Im strongly in favour of this :)

Anton

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