PCI Error Recovery API Proposal (updated)

[long]

On Friday, April 08, 2005 4:53 PM Benjamin Herrenschmidt wrote:
> > 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.

Consider a system without FW support for link/bus reset and is using a
full native OS solution.  In this situation a port bus driver or a PCI
bridge driver would need to execute the bus/link reset when we get an
error from a device.  Therefore an interface is required to request a
bus/link reset from a bus driver.   Specifically, in PCI Express the
port bus driver owns execution of a downstream link reset for a link
attached to a root port or downstream switch port.  The port bus driver
can perform a link reset by setting the SBR bit in the configuration
registers.  This results in a down stream hot-reset.

Is there some method the current interface supplies to support a full
native OS solution that I am not seeing?  The error handling interfaces,
in my view, should be flexible enough to support a full native OS
solution with no FW assistance.
 
Thanks,
Long