In message: <yov5bruq7h3s.fsf@ldt-sj3-010.sj.broadcom.com>
            cgd@broadcom.com writes:
: At Fri, 15 Aug 2003 14:46:12 -0600 (MDT), M. Warner Losh wrote:
: > Only types 0, 1 and 2 are defined, but except for section 6.1 that
: > says "the host bridge is required to return 0xff for reads to
: > non-existant devices" you are correct.  There are two ways of dealing
: > with this.  One is to accept only those things you know are defined.
: > The other is to reject those things you know to be undefined.  When
: > the register is 0xff, it is likely the result of a read on a device
: > that isn't there.  Hmmmm, come to think of it, you have the same
: > problem here as you do with the vendor string.  One could, in theory,
: > define a header type of 0x7f (it is reserved in the standard, not
: > illegal) for a multifunction device.
: 
: uh, puzzled.
: 
: "vendor string"?

bad habit of too many years talking about pccard cis strings :-(.

: The PCI spec does explicitly state that vendor ID
: 0xffff is "an invalid vendor ID."  (PCI 2.1 page 188.)  Note that
: vendors *can* use device ID of 0 or 0xffff, if they so choose.

Sun implements function 0, but chooses to return 0xffff as the vendor
id.  The config cycles happen on the bus.  Other registers are
returned (I've given a mocked up example in another email message).

: As you note, those, header type 0x7f is *not* Illegal.

Yes.  It is just not defined today.

: > : Maybe there's a better (more general) quirk to be had based on your
: > : experience.  However, if you really think this is a case of anything
: > : other than a buggy device, please quote C&V that allows the behaviour
: > : that you describe.
: > 
: > In another post I pointed out that the standard doesn't say that if
: > you read back 0xffff on function 0, that there won't be valid one on
: > function 1.
: 
: Uh, the standard *does* indicate that if it is a multi-function
: device, function 0 *must* be implemented.  (previously quoted.)

Yes.  Sun does that, but returns 0xffff for the vendor id for function
0, but all the other config registers return non-ff values.  It
actually returns 0xffff and doesn't ignore config cycles on function
0.

: If you read that back as vendor ID, no, you *cannot* have a function 1.

Where does the standard state that, exactly?  I'll grant that the sun
hme device is an extreme edge case, but it appears to comply with the
standard, at least 'a reading of the standard might imply that it
complies.'  The standard doesn't say the device can't have a vendor-id
of 0xffff, just that that vendor id will not be assigned and can be
considered to be invalid.  But what "invalid" means is only by
implication, not explicitly stated.  Does it mean 'the whole device is
not there?' or 'this function is not there?'

Here's the quoted areas:

6.2.1 says:
Vendor ID: ... Valid vendor identifiers are allocated by the PCI SIG
to ensure uniqueness.  0FFFFh is an invalid value for the Vendor
ID.[1]

section 6.1 says:
System software may need to scan the bus to determine what devices are
actually present.  To do this, the configuration software must read
the Vendor ID in each possible PCI "slot."  The host bus to PCI must
unambiguously report attempts to read the Vendor ID of non-existant
devices.  Since 0FFFFh is an invalid Vendor ID, it is adequate for the
host bus to PCI bridge to return a value of all 1's on read access to
Configuration Space of non-existant devices.[2]

[1] there's no implication as to what invalid means for the bigger
picture in this section.

[2] notice that this says 'invalid devices will return 0xffff' and not
the contrapositive that 'no device may return 0xffff' except by
implication.

I'll be the first to admit that this is a stretch, and not according
to common practice of other devices.  I'll also admit that my earlier
statements were very imprecise and some of them weren't fully
supported by the standard.  I'd also agree that this sort of silliness
should not be allowed, but there's wiggle room in the standard :-(.
It is against the intent of the standard, I'm sure.

Warner