RE: Subsystem IDs and their meaning

["Kimmery, Clifford (FL51)" <kimmery@space.honeywell.com>]

I have to quibble with your allocation of 32 bits or 64 bits to
'unique-in-all-the-world' identification.  Since the vendor ID portions
of the device and subsystem identification fields are uniquely assigned
by the PCI SIG and are not available for arbitrary vendor use, the
dynamic range of the 'unique-in-all-the-world' identification is limited
to 16 bits for case 1) or 32 bits for case 2), unquestionably a more
limited resource in either case.

I must vote for 2) since it provides a much larger address space.  A
large vendor developing multiple PCI products per year over a number of
years could conceivably exceed a 16 bit address space.  I doubt that
they could exceed 32 bits during the life of the PCI bus unless they
used a particularly inefficient encoding scheme.

Cliff Kimmery
Honeywell Inc.
kimmery@space.honeywell.com

> ----------
> From: 	Dan Mick[SMTP:dan.mick@West.Sun.COM]
> Sent: 	Monday, January 05, 1998 2:47 PM
> To: 	Mailing List Recipients
> Subject: 	Subsystem IDs and their meaning
> 
> Hi, all.  There seems to be a difference of opinion about the
> interpretation of the spec WRT Subsystem IDs.  I've asked Warren
> Questo at Intel to help clarify, but have gotten no response as yet.
> 
> Can I run a quick opinion poll?
> 
> How many of you think either of the below?  (I believe them to be
> mutually-exclusive, so you can't think both.):
> 
> 1) The Subsystem Vendor ID and Subsystem ID can be used, by
> themselves, as the only pieces of information to uniquely identify a
> given PCI device (i.e. 32 bits of config space is a
> unique-in-all-the-world identifier for "this device in this
> subsystem").
> 
> 2) The Subsystem Vendor ID and Subsystem ID can be used only in
> conjunction with the Vendor ID and Device ID to uniquely identify a
> given PCI device. (i.e. 64 bits of config space is a
> unique-in-all-the-world identifier for "this device in this
> subsystem".)
> 
> 
> Raise your e-hands, please, 1 or 2 (privately or publicly, as you
> like, and I'll summarize, anonymously or otherwise, as you like).
> 
> ---
> 
> Here's some background material if you want to read on or are unclear
> about just what I mean:
> 
> 
> INTRODUCTION:
> 
> We've recently run into a disagreement about spec interpretation for
> the Subsystem fields in the PCI config space header.
> 
> Throughout this discussion I'll refer to the pair of numbers
> Vendor ID and Device ID as "normal ID" and the pair of numbers 
> Subsystem Vendor ID and Subsystem ID as "subsystem ID".
> 
> BACKGROUND:
> 
> We at Sun seem to have the opinion that subsystem ID is used to
> indicate a
> strictly-more-specific device identification that is unique,
> per-device, just as the normal ID is unique per-device.  The
> implication is that subsystem ID is completely sufficient for finding
> the "best" driver for a device, if present, and that if there is no
> subsystem-specific driver, the subsystem info can be ignored and the
> normal ID used to bind a driver.
> 
> NEW INFO CAUSING PROBLEM:
> 
> A vendor has produced a motherboard which includes two
> very-dissimilar PCI devices (a graphics chip and an Ethernet chip),
> both of which have subsystem IDs.  However, they have exactly the
> *same* subsystem ID....the one which represents this particular
> motherboard (motherboard vendor's vendor ID, and a number indicating
> the motherboard in Subsystem ID).  They claim this is PCI 2.1- and
> PC97-compliant.
> 
> 
> PROBLEM:
> 
> The interpretation of the meaning of the values in the subsystem ID
> is the issue, not the format (the "semantics" rather than the
> "syntax",
> if you will).
> 
> The P1275 Bus Binding for PCI requires, in the absence of generic
> names, the node name (in the "name" property and in the /devices tree
> in Solaris) to be set from the subsystem ID if present, otherwise to
> be set from the normal ID.  While this will still work, strictly
> speaking, for this system, since the unit-address is different
> for the two devices, it will:
> 
> 1) certainly be a confusing set of nodes and /devices entries, as
> they'll both say "pciVVVV,DDDD@<unit-address>" using the same
> VVVV,DDDD, albeit different unit-addresses, and prtconf will show the
> device node name as "pciVVVV,DDDD".
> 
> 2) prevent the binding of a different driver for this particular
> device, made up of a video-chip-in-a-OEM-mumblefoo-motherboard,
> since the driver binding will be done either from the subsystem ID
> (which we'll have to avoid binding, since it's identical for two
> devices which obviously have different drivers), or the vendor ID
> (which loses the information about the subsystem).
> 
> 1) is inconvenient.  2) may be a problem.
> 
> I've looked at the driver binding for Microsoft Windows 95 (and assume
> it's the same for NT).  They seem to create an identifier which 
> includes both subsystem and normal IDs (along with Revision) so that
> the right driver can be bound if there is a specific driver.
> 
> INTENDED SUBSYSTEM SEMANTICS:
> 
> The PCI 2.1 spec isn't very helpful (see quote [1] below).
> 
> PC97 is similarly unhelpful; it merely says that they're required to
> be nonzero, and says some things about when they must be valid.
> 
> A later PCISIG ECN changes these from "optional" to "required", at
> several PCISIG members' request (Microsoft and DEC were big
> proponents).  I'm not certain of the status of this ECN but there are
> some quotes below at [2].
> 
> The PCI 2.1 spec certainly doesn't make it clear what the point of
> Subsystem ID is.  On the one hand, I can see the point that "a
> subsystem"
> is naturally interpreted as "a plug-in card" or "a motherboard".
> Think,
> for instance, about a commonly-found Ethernet card that has a PCI-PCI
> bridge chip and four identical DEC Ethernet PCI devices behind the
> bridge.
> What should the subsystem ID for these five devices be?  Should it 
> indicate the plug-in card, or the plug-in-card-plus-the-chip-function?
> (i.e. would you expect to be able to use the subsystem ID alone to
> determine the proper driver for each of the five PCI devices)?
> 
> It seems much clearer in the case of the two-wildly-different devices
> on the same motherboard, but I'm not clear.
> 
> On the other hand, while PCI 2.1 isn't very clear, the ECN says
> "to allow explicit driver determination for a specific PCI device"
> and "OS vendors can then use SVID and SID fields to specifically load
> the correct driver", both of which seem to support the notion
> that subsystem ID should be enough on its own to find a driver.
> 
> 
> ----
> 
> [1] From PCI 2.1:
> 
> 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 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.
> 
> 
> 
> [2] From PCI ECN "Subsystem Vendor ID and Subsystem ID required"
> 
> 
> 1.1.    Clarification / Motivation 
> 
> The intent of the Subsystem Vendor ID (SVID) and Subsystem ID (SID)
> is to allow explicit driver determination for a specific PCI device.
> These optional fields provide a standard mechanism to enable vendors
> to differentiate their designs. Since they are optional, few
> implementations use them. The problem exists when one PCI device is
> used in multiple designs. This variable device causes the
> configuration software to use heuristics as to which specific
> operating system driver to load.  This non-precise approach does lead
> to system anomalies.
> 
> The impetus of this ECR is to require these fields on all PCI devices
> with the exclusion of core logic chipsets, bridges, and legacy system
> devices. Specifically PCI devices that have a base class 6, with
> subclass 0-4 (0,1,2,3,4) and base class 8 subclass 0-3 (0,1,2,3) are
> excluded from this requirement. Core logic chipsets, bridges, and
> legacy system devices are excluded because these devices use existing
> operating system bus drivers, device dependent layers (i.e. HAL), or
> require no drivers for normal operation. All other PCI devices are
> required to implement the SVID and SID registers so that they can be
> used by different vendors in multiple designs.
> 
> OS vendors can then use SVID and SID fields to specifically load the
> correct driver, allowing IHVs to differentiate their products even
> though they are using the same silicon.
> 
> 
>