driver-api/driver-model/overview.rst

16 bus-specific drivers for bridges and devices by consolidating a set of data
19 Traditional driver models implemented some sort of tree-like structure
21 uniformity across the different bus types.
24 a bus and the devices that can appear under the bus. The unified bus
26 of common callbacks, such as device discovery during bus probing, bus
27 shutdown, bus power management, etc.
32 Microsoft (namely ACPI) ensures that almost every device on almost any bus
33 on an x86-compatible system can work within this paradigm.  Of course,
34 not every bus is able to support all such operations, although most
41 Common data fields have been moved out of individual bus layers into a common
42 data structure. These fields must still be accessed by the bus layers,
43 and sometimes by the device-specific drivers.
45 Other bus layers are encouraged to do what has been done for the PCI layer.
60 they're doing when switching between the bus driver and the global driver,
63 The PCI bus layer freely accesses the fields of struct device. It knows about
71 downstream driver would break.  On the other hand, if only the bus layer
72 (and not the device layer) accesses the struct device, it is only the bus
93 The auto-mounting of sysfs is typically accomplished by an entry similar to
98 or something similar in the /lib/init/fstab file on Debian-based systems::
104 	# mount -t sysfs sysfs /sys
107 This directory may be populated at each layer of discovery - the global layer,
108 the bus layer, or the device layer.
110 The global layer currently creates two files - 'name' and 'power'. The
115 The bus layer may also create files for the devices it finds while probing the
116 bus. For example, the PCI layer currently creates 'irq' and 'resource' files
119 A device-specific driver may also export files in its directory to expose
120 device-specific data or tunable interfaces.