Re: [PATCH 15/22] ppc64: PCI Error Recovery: PPC64 core recovery routines

From: linas
Date: Thu Oct 13 2005 - 11:04:30 EST

On Wed, Oct 12, 2005 at 07:49:52PM +1000, Paul Mackerras was heard to remark:
> Linas writes:
> > + /* We might not have a pci device, if it was a config space read
> > + * that failed. Find the pci device now. */
> > + if (!dev) {
> > + while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
> > + if (pci_device_to_OF_node(dev) == event->dn)
> > + break;
> > + }
> > + }
> Couldn't we just use PCI_DN(event->dn)->pcidev here? Is there some
> reason why this would not work in some circumstances? It would be
> nice to avoid this linear search.

Funny tha you mention this, I just chopped this out yesterday; its cruft
left over from back-when.

The reason I chopped this out is due to a bug regarding the handling
of multi-function devices with the "new style" firmware interfaces.

With the new interfaces (i.e. those using ibm,get-config-addr-info),
every function on a pci card is labelled as a "partitionable endpoint".
By contrast, the current code assumes a "PE" is associated with a pci
card. As a result of this mismatch, the handling of multi-function
cards on systems with the new-style firmware is flubbed. (In particular,
the setup and use of config-space is muffed, resulting in crashes due
to access of i/o space that wasn't correctly set up).

I'm trying several different approaches to fixing this.

1) consolidating multiple pci functions (multiple PE's) into a single
"pci card" and treating the thing as a unit.

2) Treating each PE as completely distinct, and handling each distinctly.

Each approach seems to have problems. Cross my fingers, hope to have
something working later today; however, I'm irritated that I even need
to solve his problem.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at