TEXT   9

binding.txt

Guest on 10th August 2021 01:12:04 AM

  1.  
  2. Driver Binding
  3.  
  4. Driver binding is the process of associating a device with a device
  5. driver that can control it. Bus drivers have typically handled this
  6. because there have been bus-specific structures to represent the
  7. devices and the drivers. With generic device and device driver
  8. structures, most of the binding can take place using common code.
  9.  
  10.  
  11. Bus
  12. ~~~
  13.  
  14. The bus type structure contains a list of all devices that on that bus
  15. type in the system. When device_register is called for a device, it is
  16. inserted into the end of this list. The bus object also contains a
  17. list of all drivers of that bus type. When driver_register is called
  18. for a driver, it is inserted into the end of this list. These are the
  19. two events which trigger driver binding.
  20.  
  21.  
  22. device_register
  23. ~~~~~~~~~~~~~~~
  24.  
  25. When a new device is added, the bus's list of drivers is iterated over
  26. to find one that supports it. In order to determine that, the device
  27. ID of the device must match one of the device IDs that the driver
  28. supports. The format and semantics for comparing IDs is bus-specific.
  29. Instead of trying to derive a complex state machine and matching
  30. algorithm, it is up to the bus driver to provide a callback to compare
  31. a device against the IDs of a driver. The bus returns 1 if a match was
  32. found; 0 otherwise.
  33.  
  34. int match(struct device * dev, struct device_driver * drv);
  35.  
  36. If a match is found, the device's driver field is set to the driver
  37. and the driver's probe callback is called. This gives the driver a
  38. chance to verify that it really does support the hardware, and that
  39. it's in a working state.
  40.  
  41. Device Class
  42. ~~~~~~~~~~~~
  43.  
  44. Upon the successful completion of probe, the device is registered with
  45. the class to which it belongs. Device drivers belong to one and only
  46. class, and that is set in the driver's devclass field.
  47. devclass_add_device is called to enumerate the device within the class
  48. and actually register it with the class, which happens with the
  49. class's register_dev callback.
  50.  
  51. NOTE: The device class structures and core routines to manipulate them
  52. are not in the mainline kernel, so the discussion is still a bit
  53. speculative.
  54.  
  55.  
  56. Driver
  57. ~~~~~~
  58.  
  59. When a driver is attached to a device, the device is inserted into the
  60. driver's list of devices.
  61.  
  62.  
  63. driverfs
  64. ~~~~~~~~
  65.  
  66. A symlink is created in the bus's 'devices' directory that points to
  67. the device's directory in the physical hierarchy.
  68.  
  69. A symlink is created in the driver's 'devices' directory that points
  70. to the device's directory in the physical hierarchy.
  71.  
  72. A directory for the device is created in the class's directory. A
  73. symlink is created in that directory that points to the device's
  74. physical location in the driverfs tree.
  75.  
  76. A symlink can be created (though this isn't done yet) in the device's
  77. physical directory to either its class directory, or the class's
  78. top-level directory. One can also be created to point to its driver's
  79. directory also.
  80.  
  81.  
  82. driver_register
  83. ~~~~~~~~~~~~~~~
  84.  
  85. The process is almost identical for when a new driver is added.
  86. The bus's list of devices is iterated over to find a match. Devices
  87. that already have a driver are skipped. All the devices are iterated
  88. over, to bind as many devices as possible to the driver.
  89.  
  90.  
  91. Removal
  92. ~~~~~~~
  93.  
  94. When a device is removed, the reference count for it will eventually
  95. go to 0. When it does, the remove callback of the driver is called. It
  96. is removed from the driver's list of devices and the reference count
  97. of the driver is decremented. All symlinks between the two are removed.
  98.  
  99. When a driver is removed, the list of devices that it supports is
  100. iterated over, and the driver's remove callback is called for each
  101. one. The device is removed from that list and the symlinks removed.

Raw Paste


Login or Register to edit or fork this paste. It's free.