Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | |
| 2 | Bus Types |
| 3 | |
| 4 | Definition |
| 5 | ~~~~~~~~~~ |
Wanlong Gao | 63dc355 | 2011-05-05 07:55:37 +0800 | [diff] [blame] | 6 | See the kerneldoc for the struct bus_type. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 | |
Jeremiah Mahler | 2cd14f5 | 2014-12-26 06:57:49 -0800 | [diff] [blame] | 48 | The purpose of the match callback is to give the bus an opportunity to |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 | |