In message: <20030815073150.2F96DA2@coconut.itojun.org>
            itojun@iijlab.net writes:
: >Module Name:	src
: >Committed By:	itojun
: >Date:		Fri Aug 15 07:17:22 UTC 2003
: >
: >Modified Files:
: >	src/sys/dev/pci: pci.c pci_quirks.c pcivar.h
: >
: >Log Message:
: >- check HDRTYPE early, and ignore if it is not supported (n > 2).
: >- defer access to interrupt configuration register, as its existence depends on
: >  HDRTYPE.


: >- add "skip particular funtion in multifunction device" functionality
: >  to quirk table.
: >- add GEODE/NS SC1100 quirk (now boots on soekris Net4801).

I suspect that this isn't really necessary.  FreeBSD doesn't have this
sort of quirk and we boot w/o trouble on the GEODE (after my patches)
:-).

: >
: >To generate a diff of this commit:
: >cvs rdiff -r1.80 -r1.81 src/sys/dev/pci/pci.c
: >cvs rdiff -r1.2 -r1.3 src/sys/dev/pci/pci_quirks.c
: >cvs rdiff -r1.58 -r1.59 src/sys/dev/pci/pcivar.h
: 
: 	my impression is that pci device probe needs a bit of surgery,
: 	as freebsd/openbsd works without quirk table for SC1100.  i'm not
: 	too familiar with pci configuration matters, so i would like someone
: 	to look at it (i'm happy to test it on my Net4801).

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.

The problem with the geode has to do with looking at the higher order
functions without properly checking.  The HDRTYPE register has 7 bits
for type, as well as one bit for 'this is a multi-function device'.
Prior to the fixes I put into FreeBSD, we'd check all the functions of
a device whenever this bit was 1, even for bogus header types.
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.  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.  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.

Maybe I missed some verbage in the standard that covers what
guarnatees future version of the standard will make about header types
other than 0, 1 and 2.  If so, I'd be very grateful for a gentle
pointer.

Warner