cvs commit: src/sys/dev/pci pci.c
M. Warner Losh
imp at bsdimp.com
Fri May 21 07:22:01 PDT 2004
In message: <20040521134038.GE90068 at empiric.dek.spc.org>
Bruce M Simpson <bms at spc.org> writes:
: On Fri, May 21, 2004 at 02:21:41AM -0600, Scott Long wrote:
: > Well, the 8.3.3 paragraph only specifically mentions the command
: > register and the BARs. I'm just worried that by touching stuff outside
: > of this range that you open up the risk of tickling latent buggy
: > silicon. Exception cases like the ATA hardware doing magic things with
: > the progif register should be left up to the ATA driver. It's exactly
: > those kinds of bent-rules that makes me nervous =-)
This isn't ata specific. That was just the example that made me think
of updating the cache and saving/restoring those registers. I can
understand that it makes you nervous, but I don't think we'll find any
silicon that's that brain damaged given that the standard specifically
says that writes to read-only registered must succeed (although it
says so in a round about way).
Also, it specifically said 'but not limited to' which implies more
needs to be done.
: Maybe this behaviour could be enabled or disabled with an instance variable?
: I can think of one example of hardware which might need this. I owned an
: IBM ThinkPad T22 with an xl(4) NIC for about a year, and one of the things
: which annoyed me about suspend/resume was the tendency for it to lose its
: PCI configuration.
No. That's even worse. The code is going to be uniform accross all
devices until someone can produce a legitimate example of a real
device that breaks and that we care about supporting.
The linux code and the Windows code I'm told, behaves in a similar
manner to what we're doing. All I added was a few more registers that
we save/restore that are defined in the spec.
Having said all that, I'm still contemplating not doing the
More information about the cvs-src