In message: <F5615EE8-CF65-11D7-A454-000A957650EC@wasabisystems.com>
            Jason Thorpe <thorpej@wasabisystems.com> writes:
: 
: On Friday, August 15, 2003, at 01:42  PM, Nathan J. Williams wrote:
: 
: > 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.
: 
: Specifically, HME devices.  The HME is coupled with their ebus bridge.  
: Ebus (ISA, really) is at function 0, HME is at function 1.  On HME 
: add-in cards, the Ebus function is disabled, which means the HME is the 
: only function that responds, and it responds at function 1.

Well, if you look at the add-in cards, the vendor-id returns 0xffff,
but all the other registers are live and responding.  Technically,
function 0 is responding and the 0xffff that's read back is coming
from the device not from some host bridge returning 0xffff in the
absense of the card doing that.  To cope, FreeBSD chose the header
type approach to eliminate the 'slot' and the vendor-id to elminiate
the 'functions.'

I don't think that 3.2.2.3.4 precludes this behavior, since the hme is
a mutlifunction device.  3.2.2.3.4 doesn't say that the vendor id must
be other than 0xffff.  It says is "must implement function 0", but it
is unclear what, exactly, that means.  Does having a vendor id if
0xffff mean, necessarily, that this function isn't implemented?

The HME device config dump looks like (this is faked up based on a
device that happens to be in my laptop):

0395ffff 22000006 06000000 00800000
fc100000 00000000 00000000 00000000 

notice how only the vendor is 0xffff.  So the device says it is
multifunction, but has a bogus vendor for function 0.  function 1
would look like (again, faked up from my laptop, this time an ethernet
chip):

813910ec 02900007 02000010 00804000
00001401 fc006800 00000000 00000000

and function 2 looks like:

ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff 

(these are dumps of the first 0x1f bytes of the config space)

Warner