From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linas Vepstas Date: Wed, 02 Mar 2005 18:22:05 +0000 Subject: Re: [PATCH/RFC] I/O-check interface for driver's error handling Message-Id: <20050302182205.GI1220@austin.ibm.com> List-Id: References: <422428EC.3090905@jp.fujitsu.com> <42249A44.4020507@pobox.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Linus Torvalds Cc: Jeff Garzik , Hidetoshi Seto , Linux Kernel list , linux-pci@atrey.karlin.mff.cuni.cz, linux-ia64@vger.kernel.org, Benjamin Herrenschmidt , "Luck, Tony" 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. > 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