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

[linas]

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.

--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/