Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | |
| 2 | Device Classes |
| 3 | |
| 4 | |
| 5 | Introduction |
| 6 | ~~~~~~~~~~~~ |
| 7 | A device class describes a type of device, like an audio or network |
| 8 | device. The following device classes have been identified: |
| 9 | |
| 10 | <Insert List of Device Classes Here> |
| 11 | |
| 12 | |
| 13 | Each device class defines a set of semantics and a programming interface |
| 14 | that devices of that class adhere to. Device drivers are the |
| 15 | implemention of that programming interface for a particular device on |
| 16 | a particular bus. |
| 17 | |
| 18 | Device classes are agnostic with respect to what bus a device resides |
| 19 | on. |
| 20 | |
| 21 | |
| 22 | Programming Interface |
| 23 | ~~~~~~~~~~~~~~~~~~~~~ |
| 24 | The device class structure looks like: |
| 25 | |
| 26 | |
| 27 | typedef int (*devclass_add)(struct device *); |
| 28 | typedef void (*devclass_remove)(struct device *); |
| 29 | |
| 30 | struct device_class { |
| 31 | char * name; |
| 32 | rwlock_t lock; |
| 33 | u32 devnum; |
| 34 | struct list_head node; |
| 35 | |
| 36 | struct list_head drivers; |
| 37 | struct list_head intf_list; |
| 38 | |
| 39 | struct driver_dir_entry dir; |
| 40 | struct driver_dir_entry device_dir; |
| 41 | struct driver_dir_entry driver_dir; |
| 42 | |
| 43 | devclass_add add_device; |
| 44 | devclass_remove remove_device; |
| 45 | }; |
| 46 | |
| 47 | A typical device class definition would look like: |
| 48 | |
| 49 | struct device_class input_devclass = { |
| 50 | .name = "input", |
| 51 | .add_device = input_add_device, |
| 52 | .remove_device = input_remove_device, |
| 53 | }; |
| 54 | |
| 55 | Each device class structure should be exported in a header file so it |
| 56 | can be used by drivers, extensions and interfaces. |
| 57 | |
| 58 | Device classes are registered and unregistered with the core using: |
| 59 | |
| 60 | int devclass_register(struct device_class * cls); |
| 61 | void devclass_unregister(struct device_class * cls); |
| 62 | |
| 63 | |
| 64 | Devices |
| 65 | ~~~~~~~ |
| 66 | As devices are bound to drivers, they are added to the device class |
| 67 | that the driver belongs to. Before the driver model core, this would |
| 68 | typically happen during the driver's probe() callback, once the device |
| 69 | has been initialized. It now happens after the probe() callback |
| 70 | finishes from the core. |
| 71 | |
| 72 | The device is enumerated in the class. Each time a device is added to |
| 73 | the class, the class's devnum field is incremented and assigned to the |
| 74 | device. The field is never decremented, so if the device is removed |
| 75 | from the class and re-added, it will receive a different enumerated |
| 76 | value. |
| 77 | |
| 78 | The class is allowed to create a class-specific structure for the |
| 79 | device and store it in the device's class_data pointer. |
| 80 | |
| 81 | There is no list of devices in the device class. Each driver has a |
| 82 | list of devices that it supports. The device class has a list of |
| 83 | drivers of that particular class. To access all of the devices in the |
| 84 | class, iterate over the device lists of each driver in the class. |
| 85 | |
| 86 | |
| 87 | Device Drivers |
| 88 | ~~~~~~~~~~~~~~ |
| 89 | Device drivers are added to device classes when they are registered |
| 90 | with the core. A driver specifies the class it belongs to by setting |
| 91 | the struct device_driver::devclass field. |
| 92 | |
| 93 | |
| 94 | sysfs directory structure |
| 95 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 96 | There is a top-level sysfs directory named 'class'. |
| 97 | |
| 98 | Each class gets a directory in the class directory, along with two |
| 99 | default subdirectories: |
| 100 | |
| 101 | class/ |
| 102 | `-- input |
| 103 | |-- devices |
| 104 | `-- drivers |
| 105 | |
| 106 | |
| 107 | Drivers registered with the class get a symlink in the drivers/ directory |
| 108 | that points to the driver's directory (under its bus directory): |
| 109 | |
| 110 | class/ |
| 111 | `-- input |
| 112 | |-- devices |
| 113 | `-- drivers |
| 114 | `-- usb:usb_mouse -> ../../../bus/drivers/usb_mouse/ |
| 115 | |
| 116 | |
| 117 | Each device gets a symlink in the devices/ directory that points to the |
| 118 | device's directory in the physical hierarchy: |
| 119 | |
| 120 | class/ |
| 121 | `-- input |
| 122 | |-- devices |
| 123 | | `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/ |
| 124 | `-- drivers |
| 125 | |
| 126 | |
| 127 | Exporting Attributes |
| 128 | ~~~~~~~~~~~~~~~~~~~~ |
| 129 | struct devclass_attribute { |
| 130 | struct attribute attr; |
| 131 | ssize_t (*show)(struct device_class *, char * buf, size_t count, loff_t off); |
| 132 | ssize_t (*store)(struct device_class *, const char * buf, size_t count, loff_t off); |
| 133 | }; |
| 134 | |
| 135 | Class drivers can export attributes using the DEVCLASS_ATTR macro that works |
| 136 | similarly to the DEVICE_ATTR macro for devices. For example, a definition |
| 137 | like this: |
| 138 | |
| 139 | static DEVCLASS_ATTR(debug,0644,show_debug,store_debug); |
| 140 | |
| 141 | is equivalent to declaring: |
| 142 | |
| 143 | static devclass_attribute devclass_attr_debug; |
| 144 | |
| 145 | The bus driver can add and remove the attribute from the class's |
| 146 | sysfs directory using: |
| 147 | |
| 148 | int devclass_create_file(struct device_class *, struct devclass_attribute *); |
| 149 | void devclass_remove_file(struct device_class *, struct devclass_attribute *); |
| 150 | |
| 151 | In the example above, the file will be named 'debug' in placed in the |
| 152 | class's directory in sysfs. |
| 153 | |
| 154 | |
| 155 | Interfaces |
| 156 | ~~~~~~~~~~ |
| 157 | There may exist multiple mechanisms for accessing the same device of a |
| 158 | particular class type. Device interfaces describe these mechanisms. |
| 159 | |
| 160 | When a device is added to a device class, the core attempts to add it |
| 161 | to every interface that is registered with the device class. |
| 162 | |