]>
Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | |
2 | Bus Types | |
3 | ||
4 | Definition | |
5 | ~~~~~~~~~~ | |
63dc355a | 6 | See the kerneldoc for the struct bus_type. |
1da177e4 LT |
7 | |
8 | int bus_register(struct bus_type * bus); | |
9 | ||
10 | ||
11 | Declaration | |
12 | ~~~~~~~~~~~ | |
13 | ||
14 | Each bus type in the kernel (PCI, USB, etc) should declare one static | |
15 | object of this type. They must initialize the name field, and may | |
16 | optionally initialize the match callback. | |
17 | ||
18 | struct bus_type pci_bus_type = { | |
19 | .name = "pci", | |
20 | .match = pci_bus_match, | |
21 | }; | |
22 | ||
23 | The structure should be exported to drivers in a header file: | |
24 | ||
25 | extern struct bus_type pci_bus_type; | |
26 | ||
27 | ||
28 | Registration | |
29 | ~~~~~~~~~~~~ | |
30 | ||
31 | When a bus driver is initialized, it calls bus_register. This | |
32 | initializes the rest of the fields in the bus object and inserts it | |
33 | into a global list of bus types. Once the bus object is registered, | |
34 | the fields in it are usable by the bus driver. | |
35 | ||
36 | ||
37 | Callbacks | |
38 | ~~~~~~~~~ | |
39 | ||
40 | match(): Attaching Drivers to Devices | |
41 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
42 | ||
43 | The format of device ID structures and the semantics for comparing | |
44 | them are inherently bus-specific. Drivers typically declare an array | |
45 | of device IDs of devices they support that reside in a bus-specific | |
46 | driver structure. | |
47 | ||
2cd14f5d | 48 | The purpose of the match callback is to give the bus an opportunity to |
1da177e4 LT |
49 | determine if a particular driver supports a particular device by |
50 | comparing the device IDs the driver supports with the device ID of a | |
51 | particular device, without sacrificing bus-specific functionality or | |
52 | type-safety. | |
53 | ||
54 | When a driver is registered with the bus, the bus's list of devices is | |
55 | iterated over, and the match callback is called for each device that | |
56 | does not have a driver associated with it. | |
57 | ||
58 | ||
59 | ||
60 | Device and Driver Lists | |
61 | ~~~~~~~~~~~~~~~~~~~~~~~ | |
62 | ||
63 | The lists of devices and drivers are intended to replace the local | |
64 | lists that many buses keep. They are lists of struct devices and | |
65 | struct device_drivers, respectively. Bus drivers are free to use the | |
66 | lists as they please, but conversion to the bus-specific type may be | |
67 | necessary. | |
68 | ||
69 | The LDM core provides helper functions for iterating over each list. | |
70 | ||
71 | int bus_for_each_dev(struct bus_type * bus, struct device * start, void * data, | |
72 | int (*fn)(struct device *, void *)); | |
73 | ||
74 | int bus_for_each_drv(struct bus_type * bus, struct device_driver * start, | |
75 | void * data, int (*fn)(struct device_driver *, void *)); | |
76 | ||
77 | These helpers iterate over the respective list, and call the callback | |
78 | for each device or driver in the list. All list accesses are | |
79 | synchronized by taking the bus's lock (read currently). The reference | |
80 | count on each object in the list is incremented before the callback is | |
81 | called; it is decremented after the next object has been obtained. The | |
82 | lock is not held when calling the callback. | |
83 | ||
84 | ||
85 | sysfs | |
86 | ~~~~~~~~ | |
87 | There is a top-level directory named 'bus'. | |
88 | ||
89 | Each bus gets a directory in the bus directory, along with two default | |
90 | directories: | |
91 | ||
92 | /sys/bus/pci/ | |
93 | |-- devices | |
94 | `-- drivers | |
95 | ||
96 | Drivers registered with the bus get a directory in the bus's drivers | |
97 | directory: | |
98 | ||
99 | /sys/bus/pci/ | |
100 | |-- devices | |
101 | `-- drivers | |
102 | |-- Intel ICH | |
103 | |-- Intel ICH Joystick | |
104 | |-- agpgart | |
105 | `-- e100 | |
106 | ||
107 | Each device that is discovered on a bus of that type gets a symlink in | |
108 | the bus's devices directory to the device's directory in the physical | |
109 | hierarchy: | |
110 | ||
111 | /sys/bus/pci/ | |
112 | |-- devices | |
113 | | |-- 00:00.0 -> ../../../root/pci0/00:00.0 | |
114 | | |-- 00:01.0 -> ../../../root/pci0/00:01.0 | |
115 | | `-- 00:02.0 -> ../../../root/pci0/00:02.0 | |
116 | `-- drivers | |
117 | ||
118 | ||
119 | Exporting Attributes | |
120 | ~~~~~~~~~~~~~~~~~~~~ | |
121 | struct bus_attribute { | |
122 | struct attribute attr; | |
123 | ssize_t (*show)(struct bus_type *, char * buf); | |
124 | ssize_t (*store)(struct bus_type *, const char * buf, size_t count); | |
125 | }; | |
126 | ||
127 | Bus drivers can export attributes using the BUS_ATTR macro that works | |
128 | similarly to the DEVICE_ATTR macro for devices. For example, a definition | |
129 | like this: | |
130 | ||
131 | static BUS_ATTR(debug,0644,show_debug,store_debug); | |
132 | ||
133 | is equivalent to declaring: | |
134 | ||
135 | static bus_attribute bus_attr_debug; | |
136 | ||
137 | This can then be used to add and remove the attribute from the bus's | |
138 | sysfs directory using: | |
139 | ||
140 | int bus_create_file(struct bus_type *, struct bus_attribute *); | |
141 | void bus_remove_file(struct bus_type *, struct bus_attribute *); | |
142 | ||
143 |