~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~ [ freetext search ] ~ [ file search ] ~

Linux Cross Reference
Linux-2.6.17/Documentation/driver-model/class.txt

Version: ~ [ 2.6.16 ] ~ [ 2.6.17 ] ~
Architecture: ~ [ ia64 ] ~ [ i386 ] ~ [ arm ] ~ [ ppc ] ~ [ sparc64 ] ~

  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 

~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~ [ freetext search ] ~ [ file search ] ~

This page was automatically generated by the LXR engine.
Visit the LXR main site for more information.