^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ==========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) The Basic Device Structure
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ==========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) See the kerneldoc for the struct device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) Programming Interface
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) ~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) The bus driver that discovers the device uses this to register the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) device with the core::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) int device_register(struct device * dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) The bus should initialize the following fields:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) - parent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) - name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) - bus_id
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) - bus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) A device is removed from the core when its reference count goes to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) 0. The reference count can be adjusted using::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) struct device * get_device(struct device * dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) void put_device(struct device * dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) get_device() will return a pointer to the struct device passed to it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) if the reference is not already 0 (if it's in the process of being
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) removed already).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) A driver can access the lock in the device structure using::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) void lock_device(struct device * dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) void unlock_device(struct device * dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) Attributes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) ~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) struct device_attribute {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) struct attribute attr;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) ssize_t (*show)(struct device *dev, struct device_attribute *attr,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) char *buf);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) ssize_t (*store)(struct device *dev, struct device_attribute *attr,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) const char *buf, size_t count);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) Attributes of devices can be exported by a device driver through sysfs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) Please see Documentation/filesystems/sysfs.rst for more information
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) on how sysfs works.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) As explained in Documentation/core-api/kobject.rst, device attributes must be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) created before the KOBJ_ADD uevent is generated. The only way to realize
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) that is by defining an attribute group.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) Attributes are declared using a macro called DEVICE_ATTR::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) #define DEVICE_ATTR(name,mode,show,store)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) Example:::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) static DEVICE_ATTR(type, 0444, show_type, NULL);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) static DEVICE_ATTR(power, 0644, show_power, store_power);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) This declares two structures of type struct device_attribute with respective
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) names 'dev_attr_type' and 'dev_attr_power'. These two attributes can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) organized as follows into a group::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) static struct attribute *dev_attrs[] = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) &dev_attr_type.attr,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) &dev_attr_power.attr,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) NULL,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) static struct attribute_group dev_attr_group = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) .attrs = dev_attrs,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) static const struct attribute_group *dev_attr_groups[] = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) &dev_attr_group,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) NULL,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) This array of groups can then be associated with a device by setting the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) group pointer in struct device before device_register() is invoked::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) dev->groups = dev_attr_groups;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) device_register(dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) The device_register() function will use the 'groups' pointer to create the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) device attributes and the device_unregister() function will use this pointer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) to remove the device attributes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) Word of warning: While the kernel allows device_create_file() and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) device_remove_file() to be called on a device at any time, userspace has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) strict expectations on when attributes get created. When a new device is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) registered in the kernel, a uevent is generated to notify userspace (like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) udev) that a new device is available. If attributes are added after the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) device is registered, then userspace won't get notified and userspace will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) not know about the new attributes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) This is important for device driver that need to publish additional
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) attributes for a device at driver probe time. If the device driver simply
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) calls device_create_file() on the device structure passed to it, then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) userspace will never be notified of the new attributes.