Orange Pi5 kernel

Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards

3 Commits   0 Branches   0 Tags
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   1) =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   2) The Linux Kernel Device Model
^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) Patrick Mochel	<mochel@digitalimplant.org>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   6) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   7) Drafted 26 August 2002
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   8) Updated 31 January 2006
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   9) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  10) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  11) Overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  12) ~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  13) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  14) The Linux Kernel Driver Model is a unification of all the disparate driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  15) models that were previously used in the kernel. It is intended to augment the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  16) bus-specific drivers for bridges and devices by consolidating a set of data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  17) and operations into globally accessible data structures.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  18) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  19) Traditional driver models implemented some sort of tree-like structure
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  20) (sometimes just a list) for the devices they control. There wasn't any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  21) uniformity across the different bus types.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  22) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  23) The current driver model provides a common, uniform data model for describing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  24) a bus and the devices that can appear under the bus. The unified bus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  25) model includes a set of common attributes which all busses carry, and a set
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  26) of common callbacks, such as device discovery during bus probing, bus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  27) shutdown, bus power management, etc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  28) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  29) The common device and bridge interface reflects the goals of the modern
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  30) computer: namely the ability to do seamless device "plug and play", power
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  31) management, and hot plug. In particular, the model dictated by Intel and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  32) Microsoft (namely ACPI) ensures that almost every device on almost any bus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  33) on an x86-compatible system can work within this paradigm.  Of course,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  34) not every bus is able to support all such operations, although most
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  35) buses support most of those operations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  36) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  37) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  38) Downstream Access
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  39) ~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  40) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  41) Common data fields have been moved out of individual bus layers into a common
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  42) data structure. These fields must still be accessed by the bus layers,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  43) and sometimes by the device-specific drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  44) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  45) Other bus layers are encouraged to do what has been done for the PCI layer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  46) struct pci_dev now looks like this::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  47) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  48)   struct pci_dev {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  49) 	...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  50) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  51) 	struct device dev;     /* Generic device interface */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  52) 	...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  53)   };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  54) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  55) Note first that the struct device dev within the struct pci_dev is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  56) statically allocated. This means only one allocation on device discovery.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  57) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  58) Note also that that struct device dev is not necessarily defined at the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  59) front of the pci_dev structure.  This is to make people think about what
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  60) they're doing when switching between the bus driver and the global driver,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  61) and to discourage meaningless and incorrect casts between the two.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  62) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  63) The PCI bus layer freely accesses the fields of struct device. It knows about
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  64) the structure of struct pci_dev, and it should know the structure of struct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  65) device. Individual PCI device drivers that have been converted to the current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  66) driver model generally do not and should not touch the fields of struct device,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  67) unless there is a compelling reason to do so.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  68) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  69) The above abstraction prevents unnecessary pain during transitional phases.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  70) If it were not done this way, then when a field was renamed or removed, every
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  71) downstream driver would break.  On the other hand, if only the bus layer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  72) (and not the device layer) accesses the struct device, it is only the bus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  73) layer that needs to change.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  74) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  75) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  76) User Interface
^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) By virtue of having a complete hierarchical view of all the devices in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  80) system, exporting a complete hierarchical view to userspace becomes relatively
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  81) easy. This has been accomplished by implementing a special purpose virtual
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  82) file system named sysfs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  83) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  84) Almost all mainstream Linux distros mount this filesystem automatically; you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  85) can see some variation of the following in the output of the "mount" command::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  86) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  87)   $ mount
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  88)   ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  89)   none on /sys type sysfs (rw,noexec,nosuid,nodev)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  90)   ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  91)   $
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  92) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  93) The auto-mounting of sysfs is typically accomplished by an entry similar to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  94) the following in the /etc/fstab file::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  95) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  96)   none     	/sys	sysfs    defaults	  	0 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  97) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  98) or something similar in the /lib/init/fstab file on Debian-based systems::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  99) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100)   none            /sys    sysfs    nodev,noexec,nosuid    0 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) If sysfs is not automatically mounted, you can always do it manually with::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) 	# mount -t sysfs sysfs /sys
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) Whenever a device is inserted into the tree, a directory is created for it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) This directory may be populated at each layer of discovery - the global layer,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) the bus layer, or the device layer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) The global layer currently creates two files - 'name' and 'power'. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) former only reports the name of the device. The latter reports the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) current power state of the device. It will also be used to set the current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) power state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) The bus layer may also create files for the devices it finds while probing the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) bus. For example, the PCI layer currently creates 'irq' and 'resource' files
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) for each PCI device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) A device-specific driver may also export files in its directory to expose
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) device-specific data or tunable interfaces.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) More information about the sysfs directory layout can be found in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) the other documents in this directory and in the file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) Documentation/filesystems/sysfs.rst.