0001 ==============
0002 Driver Binding
0003 ==============
0004
0005 Driver binding is the process of associating a device with a device
0006 driver that can control it. Bus drivers have typically handled this
0007 because there have been bus-specific structures to represent the
0008 devices and the drivers. With generic device and device driver
0009 structures, most of the binding can take place using common code.
0010
0011
0012 Bus
0013 ~~~
0014
0015 The bus type structure contains a list of all devices that are on that bus
0016 type in the system. When device_register is called for a device, it is
0017 inserted into the end of this list. The bus object also contains a
0018 list of all drivers of that bus type. When driver_register is called
0019 for a driver, it is inserted at the end of this list. These are the
0020 two events which trigger driver binding.
0021
0022
0023 device_register
0024 ~~~~~~~~~~~~~~~
0025
0026 When a new device is added, the bus's list of drivers is iterated over
0027 to find one that supports it. In order to determine that, the device
0028 ID of the device must match one of the device IDs that the driver
0029 supports. The format and semantics for comparing IDs is bus-specific.
0030 Instead of trying to derive a complex state machine and matching
0031 algorithm, it is up to the bus driver to provide a callback to compare
0032 a device against the IDs of a driver. The bus returns 1 if a match was
0033 found; 0 otherwise.
0034
0035 int match(struct device * dev, struct device_driver * drv);
0036
0037 If a match is found, the device's driver field is set to the driver
0038 and the driver's probe callback is called. This gives the driver a
0039 chance to verify that it really does support the hardware, and that
0040 it's in a working state.
0041
0042 Device Class
0043 ~~~~~~~~~~~~
0044
0045 Upon the successful completion of probe, the device is registered with
0046 the class to which it belongs. Device drivers belong to one and only one
0047 class, and that is set in the driver's devclass field.
0048 devclass_add_device is called to enumerate the device within the class
0049 and actually register it with the class, which happens with the
0050 class's register_dev callback.
0051
0052
0053 Driver
0054 ~~~~~~
0055
0056 When a driver is attached to a device, the device is inserted into the
0057 driver's list of devices.
0058
0059
0060 sysfs
0061 ~~~~~
0062
0063 A symlink is created in the bus's 'devices' directory that points to
0064 the device's directory in the physical hierarchy.
0065
0066 A symlink is created in the driver's 'devices' directory that points
0067 to the device's directory in the physical hierarchy.
0068
0069 A directory for the device is created in the class's directory. A
0070 symlink is created in that directory that points to the device's
0071 physical location in the sysfs tree.
0072
0073 A symlink can be created (though this isn't done yet) in the device's
0074 physical directory to either its class directory, or the class's
0075 top-level directory. One can also be created to point to its driver's
0076 directory also.
0077
0078
0079 driver_register
0080 ~~~~~~~~~~~~~~~
0081
0082 The process is almost identical for when a new driver is added.
0083 The bus's list of devices is iterated over to find a match. Devices
0084 that already have a driver are skipped. All the devices are iterated
0085 over, to bind as many devices as possible to the driver.
0086
0087
0088 Removal
0089 ~~~~~~~
0090
0091 When a device is removed, the reference count for it will eventually
0092 go to 0. When it does, the remove callback of the driver is called. It
0093 is removed from the driver's list of devices and the reference count
0094 of the driver is decremented. All symlinks between the two are removed.
0095
0096 When a driver is removed, the list of devices that it supports is
0097 iterated over, and the driver's remove callback is called for each
0098 one. The device is removed from that list and the symlinks removed.
