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

PCI rev 2.1 says (p. 88):

> Devices that respond to Type 0 configuration cycles are separated
> into two classes. The first class (single function device) is
> defined for backward compatibility, and only uses its IDSEL pin and
> AD[1::0] ("00") to determine whether or not to respond. The second
> class of device (multi-function device) understands the Function
> Number field and uses its IDSEL pin, AD[1::0] ("00") as well as the
> encoded value on AD[10::08] to determine whether or not to
> respond. The two classes are differentiated by an encoding in the
> Configuration Space header.
>
> Multi-function devices are required to do a full decode on
> AD[10::08], and only respond to the configuration cycle if they have
> implemented the Configuration Space registers for the selected
> function. They are also required to always implement function 0 in
> the device. Implementing other functions is optional and may be
> assigned in any order (i.e., a two-function device must respond to
> function 0, but can choose any of the other possible function
> numbers (1-7) for the second function).

i.e., a multifunction device:

* doesn't respond to configuration cycles for functions that it does
  not implement and,

* does respond to configuration cyeles for functions that it does
  implement.

PCI rev 2.2 has moved this text to a different location, there it's on
page 55, which also includes a complete description about when a
MF device should respond to a configuration transaction.  There's no
consideration given for which register is being accessed.


AFAIK there's no subset of configuration space registers that one is
allowed to implement on a per-function basis.


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

To quote PCI 2.1 page 202, which appears identical to PCI 2.2 page 190
(but i can't copy and paste form the latter easily:

> The predefined header portion of the Configuration Space is divided
> into two parts. The first 16 bytes are defined the same for all
> types of devices. The remaining bytes can have different layouts
> depending on the base function that the device supports. The Header
> Type field (located at offset 0Eh) defines what layout is provided.

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


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

See above, and note that:

(a) the field is in the part of the header that is "the same for all
types of devices," and

(b) there's no exception for header types other than 0, 1, or 2 in the
description of that field, PCI 2.1 page 204:

> Bit 7 in this register is used to identify a multi-function
> device. If the bit is 0, then the device is single function. If the
> bit is 1, then the device has multiple functions. Bits 6 through 0
> identify the layout of the second part of the predefined header.



> This is especially true for
> the 0x7f header type.  Since non-existant registers either read as all
> 'f' or cause an exception to happen, a bare minimum of filtering would
> be to completely ignore the slot if HDRTYPE is 0xff.

No, the correct amount of filtering, not counting workarounds for
broken devices -- of which this is one -- is what's implemented now
(or at least, "a while ago"), as far as I can read the spec.


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.



cgd