In message: <yov5n0ea7mjd.fsf@ldt-sj3-010.sj.broadcom.com>
            cgd@broadcom.com writes:
: At Fri, 15 Aug 2003 18:13:39 +0000 (UTC), "M. Warner Losh" wrote:
: > The problem, for those that are new to the discussion, is that reading
: > anything but the header type for devices that do not exist is ill
: > defined.  For devices that are really there, one can rely on certain
: > registers being implemented for all devices.  However, the standard is
: > less clear on what happens when on access registers on devices that
: > aren't there.
: 
: I'd really like a chapter and verse quote that "reading anything but
: the header type ... is ill-defined."

I couldn't find anything either, but when the reports came it, this
was asserted.  I could just find the positive statements.

: > However, the standard seems to say (I thought I'd found it before, but
: > can't find it now) that only the 7-bits that define the header type
: > are valid for all header types.
: 
: C&V please.

It turns out this was in the PCI Bible, not the standard.  It
recommended that software should ignore devices that whose header
types weren't understood.

: I.e., the first 16 bytes of header are the same for *all* types of devices.

Except for devices that aren't there.

: > The standard only defines header type
: > 0, 1, and 2.  If the header type isn't one of those, you can't count
: > on the high bit meaning multifunction.
: 
: C&V please.

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.

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

Looking at the current NetBSD code (before itojun's changes), I can't
see why it would hang on the geode.  It hangs (bogusly imho) only when
you read config registers for devices that don't exist with a function
number > 1.  NetBSD's code looks like it should cope completely with
this (there are 3 or 4 places that scan the pci bus and they all do it
the same for x86).

Looking at itojun's code via cvsweb now shows that it goes far beyond
the filter that FreeBSD implements.

Warner