From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Date: Wed, 02 Mar 2005 22:41:43 +0000 Subject: Re: [PATCH/RFC] I/O-check interface for driver's error handling Message-Id: <1109803303.5611.108.camel@gaston> List-Id: References: <422428EC.3090905@jp.fujitsu.com> <42249A44.4020507@pobox.com> <20050302182205.GI1220@austin.ibm.com> In-Reply-To: <20050302182205.GI1220@austin.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Linas Vepstas Cc: Linus Torvalds , Jeff Garzik , Hidetoshi Seto , Linux Kernel list , linux-pci@atrey.karlin.mff.cuni.cz, linux-ia64@vger.kernel.org, "Luck, Tony" On Wed, 2005-03-02 at 12:22 -0600, Linas Vepstas wrote: > On Tue, Mar 01, 2005 at 08:49:45AM -0800, Linus Torvalds was heard to remark: > > > > The new API is what _allows_ a driver to care. It doesn't handle DMA, but > > I think that's because nobody knows how to handle it (ie it's probably > > hw-dependent and all existign implementations would thus be > > driver-specific anyway). > > ? > We could add a call > > int pci_was_there_an_error_during_dma (struct pci_dev); > > right? And it could return true/false, right? I can certainly > do that today with ppc64. I just can't tell you which dma triggered > the problem. That's ugly. I prefer asynchronous notification by far. > > And yes, CLEARLY drivers will have to do all the heavy lifting. > > well .. maybe. On ppc64, we have one hack-ish solution for > hotplug-capable but pci-error-unaware device drivers, and that > is to hot unplug the driver, clear the pci error condition, and > and replug the driver. Works great for ethernet; haven't tested > USB. > > I'm getting greif from the guys over here because my hack-ish code > is hackish, and isn't arch-generic, and Paul Mackerras doesn't like it, > which is why Benh is threatening to re-write it, and etc. ... > which is why Seto is involved, and we're having this conversation ... > > > --linas -- Benjamin Herrenschmidt