Date: Tue, 13 Jan 1998 19:37:42 -0800 (PST) From: Dan Mick Subject: Item #430: PCI Binding: Expand PCI compatible/name ... P1275 Openboot Working Group Proposal -- Proposal #:430 Ver 0.7 Title: Expand PCI compatible/name to include more unique ID info Author: Dan.Mick@West.Sun.COM Date: January 8, 1998 Ed/Tech: Technical Synopsis: Subsystem ID's are not a sufficiently-unique device identifier Doc & Version: PCI Bus Binding, Revision 2.0 Problem: The definition of name and compatible make the assumption that the pair of numbers Subsystem Vendor ID/Subsystem ID (SSVID/SSID) are a unique identifier for the device, and can be used to identify a device in a way sufficient to choose a driver, in much the same way as the Vendor ID/Device ID (VID/DID). This assumption is part of the specification for the value of the "name" and "compatible" properties for a device without an FCode program (section 2.5, page 9). The specification says: "name" Based on the PCI Class Code register, pick a name from Table 1. If none apply, generate a name of the form "pciVVVV,DDDD" as described below under "compatible". "compatible" Construct a name of the form pciVVVV,DDDD. If the Subsystem ID field in the configuration registers for this device is non-zero, VVVV,DDDD shall be the Subsystem Vendor ID and Subsystem ID respectively; otherwise VVVV,DDDD shall be the value of the Vendor ID and Device ID fields. VVVV and DDDD are ASCII hexadecimal numbers, lower case, without leading zeros. Proposal #380 further modifies this recommendation, something like this (it apparently hasn't yet been incorporated into the PCI Bus Binding): "compatible" Construct a list of names in most-specific to least-specific order as defined in [4] [the generic names proposal], with the most specific name first in the list derived from the subsystem id, vendor id [ use existing text here ]. The second entry in the list is in the form pciclass,NNNNNN, where NNNNNN is the device class code, in lower-case hexadecimal including leading zeroes. Proposal #405 added the VID/DID-based name to compatible as well, making the result subsystem-id-name + vendor-id-name + class-code-name However, we now know of at least one vendor who is implementing a motherboard with two different PCI devices, each with a different VID/DID, and indeed different Class Codes, but the same SSVID/SSID for each. In an informal poll of the participants of the mailing list pci-sig@znyx.com, of 24 respondents, 17 said their understanding was that SSVID/SSID was not a unique device identifier, but rather only had meaning when combined with VID/DID. This makes the choice of name and/or compatible suboptimal, as it's no longer a unique identifier for the device that would allow choice of an appropriate driver. Since an OS may wish to use the name and compatible properties to bind a driver, it is desirable to have sufficiently-unique information in those two properties to allow the proper driver binding. Moreover, it may be preferable to allow OS driver binding to occur influenced by other items in the PCI configuration space, such as Revision ID, and Class Code with and without the programming information byte. Precedent for this sort of device identification has been established in the ACPI specification. The definition for _CID recommends that six different forms of "compatible device ID's" be defined (see http://www.teleport.com/~acpi/acpihtml/topic102.htm#1): PCI\CC_ccss PCI\CC_ccsspp PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssssss&REV_rr PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssssss PCI\VEN_vvvv&DEV_dddd&REV_rr PCI\VEN_vvvv&DEV_dddd where: cc = hexadecimal representation of the Class Code byte ss = hexadecimal representation of the Subclass Code byte pp = hexadecimal representation of the Programming interface byte vvvv = hexadecimal representation of the Vendor ID dddd = hexadecimal representation of the Device ID ssssssss = hexadecimal representation of the Subsystem ID rr = hexadecimal representation of the Revision byte Microsoft Windows 95 and Windows NT already use a very similar scheme to represent devices enumerated on various buses. Proposal: Add similar extensions to the definition of "name" and "compatible", replacing the existing specification for both properties with the following text (between "=====" marks): ===== "name" Based on the PCI Class Code register, pick a name from Table 1. If none apply, and Subsystem Vendor ID is nonzero, generate a name of form (1) as described below under "compatible". If none apply, and Subsystem Vendor ID is zero, generate a name of form (4) as described below under "compatible". "compatible" Construct a list of names in most-specific to least-specific order. The names shall be derived from values of the Vendor ID, Device ID, Subsystem Vendor ID, Subsystem ID, Revision ID, and Class Code bytes, and shall have the following form, and be placed in the list in the following order: pciVVVV,DDDD.SSSS.ssss.RR (1) pciVVVV,DDDD.SSSS.ssss (2) pciSSSS,ssss (3) pciVVVV,DDDD.RR (4) pciVVVV,DDDD (5) pciclass,CCSSPP (6) pciclass,CCSS (7) where: VVVV is the Vendor ID DDDD is the Device ID SSSS is the Subsystem Vendor ID ssss is the Subsystem ID RR is the Revision ID CC is the most-significant byte of the Class Code, or base class code (config space byte at address 0x0b) SS is the second-most-significant byte of the Class Code, or sub-class code (config space byte at address 0x0a) PP is the least-significant byte of the Class Code, or programming interface (config space byte at address 0x09) The entries numbered (1) and (2) (of the form pciVVVV,DDDD,SSSS,ssss,RR and pciVVVV,DDDD,SSSS,ssss) shall be included if and only if the Subsystem Vendor ID is non-zero. Entry (3) is supplied only for backwards compatibility with versions of the PCI binding prior to this proposal; new OS binding mechanisms should instead use forms (1) or (2) to select a driver based on the values in SSVID/SSID. VVVV, DDDD, SSSS, ssss, and RR are ASCII hexadecimal numbers, lower case, without leading zeroes. CC, SS, and PP are ASCII hexadecimal numbers, lower case, including leading zeroes. ===== (Note: Proposal #405 said to create the subsystem-id-name "if the subsystem-id is non-zero". This proposal changes that criterion to "if SSVID is non-zero", since I believe the PCI spec allows for the possibility that SSVID != 0 while SSID == zero. The spec is rather ambiguous in its wording on this issue, as with all issues about SSVID/SSID.) [ P1275 Item #430 -- Received: Tue Jan 13 19:39:40 PST 1998 ]