Quoting "Brown, Len" <len.brown@xxxxxxxxx>:
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-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
