[PATCH] Support for PCI Express reset type in EEH

[Richard Lary]

Linas Vepstas <linasvepstas at gmail.com> wrote on 07/23/2009 07:44:33 AM:

> 2009/7/15 Mike Mason <mmlnx at us.ibm.com>:
> > By default, EEH does what's known as a "hot reset" during error
recovery of
> > a PCI Express device.  We've found a case where the device needs a
> > "fundamental reset" to recover properly.  The current PCI error
recovery and
> > EEH frameworks do not support this distinction.
> >
> > The attached patch (courtesy of Richard Lary) adds a bit field to
pci_dev
> > that indicates whether the device requires a fundamental reset during
error
> > recovery.  This bit can be checked by EEH to determine which reset type
is
> > required.
> >
> > This patch supersedes the previously submitted patch that implemented a
> > reset type callback.
> >
> > Please review and let me know of any concerns.
>
> I like this patch a *lot* better .. it is vastly simpler, more direct.
>
>
> > diff -uNrp a/include/linux/pci.h b/include/linux/pci.h
> > --- a/include/linux/pci.h       2009-07-13 14:25:37.000000000 -0700
> > +++ b/include/linux/pci.h       2009-07-15 10:25:37.000000000 -0700
> > @@ -273,6 +273,7 @@ struct pci_dev {
> >        unsigned int    ari_enabled:1;  /* ARI forwarding */
> >        unsigned int    is_managed:1;
> >        unsigned int    is_pcie:1;
> > +       unsigned int    fndmntl_rst_rqd:1; /* Dev requires fundamental
reset
> > */
> >        unsigned int    state_saved:1;
> >        unsigned int    is_physfn:1;
> >        unsigned int    is_virtfn:1;
>
> As Ben points out, the name is awkward.  How about needs_freset ?

I have no problem changing the name.

> Since this affects the entire pci subsystem, it should be documented
> properly.  The "pci error recovery" subsystem was designed to be
> usable in other architectures, and so the error recovery docs should
> take at least a paragraph to describe what this flag means, and when
> its supposed to be used.

I will take a stab at updating the docs and post here for comment.

> Providing the docs patch together with the pci.h patch *only* would
> probably simplify acceptance by the PCI community.
>
> --linas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090723/e8b11e3a/attachment-0001.htm>