"M. Warner Losh" <imp@bsdimp.com> writes:

> Back to this section, you'll notice it doesn't unambiguously say that
> 'if vendorid == 0xffff for function 0, then there are no other
> functions'  It just says that vendorid == 0xffff is invalid and that
> reads from devices that aren't there must return 0xffff.  A subtle
> difference, but one that has been observed in the wild at least once.

Section 3.2.2.3.4 requires that a single-function device use function
0 (either the modern way, by explicitly decoding function 0, or the
legacy way, by not decoding the function bits at all), and that a
multifunction device must respond on function 0 and some other subset
of functions. A device that responds on, say, 1, 2, and 3 but not 0,
is broken. You seem to say that some Sun devices are broken that way,
which sucks.

> My copy of the standard says, at the end of 6.1, that 'If a device
> supports *the function* that the register is concerned with, the
> device must implement the defined location.' (emphasis mine).  It
> isn't 100% clear that
> 	if function 0's vendor id is 0xfffff, then none of functions
> 	are valid.

Again, 3.2.2.3.4 says this.

> Before I made my change, FreeBSD would read all functions' Vendor ID.
> After my change, it will only read things from function 0 unless we
> know the Multifunction bit is legitimately set.  The act of reading >
> fucntion 0 for non-existant devices is what triggers the GEODE bug.

We're about to be in violent agreement, I think. Both NetBSD and
FreeBSD are doing reasonable things, and the only issue is how to
handle this bit of buggy hardware. Itojun's quirk seems okay for that.

        - Nathan