cvs commit: src/sys/dev/pci pci.c

[M. Warner Losh]

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
vendor/subvendor registers.

Warner