Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | |
| 2 | The Basic Device Structure |
| 3 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 4 | |
Wanlong Gao | 63dc355 | 2011-05-05 07:55:37 +0800 | [diff] [blame] | 5 | See the kerneldoc for the struct device. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 6 | |
| 7 | |
| 8 | Programming Interface |
| 9 | ~~~~~~~~~~~~~~~~~~~~~ |
| 10 | The bus driver that discovers the device uses this to register the |
| 11 | device with the core: |
| 12 | |
| 13 | int device_register(struct device * dev); |
| 14 | |
| 15 | The bus should initialize the following fields: |
| 16 | |
| 17 | - parent |
| 18 | - name |
| 19 | - bus_id |
| 20 | - bus |
| 21 | |
| 22 | A device is removed from the core when its reference count goes to |
| 23 | 0. The reference count can be adjusted using: |
| 24 | |
| 25 | struct device * get_device(struct device * dev); |
| 26 | void put_device(struct device * dev); |
| 27 | |
| 28 | get_device() will return a pointer to the struct device passed to it |
| 29 | if the reference is not already 0 (if it's in the process of being |
| 30 | removed already). |
| 31 | |
| 32 | A driver can access the lock in the device structure using: |
| 33 | |
| 34 | void lock_device(struct device * dev); |
| 35 | void unlock_device(struct device * dev); |
| 36 | |
| 37 | |
| 38 | Attributes |
| 39 | ~~~~~~~~~~ |
| 40 | struct device_attribute { |
Mike Murphy | 245127d | 2009-02-22 01:17:14 -0500 | [diff] [blame] | 41 | struct attribute attr; |
| 42 | ssize_t (*show)(struct device *dev, struct device_attribute *attr, |
| 43 | char *buf); |
| 44 | ssize_t (*store)(struct device *dev, struct device_attribute *attr, |
| 45 | const char *buf, size_t count); |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 46 | }; |
| 47 | |
| 48 | Attributes of devices can be exported via drivers using a simple |
| 49 | procfs-like interface. |
| 50 | |
| 51 | Please see Documentation/filesystems/sysfs.txt for more information |
| 52 | on how sysfs works. |
| 53 | |
| 54 | Attributes are declared using a macro called DEVICE_ATTR: |
| 55 | |
| 56 | #define DEVICE_ATTR(name,mode,show,store) |
| 57 | |
| 58 | Example: |
| 59 | |
| 60 | DEVICE_ATTR(power,0644,show_power,store_power); |
| 61 | |
| 62 | This declares a structure of type struct device_attribute named |
| 63 | 'dev_attr_power'. This can then be added and removed to the device's |
| 64 | directory using: |
| 65 | |
| 66 | int device_create_file(struct device *device, struct device_attribute * entry); |
| 67 | void device_remove_file(struct device * dev, struct device_attribute * attr); |
| 68 | |
| 69 | Example: |
| 70 | |
| 71 | device_create_file(dev,&dev_attr_power); |
| 72 | device_remove_file(dev,&dev_attr_power); |
| 73 | |
| 74 | The file name will be 'power' with a mode of 0644 (-rw-r--r--). |
| 75 | |
Grant Likely | b22813b | 2009-03-06 14:05:39 -0700 | [diff] [blame] | 76 | Word of warning: While the kernel allows device_create_file() and |
| 77 | device_remove_file() to be called on a device at any time, userspace has |
| 78 | strict expectations on when attributes get created. When a new device is |
| 79 | registered in the kernel, a uevent is generated to notify userspace (like |
| 80 | udev) that a new device is available. If attributes are added after the |
| 81 | device is registered, then userspace won't get notified and userspace will |
| 82 | not know about the new attributes. |
| 83 | |
| 84 | This is important for device driver that need to publish additional |
| 85 | attributes for a device at driver probe time. If the device driver simply |
| 86 | calls device_create_file() on the device structure passed to it, then |
| 87 | userspace will never be notified of the new attributes. Instead, it should |
| 88 | probably use class_create() and class->dev_attrs to set up a list of |
| 89 | desired attributes in the modules_init function, and then in the .probe() |
| 90 | hook, and then use device_create() to create a new device as a child |
| 91 | of the probed device. The new device will generate a new uevent and |
| 92 | properly advertise the new attributes to userspace. |
| 93 | |
| 94 | For example, if a driver wanted to add the following attributes: |
| 95 | struct device_attribute mydriver_attribs[] = { |
| 96 | __ATTR(port_count, 0444, port_count_show), |
| 97 | __ATTR(serial_number, 0444, serial_number_show), |
| 98 | NULL |
| 99 | }; |
| 100 | |
| 101 | Then in the module init function is would do: |
| 102 | mydriver_class = class_create(THIS_MODULE, "my_attrs"); |
| 103 | mydriver_class.dev_attr = mydriver_attribs; |
| 104 | |
| 105 | And assuming 'dev' is the struct device passed into the probe hook, the driver |
| 106 | probe function would do something like: |
Robert P. J. Day | b6baddd | 2011-05-28 19:11:39 -0400 | [diff] [blame] | 107 | device_create(&mydriver_class, dev, chrdev, &private_data, "my_name"); |