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"?  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.

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


> : 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.)

"Read back 0xffff on function 0" from what?

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



(I don't know what Itojun implemented, but was responding to your
suggestion that a more general filter was desirable.  If what he did
was a device-specific quirk, well, maybe it could be better but it
wouldn't harm other devices at least.  whereas, a more general check
might.)


cgd