1*4882a593Smuzhiyun============== 2*4882a593SmuzhiyunDriver Binding 3*4882a593Smuzhiyun============== 4*4882a593Smuzhiyun 5*4882a593SmuzhiyunDriver binding is the process of associating a device with a device 6*4882a593Smuzhiyundriver that can control it. Bus drivers have typically handled this 7*4882a593Smuzhiyunbecause there have been bus-specific structures to represent the 8*4882a593Smuzhiyundevices and the drivers. With generic device and device driver 9*4882a593Smuzhiyunstructures, most of the binding can take place using common code. 10*4882a593Smuzhiyun 11*4882a593Smuzhiyun 12*4882a593SmuzhiyunBus 13*4882a593Smuzhiyun~~~ 14*4882a593Smuzhiyun 15*4882a593SmuzhiyunThe bus type structure contains a list of all devices that are on that bus 16*4882a593Smuzhiyuntype in the system. When device_register is called for a device, it is 17*4882a593Smuzhiyuninserted into the end of this list. The bus object also contains a 18*4882a593Smuzhiyunlist of all drivers of that bus type. When driver_register is called 19*4882a593Smuzhiyunfor a driver, it is inserted at the end of this list. These are the 20*4882a593Smuzhiyuntwo events which trigger driver binding. 21*4882a593Smuzhiyun 22*4882a593Smuzhiyun 23*4882a593Smuzhiyundevice_register 24*4882a593Smuzhiyun~~~~~~~~~~~~~~~ 25*4882a593Smuzhiyun 26*4882a593SmuzhiyunWhen a new device is added, the bus's list of drivers is iterated over 27*4882a593Smuzhiyunto find one that supports it. In order to determine that, the device 28*4882a593SmuzhiyunID of the device must match one of the device IDs that the driver 29*4882a593Smuzhiyunsupports. The format and semantics for comparing IDs is bus-specific. 30*4882a593SmuzhiyunInstead of trying to derive a complex state machine and matching 31*4882a593Smuzhiyunalgorithm, it is up to the bus driver to provide a callback to compare 32*4882a593Smuzhiyuna device against the IDs of a driver. The bus returns 1 if a match was 33*4882a593Smuzhiyunfound; 0 otherwise. 34*4882a593Smuzhiyun 35*4882a593Smuzhiyunint match(struct device * dev, struct device_driver * drv); 36*4882a593Smuzhiyun 37*4882a593SmuzhiyunIf a match is found, the device's driver field is set to the driver 38*4882a593Smuzhiyunand the driver's probe callback is called. This gives the driver a 39*4882a593Smuzhiyunchance to verify that it really does support the hardware, and that 40*4882a593Smuzhiyunit's in a working state. 41*4882a593Smuzhiyun 42*4882a593SmuzhiyunDevice Class 43*4882a593Smuzhiyun~~~~~~~~~~~~ 44*4882a593Smuzhiyun 45*4882a593SmuzhiyunUpon the successful completion of probe, the device is registered with 46*4882a593Smuzhiyunthe class to which it belongs. Device drivers belong to one and only one 47*4882a593Smuzhiyunclass, and that is set in the driver's devclass field. 48*4882a593Smuzhiyundevclass_add_device is called to enumerate the device within the class 49*4882a593Smuzhiyunand actually register it with the class, which happens with the 50*4882a593Smuzhiyunclass's register_dev callback. 51*4882a593Smuzhiyun 52*4882a593Smuzhiyun 53*4882a593SmuzhiyunDriver 54*4882a593Smuzhiyun~~~~~~ 55*4882a593Smuzhiyun 56*4882a593SmuzhiyunWhen a driver is attached to a device, the device is inserted into the 57*4882a593Smuzhiyundriver's list of devices. 58*4882a593Smuzhiyun 59*4882a593Smuzhiyun 60*4882a593Smuzhiyunsysfs 61*4882a593Smuzhiyun~~~~~ 62*4882a593Smuzhiyun 63*4882a593SmuzhiyunA symlink is created in the bus's 'devices' directory that points to 64*4882a593Smuzhiyunthe device's directory in the physical hierarchy. 65*4882a593Smuzhiyun 66*4882a593SmuzhiyunA symlink is created in the driver's 'devices' directory that points 67*4882a593Smuzhiyunto the device's directory in the physical hierarchy. 68*4882a593Smuzhiyun 69*4882a593SmuzhiyunA directory for the device is created in the class's directory. A 70*4882a593Smuzhiyunsymlink is created in that directory that points to the device's 71*4882a593Smuzhiyunphysical location in the sysfs tree. 72*4882a593Smuzhiyun 73*4882a593SmuzhiyunA symlink can be created (though this isn't done yet) in the device's 74*4882a593Smuzhiyunphysical directory to either its class directory, or the class's 75*4882a593Smuzhiyuntop-level directory. One can also be created to point to its driver's 76*4882a593Smuzhiyundirectory also. 77*4882a593Smuzhiyun 78*4882a593Smuzhiyun 79*4882a593Smuzhiyundriver_register 80*4882a593Smuzhiyun~~~~~~~~~~~~~~~ 81*4882a593Smuzhiyun 82*4882a593SmuzhiyunThe process is almost identical for when a new driver is added. 83*4882a593SmuzhiyunThe bus's list of devices is iterated over to find a match. Devices 84*4882a593Smuzhiyunthat already have a driver are skipped. All the devices are iterated 85*4882a593Smuzhiyunover, to bind as many devices as possible to the driver. 86*4882a593Smuzhiyun 87*4882a593Smuzhiyun 88*4882a593SmuzhiyunRemoval 89*4882a593Smuzhiyun~~~~~~~ 90*4882a593Smuzhiyun 91*4882a593SmuzhiyunWhen a device is removed, the reference count for it will eventually 92*4882a593Smuzhiyungo to 0. When it does, the remove callback of the driver is called. It 93*4882a593Smuzhiyunis removed from the driver's list of devices and the reference count 94*4882a593Smuzhiyunof the driver is decremented. All symlinks between the two are removed. 95*4882a593Smuzhiyun 96*4882a593SmuzhiyunWhen a driver is removed, the list of devices that it supports is 97*4882a593Smuzhiyuniterated over, and the driver's remove callback is called for each 98*4882a593Smuzhiyunone. The device is removed from that list and the symlinks removed. 99