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 - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
