PCI Error Recovery API Proposal (updated)

Benjamin Herrenschmidt benh at kernel.crashing.org
Sat Apr 9 09:52:45 EST 2005


On Fri, 2005-04-08 at 10:18 -0700, long wrote:
> On Thursday, April 07, 2005 3:30 PM Benjamin Herrenschmidt wrote:
> >Hrm... I don't think the port driver should enter that picture at all.
> >As far as I'm concerned, the port driver is part of the implementation.
> >The defined API really only concerns the downstream device. That is,the
> >AER can use whatever private PCI-Express API you have to trigger the
> >link reset. I think that's why we have some misunderstanding about the
> >definition of this callback.
> 
> The port driver is a PCI device driver, which supports PCI Express
> features. Each feature has its own service driver, which is not based on
> PCI Driver Model. These service drivers should be informed of what is
> going on in the hierarchy where fatal error occurs as well as what error
> recovery action takes place. Therefore, in my view, the port driver
> should be part of error recovery process, which is based on a native SW
> solution, not a FW policy. I hope you understand my concerns and rewrite
> the definition of this callback usage.

Well, while I agree that the port driver is part of the process, it
doesn't have to adhere to the defined API as far as reset of it's
downlink link is concerned. Please understand that this API is aimed
toward "generic" facility for normal device drivers. The port driver is
a specific of the PCI Express implementation, and while it takes an
active role in the process, the generic API shouldn't be modified to
take into account specific needs of a port driver. Instead, the AER
should have it's own private API to the port driver to implement the
recovery process.
 
> >In my view of things, it's just a call to the downstream device after
> >the link have been reset, and thus is very similar to 2).

Ok, if the link "above" the port driver has been reset, then yes, the
port driver in this context can act as a normal driver. In the case of
the link down from the port driver, it is not.

> The difference in their usages is the reason why I've kept requesting
> you to have API 3) for PCI Express.
> 
> Thanks,
> Long
-- 
Benjamin Herrenschmidt <benh at kernel.crashing.org>




More information about the Linuxppc64-dev mailing list