Messages in this thread | | | Date | Tue, 25 Apr 2006 19:59:43 -0400 | From | abelay@MIT ... | Subject | RE: [PATCH] reverse pci config space restore order |
| |
Quoting "Brown, Len" <len.brown@intel.com>:
> >> On Tue, 2006-04-25 at 11:48 +0100, Matthew Garrett wrote: >>> On Tue, Apr 25, 2006 at 02:50:57PM +0800, Yu, Luming wrote: >>> >>> > - for (i = 0; i < 16; i++) >>> > + for (i = 15; i >= 0 ; i--) >>> >>> We certainly need to do /something/ here, but I'm not sure >>> this is it. >>> Adam Belay has code to limit PCI state restoration to the >>> PCI-specified >>> registers, with the idea being that individual drivers fix things up >>> properly. While this has the obvious drawback that almost every PCI >>> driver in the tree would then need fixing up, it's also probably the >>> right thing. >> >> it has a second drawback: it assumes all devices HAVE a driver, which >> isn't normally the case... > > Adam mentioned earlier, and I agree, that it is probably a bad > idea for this code to blindly scribble on the BIST field at i=3. > Probably we should clear that field before restoring it. > > Re: this patch > I think that this patch is likely a positive forward step. > It seems logical to restore the BARs before the CMD/STATUS in general, > nothing specific to the ICH here. > > But yes, this is a helper routine and devices where it hurts > instead of helps should have their own routine. Complex devices > need to handle the device-specific config space state above these > 1st 16 locations anyway.
Right, and because we only restore the first 0x40 or so registers (they're all standard), I don't think implementing pci_save/restore_state() properly is going to break much at all. I'm planning to merge these changes with -mm, so hopefully it won't be difficult to tell. :)
Re: devices without drivers
We can certainly call a generic save and restore function when there isn't a driver available, but beyond handling standard registers mentioned in the spec, if important hardware context is lost there's really no way around it.
-Adam
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |