PCI Error Recovery API Proposal. (WAS:: [PATCH/RFC] PCI Error Recovery)

Benjamin Herrenschmidt benh at kernel.crashing.org
Thu Mar 17 09:40:28 EST 2005


On Wed, 2005-03-16 at 08:43 -0800, Nguyen, Tom L wrote:
> On Tue, Mar 15, 2005 at 04:32:20PM, Benjamin Herrenschmidt wrote:
> > 
> > Ok, let's propose what i think is a proper API and simple enough on
> the
> > driver side, ...
> > That
> > should cover all the needs we discussed so far:
> > 
> > I think we need a callback in pci_driver, as I explained all along,
> with
> > a very simple semantic:
> > 
> >    int (*error_handler)(struct pci_dev *dev, int message);
> 
> This API does not support PCI Express AER precise errors. I prefer to
> have param int message being replaced by union error_src structure as
> below to include PCI Express AER precise errors.
> 
> union error_src {
> 	int message;	 		/* This for PCI Error */  
> 	struct {				/* This for PCI Express
> Precise Error */
> 		int type;   
> 		unsigned int flags;  
> 		unsigned int status; 
> 		struct header_log_regs *log; 
> 	}pcie_aer;
> };
> 
> Please let me know what you think?

Well, I did that on purpose to avoid messing with variable argument
types or complexify the arguments of the callback.

The way I see things, there are 2 ways the error details can be obtained
by the driver, one is returning those from the clear ... check stuff
described by Seto, and eventually a pci_get_last_error(pdev).

In both cases, it was suggested that the error is returned as an
"opaque" token with accessors to retreive the class of error and other
details. We have to deal with PCI legacy errors, PCIE-AER errors, plus
other kind of errors provided by various architectures/firmwares for
things like DMA errors, etc...

Now, if you feel that we should really pass the error token to the
callback, then maybe we should go with that, though it only have sense
in the initial callback, not the 3 other ones.

Ben.





More information about the Linuxppc64-dev mailing list