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 associatedwith it, which generic code can retrieve. I've listed them here inmost-specific to least-specific order, by their Solaris property name(shown in the prtconf -pv output, which is why we always always alwaysask 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 manymachines now use the same subsystem ID for everymotherboard device, and if not, at least the same subsystem-vendor-id.Sun had originally interpreted subsystem to be more specific thanvendor-id, device-id, but that's not how the industry ended up adoptingit. (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 compatibleproperty, in order, a) look for a same-named driver; if it's there, useit; if not, b) look for a same-named device alias, and get the driverfield out of it; if it's there, use it. That's it. (Note that I'mspecifically talking about Solaris, nothing to do with bootconf or theDCA.)

So most devices are bound through the vendor-id, device-id pair.Some devices and drivers are generic enough so that one driver is ableto run an entire class of devices (say, for instance, pci-ide); in thatcase, 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'salways the right thing to talk about when you're trying to describewhich device you have to someone else.

The Broadcom device aliases were added with bothvendor-id, device-id and subsystem-vendor-id,subsystem-id, the intent being to try to bind the bge device driveronly to particular boards and motherboards we had testedexplicitly. (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 aliasmight match for a particular set of numbers in the PCI device...butthat's why we specify what's in the compatible property, not what's inthe device. The compatible property is always constructed in aspecific 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 subclassnumber, PP programming-interface-byte)

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

---