public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: "Nguyen, Tom L" <tom.l.nguyen@intel.com>,
	Paul Mackerras <paulus@samba.org>,
	Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>,
	Greg KH <greg@kroah.com>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	ak@muc.de, linuxppc64-dev <linuxppc64-dev@ozlabs.org>,
	linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: PCI Error Recovery API Proposal. (WAS:: [PATCH/RFC]PCIErrorRecovery)
Date: Sat, 19 Mar 2005 10:13:02 +1100	[thread overview]
Message-ID: <1111187582.1236.192.camel@gaston> (raw)
In-Reply-To: <20050318181005.GA30909@colo.lackof.org>

On Fri, 2005-03-18 at 11:10 -0700, Grant Grundler wrote:
> On Fri, Mar 18, 2005 at 09:24:02AM -0800, Nguyen, Tom L wrote:
> > >Likewise, with EEH the device driver could take recovery action on its
> > >own.  But we don't want to end up with multiple sets of recovery code
> > >in drivers, if possible.  Also we want the recovery code to be as
> > >simple as possible, otherwise driver authors will get it wrong.
> > 
> > Drivers own their devices register sets.  Therefore if there are any
> > vendor unique actions that can be taken by the driver to recovery we
> > expect the driver to do so.
> ...
> 
> All drivers also need to cleanup driver state if they can't
> simply recover (and restart pending IOs). ie they need to release
> DMA resources and return suitable errors for pending requests.

Additionally, in "real life", very few errors are cause by known errata.
If the drivers know about the errata, they usually already work around
them. Afaik, most of the errors are caused by transcient conditions on
the bus or the device, like a bit beeing flipped, or thermal
conditions... 

> To the driver writer, it's all "platform" code.
> Folks who maintain PCI (and other) services differentiate between
> "generic" and "arch/platform" specific. Think first like a driver
> writer and then worry about if/how that can be divided between platform
> generic and platform/arch specific code.
> 
> Even PCI-Express has *some* arch specific component. At a minimum each
> architecture has it's own chipset and firmware to deal with
> for PCI Express bus discovery and initialization. But driver writers
> don't have to worry about that and they shouldn't for error
> recovery either.

Exactly. A given platform could use Intel's code as-is, or may choose to
do things differently while still showing the same interface to drivers.
Eventually we may end up adding platform hooks to the generic PCIE code
like we have in the PCI code if some platforms require them.




  reply	other threads:[~2005-03-18 23:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-18 17:24 PCI Error Recovery API Proposal. (WAS:: [PATCH/RFC]PCIErrorRecovery) Nguyen, Tom L
2005-03-18 18:10 ` Grant Grundler
2005-03-18 23:13   ` Benjamin Herrenschmidt [this message]
2005-03-19  0:35     ` Real-life pci errors (Was: " Linas Vepstas
2005-03-19  1:24       ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2005-03-18 19:29 Nguyen, Tom L
2005-03-18 18:33 Nguyen, Tom L
2005-03-18 17:17 Nguyen, Tom L
2005-03-17 18:53 PCI Error Recovery API Proposal. (WAS:: [PATCH/RFC] PCIErrorRecovery) Nguyen, Tom L
2005-03-18  2:43 ` Benjamin Herrenschmidt
2005-03-18  4:01 ` Paul Mackerras
2005-03-17 18:33 Nguyen, Tom L
2005-03-17 22:57 ` Benjamin Herrenschmidt
2005-03-18  3:22 ` Paul Mackerras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1111187582.1236.192.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=ak@muc.de \
    --cc=greg@kroah.com \
    --cc=grundler@parisc-linux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=linuxppc64-dev@ozlabs.org \
    --cc=paulus@samba.org \
    --cc=seto.hidetoshi@jp.fujitsu.com \
    --cc=tom.l.nguyen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox