>From the specification (2.1):

6.2.4.	Miscellaneous Functions
[...]
	Subsystem Vendor ID and Subsystem ID

	These registers are used to uniquely identify the add-in board
	or subsystem where the PCI device resides. They provide a
	mechanism for add-in card vendors to distinguish their cards

(This hints somewhat at 'branding', BTW.)

	from one another even though the cards may have the same PCI
	controller on them (and, therefore, the same Vendor ID and
	Device ID). Implementation of these registers is optional
	and an all zero value indicates that the device does not
	support subsystem identification. Subsystem Vendor IDs can be
	obtained from the PCI SIG and are used to identify the vendor
	of the add-in board or subsystem. Values for Subsystem ID are
	vendor specific. Values in these registers are programmed
	during the manufacturing process or loaded from external logic
	(e.g., strapping options, serial ROMs, etc), prior to the
	system BIOS or any system software accessing the PCI
	Configuration Space. Devices loading these values from
	external logic are responsible for guaranteeing the data is
	valid before allowing reads to these registers to complete.
	This can be done by responding to any accesses with a Retry
	until the data is valid.

On Tue, Oct 06, 1998 at 11:50:34AM -0700, Chris G. Demetriou wrote:
> >   From reading pcivar.h and pcireg.h, it appears that we don't even collect
> > that info.
> >   I expect that we should. Comments?
> 
> Perhaps.  I've yet to see consistent enough usage and application of
> them to decide how to represent them.
> 
> Specifically, the things i'm wondering are:
> 
> (1) what is the namespace for subsystem vendor IDs?  (I've heard "same
> as vendor IDs," but haven't had C&V quoted at me, so i'm
> skeptical. 8-)

'Subsystem Vendor IDs can be obtained from the PCI SIG [...]'

Whatever that means.

> (2) what is the namespace for subsystem IDs?  I.e. is it per subsystem
> vendor, or per prod/vendor/subsystem_vendor?

'Values for Subsystem ID are vendor specific.'

Whatever that means.

I have two devices with non-zero sub-ID fields.

			vendor	product	subsys	subvendor
Matrox Millenium G200	0x102b	0x0521	0xff03	0x102b
Ensoniq AudioPCI	0x1274	0x5000	0x4c4c	0x4942

Matrox seems to support (1) above. They use the subsystem ID
for distinguishing between their numerous different cards
using the G200 core (same product ID).

0x4942 is not in the PCI SIG lists, and 0x4c4c seems rather
random. Ah well.

> The answers to those questions are necessary before anything 'useful'
> can be done around recording them in a consistent manner.
> There's also the issue that, in the largest share of devices i've
> seen, if they're present at all they're completely ignorable.
> There're only two cases i've heard of where paying attention to them
> are important, and of those, only one has a driver in the source tree.

Anyway, what is important in relation to NetBSD is whether
drivers need the sub IDs for matching/attachment, and I
believe that is not the case.

It seems to me that one driver should be sufficient for
any number of devices with different sub-IDs but the
same one (or more) product ID.

I think all this is necessary here is adding somewhat like
this little diff and letting the drivers sort it out.

--- src/sys/dev/pci/pcireg.h.orig	Tue Oct  6 21:52:50 1998
+++ src/sys/dev/pci/pcireg.h	Tue Oct  6 22:08:00 1998
@@ -283,6 +283,23 @@
 #define	PCI_MAPREG_IO_ADDR_MASK			0xfffffffc
 
 /*
+ * CardBus CIS register; contains a pointer to a CardBus CIS structure.
+ */
+
+#define PCI_CARDBUS_CIS_REG		0x28
+
+/*
+ * Subsystem identication register; contains a subsystem ID and
+ * a subsystem vendor ID.
+ */
+#define	PCI_SUBID_REG			0x2c
+
+/*
+ * Expansion ROM base address register.
+ */
+#define PCI_ROMBASE_REG			0x30
+
+/*
  * Interrupt Configuration Register; contains interrupt pin and line.
  */
 #define	PCI_INTERRUPT_REG		0x3c


-- 
Soren