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

[M. Warner Losh]

In message: <1085391163.6814.6.camel at buffy.york.ac.uk>
            Gavin Atkinson <gavin.atkinson at ury.york.ac.uk> writes:
: On Mon, 2004-05-24 at 04:57, M. Warner Losh wrote:
: > In message: <20040523204728.U66525 at root.org>
: >             Nate Lawson <nate at root.org> writes:
: > : On Sat, 22 May 2004, M. Warner Losh wrote:
: > : > Well, we're talking exclusively about the vendor, device, subvendor,
: > : > subdevice, class, subclass and progif fields, which are obstensively
: > : > read-only.  However, the pci standards are self-contradictory.  The
: > : > main 2.2 one says they are read-only (without defining what that means
: > : > that I could find), yet the pciide spec says that progif had writable
: > : > bits...
: > : 
: > : I think the progif is the only one of that list that you need to restore,
: > : as per your reading of the specs.  Since the others are identifiers, they
: > : probably don't need to be restored.
: > 
: > Things are vague enough in the spec that this is totally
: > unsatisfying.  We're just guessing based on hunches, which I really
: > don't like, which is why I saved/restored everything.
: 
: Could we perhaps read them on restore and only write to them if
: necessary? That way we reduce the possibility of tickling bugs in the
: silicon by writing to read-only registers for chips that don't actually
: need it?

How do you know it is necessary?  No, this whole arm-chair generaling
thing is getting out of hand.  Either we do it or we don't.  If
someone can find *ANY* chip *AT*ALL* that has a problem, I'd be much
less grumpy about the shots from the sidelines, but there simply
aren't any.  Scott is worried that there might be based on his
experience, but he's unable to give an example.  I respect that
experience, but at the same time I'm not going to make this code
overly complex based purely on speculation of what might be a
problem.  If there are real problems, of course I'll deal.

Warner