From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e2.ny.us.ibm.com", Issuer "Equifax" (verified OK)) by ozlabs.org (Postfix) with ESMTP id DE672DDE49 for ; Sat, 10 Feb 2007 02:20:31 +1100 (EST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l19FKLoM021585 for ; Fri, 9 Feb 2007 10:20:21 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l19FKLLu298750 for ; Fri, 9 Feb 2007 10:20:21 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l19FKKxZ017146 for ; Fri, 9 Feb 2007 10:20:20 -0500 Message-ID: <45CC9133.80006@linux.vnet.ibm.com> Date: Fri, 09 Feb 2007 09:20:19 -0600 From: Brian King MIME-Version: 1.0 To: Matthew Wilcox Subject: Re: [PATCH 1/3] pci: New PCI-E reset API References: <11703510202911-patch-mail.ibm.com> <20070201191235.GQ7585@parisc-linux.org> <45C26633.2010804@linux.vnet.ibm.com> In-Reply-To: <45C26633.2010804@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: James.Bottomley@steeleye.com, linux-scsi@vger.kernel.org, gregkh@suse.de, linuxppc-dev@ozlabs.org, paulus@samba.org, linux-pci@atrey.karlin.mff.cuni.cz Reply-To: brking@linux.vnet.ibm.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Matthew, Any further comments on this? Thanks, Brian Brian King wrote: > Matthew Wilcox wrote: >> On Thu, Feb 01, 2007 at 11:30:21AM -0600, Brian King wrote: >>> Adds a new API which can be used to issue various types >>> of PCI-E reset, including PCI-E warm reset and PCI-E hot reset. >>> This is needed for an ipr PCI-E adapter which does not properly >>> implement BIST. Running BIST on this adapter results in PCI-E >>> errors. The only reliable reset mechanism that exists on this >>> hardware is PCI Fundamental reset (warm reset). Since driving >>> this type of reset is architecture unique, this provides the >>> necessary hooks for architectures to add this support. >> A few points ... >> >> - When doing a warm reset, you reset the entire device not just the >> function (== pci_dev) that gets passed in. How happy are drivers for >> the other functions going to be about this? > > I guess I don't see how a warm reset could be issued to a single function > of a PCI device. I would argue that for a multi-function device, you would > have to use function level reset. > > >> - You've missed the requirement: >> >> "To allow components to perform internal initialization, system software >> must wait for at least 100 ms from the end of a Conventional Reset of one >> or more devices before it is permitted to issue Configuration Requests >> to those devices." >> >> To fix this, we need to call pci_block_user_cfg_access() before >> calling the pcibios function, then msleep(100) after calling it, then >> call pci_unblock_user_cfg_access(). > > What I've done is to provide a very low-level API that can be used to > accomplish this. In my implementation, the ipr driver is the one doing > all the required delays and calling pci_block_user_cfg_access, since it > already was doing that in order to run BIST on the adapter. > >> - There's no attempt to support either cold or function-level reset in >> this patch. > > Correct. I had no requirement to implement this. It can always be added > if there is a need. A function level reset can be performed by simply > writing a bit in config space, so *technically* we wouldn't need an > API to do that for us, but it could certainly be added here. > >> I suspect the Right Way of handling hot/warm/cold reset is going to be >> some kind of integration with error handling. This driver understands >> about slots being different from functions, and has the ability to >> notify drivers of other functions that a reset is happening. > > Perhaps. It would require a way for the adapter device driver to > indicate what type of reset(s) will work for a particular pci device. > It would also require a method for a device driver to invoke a reset, > which does not currently exist today. I think it would be the first > case of the device driver invoking pci error recovery, so I'm not sure > how difficult that would be to do with the current code. > > I actually thought this API might be used by PCI error recovery > code, since it may need to perform these sorts of functions. > > CC'ing Linas Vepstas since he wrote the powerpc pci recovery code. > > Brian > > -- Brian King eServer Storage I/O IBM Linux Technology Center