PCI device identification and driver binding in Solaris

This is a blog article written by Dan Mick, http://blogs.sun.com/dmick/entry/title_pci_device_identification_and

A PCI device has a bunch of device identification numbers associated with it, which generic code can retrieve. I've listed them here in most-specific to least-specific order, by their Solaris property name (shown in the prtconf -pv output, which is why we always always always ask for that when diagnosing driver-binding problems):

1. revision (not useful on its own)
2. vendor-id, device-id (the usual lone source of driver binding)
3. subsystem-vendor-id, subsystem-id (the usual source of the "name" property, and hence the usual source of the /devices node name)
4. class-code

The revision number is only useful in conjunction with vendor-id, device-id.

Entry 3, the subsystem, is nearly useless for every purpose, as many machines now use the same subsystem ID for every motherboard device, and if not, at least the same subsystem-vendor-id. Sun had originally interpreted subsystem to be more specific than vendor-id, device-id, but that's not how the industry ended up adopting it. (as usual, the spec was unclear as to its intent).

The only things Solaris normally uses for binding device drivers are 2 and 4.

The way Solaris driver binding works is: for every element in the compatible property, in order, a) look for a same-named driver; if it's there, use it; if not, b) look for a same-named device alias, and get the driver field out of it; if it's there, use it. That's it. (Note that I'm specifically talking about Solaris, nothing to do with bootconf or the DCA.)

So most devices are bound through the vendor-id, device-id pair. Some devices and drivers are generic enough so that one driver is able to run an entire class of devices (say, for instance, pci-ide); in that case, the class-code can be used. But for the most part, vendor-id,device-id is what you want in /etc/driver_aliases, and it's always the right thing to talk about when you're trying to describe which device you have to someone else.

The Broadcom device aliases were added with both vendor-id, device-id and subsystem-vendor-id, subsystem-id, the intent being to try to bind the bge device driver only to particular boards and motherboards we had tested explicitly. (Opinions differed as to whether this was a good idea.) Since then, I believe the motion is back to just vendor-id,device-id, but if you see device aliases for bge with four numbers, that's why. They'll still work with two numbers, just not as pickily.

Now obviously this opens up the possibility that more than one alias might match for a particular set of numbers in the PCI device...but that's why we specify what's in the compatible property, not what's in the device. The compatible property is always constructed in a specific order, and as of s10_37, contains the following (intentionally-redundant) elements for PCI devices:

         *   (possibly) node-name       (0)

         *   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)

(VVVV is vendor-id, DDDD is device-id, SSSS is subsystem-vendor-id, ssss is subsystem-id, RR revision, CC major class number, SS subclass number, PP programming-interface-byte)

Form 0 is there for certain special devices, to "override" the normal matching, mostly older devices. Then, as you can see, we sorta go from most-specific to least-specific, which is the intent of the compatible property on any bus, PCI being no exception. The exception to that order is number 3, which had to be where it is because of the original definition of the compatible property in the original IEEE1275 spec, which all this is based on. But it's OK, because we (as noted above) virtually never use it for binding drivers anyway; we almost-always use 5 or 6/7, and sometimes 2.

---