Orange Pi5 kernel

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