Date: Fri, 21 May 2004 08:20:06 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: bms@spc.org Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/pci pci.c Message-ID: <20040521.082006.70223536.imp@bsdimp.com> In-Reply-To: <20040521134038.GE90068@empiric.dek.spc.org> References: <20040521.020412.118756775.imp@bsdimp.com> <40ADBC15.6040004@freebsd.org> <20040521134038.GE90068@empiric.dek.spc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040521134038.GE90068@empiric.dek.spc.org>
Bruce M Simpson <bms@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040521.082006.70223536.imp>