1. 前言
#在Linux驅動程式開發中，device和device driver是基本概念。 Kernel的核心想法就是為裝置和其驅動程式分別定義device和device_driver兩個資料結構，本文將圍繞這兩個資料結構，介紹Linux裝置模型的核心邏輯，包括：
要注意的是，在介紹device和device_driver的過程中，可能會涉及許多其他知識點，如Class、Bus、DMA、電源管理等等。這些知識點都非常複雜，任意一個都可以當作一個單獨的專題來闡述。因此，本文不會深入解析它們，而會在後續的文章中專門介紹。
2. struct device和struct device_driver
在閱讀Linux核心原始碼時，透過核心資料結構，即可理解某個模組60%以上的邏輯，裝置模型部分尤為明顯。
在include/linux/device.h中，Linux核心定義了裝置模型中最重要的兩個資料結構，struct device和struct device_driver。
1: /* include/linux/device.h, line 660 */
2: struct device {
3: struct device *parent;
4:
5: struct device_private *p;
6:
7: struct kobject kobj;
8: const char *init_name; /* initial name of the device */
9: const struct device_type *type;
10:
11: struct mutex mutex; /* mutex to synchronize calls to
12: * its driver.
13: */
14:
15: struct bus_type *bus; /* type of bus device is on */
16: struct device_driver *driver; /* which driver has allocated this
17: device */
18: void *platform_data; /* Platform specific data, device
19: core doesn't touch it */
20: struct dev_pm_info power;
21: struct dev_pm_domain *pm_domain;
22:
23: #ifdef CONFIG_PINCTRL
24: struct dev_pin_info *pins;
25: #endif
26:
27: #ifdef CONFIG_NUMA
28: int numa_node; /* NUMA node this device is close to */
29: #endif
30: u64 *dma_mask; /* dma mask (if dma'able device) */
31: u64 coherent_dma_mask;/* Like dma_mask, but for
32: alloc_coherent mappings as
33: not all hardware supports
34: 64 bit addresses for consistent
35: allocations such descriptors. */
36:
37: struct device_dma_parameters *dma_parms;
38:
39: struct list_head dma_pools; /* dma pools (if dma'ble) */
40:
41: struct dma_coherent_mem *dma_mem; /* internal for coherent mem
42: override */
43: #ifdef CONFIG_CMA
44: struct cma *cma_area; /* contiguous memory area for dma
45: allocations */
46: #endif
47: /* arch specific additions */
48: struct dev_archdata archdata;
49:
50: struct device_node *of_node; /* associated device tree node */
51: struct acpi_dev_node acpi_node; /* associated ACPI device node */
52:
53: dev_t devt; /* dev_t, creates the sysfs "dev" */
54: u32 id; /* device instance */
55:
56: spinlock_t devres_lock;
57: struct list_head devres_head;
58:
59: struct klist_node knode_class;
60: struct class *class;
61: const struct attribute_group **groups; /* optional groups */
62:
63: void (*release)(struct device *dev);
64: struct iommu_group *iommu_group;
65: };
「
#device結構很複雜（不過linux核心的開發人員素質是很高的，該介面的註解寫的非常詳細，有興趣的同學可以參考核心原始碼），這裡將會選一些對理解裝置模型非常關鍵的字段進行說明。
parent，該設備的父親設備，一般是該設備所從屬的bus、controller等設備。
p，一個用於struct device的私有資料結構指針，該指標中會保存子設備鍊錶、用於添加到bus/driver/prent等設備中的鍊錶頭等等，具體可查看原始程式碼。
kobj，該資料結構對應的struct kobject。
init_name，該裝置的名稱。
註1：在設備模型中，名稱是一個非常重要的變量，任何註冊到核心中的設備，都必須有一個合法的名稱，可以在初始化時給出，也可以由核心根據「bus name device ID」的方式創造。
type，struct device_type結構是新版核心新引入的結構，它和struct device關係，非常類似stuct kobj_type和struct kobject之間的關係，後續會再詳細說明。
bus，該device屬於哪個匯流排（後續會詳細描述）。
driver，該device對應的device driver。
platform_data，一個指針，用來保存特定的平台相關的資料。具體的driver模組，可以將一些私有的數據，暫存在這裡，需要使用的時候，再拿出來，因此設備模型並不關心該指針得實際意義。
power、pm_domain，電源管理相關的邏輯，後續會由電源管理專題來講解。
pins，”PINCTRL”功能，暫不描述。
numa_node，”NUMA」功能，暫不描述。
dma_mask~archdata，DMA相關的功能，暫不描述。
devt，dev_t是一個32位元的整數，它由兩個部分（Major和Minor）組成，在需要以裝置節點的形式（字元裝置和區塊裝置）向使用者空間提供介面的裝置中，當作設備號使用。在這裡，該變數主要用於在sys檔案系統中，為每個具有裝置號碼的device，建立/sys/dev/* 下的對應目錄，如下：
1|root@android:/storage/sdcard0 #ls /sys/dev/char/1:
1:1/ 1:11/ 1:13/ 1:14/ 1:2/ 1:3/ 1:5/ 1:7/ 1:8/ 1:9/
1|root@android:/storage/sdcard0 #ls /sys/dev/char/1:1
1:1/ 1:11/ 1:13/ 1:14/
1|root@android:/storage/sdcard0 # ls /sys/dev/char/1:1
# /sys/dev/char/1:1class，該設備屬於哪個class。
groups，該裝置的預設attribute集合。將會在設備註冊時自動在sysfs中建立對應的檔案。
”
1: /* include/linux/device.h, line 213 */
2: struct device_driver {
3: const char *name;
4: struct bus_type *bus;
5:
6: struct module *owner;
7: const char *mod_name; /* used for built-in modules */
8:
9: bool suppress_bind_attrs; /* disables bind/unbind via sysfs */
10:
11: const struct of_device_id *of_match_table;
12: const struct acpi_device_id *acpi_match_table;
13:
14: int (*probe) (struct device *dev);
15: int (*remove) (struct device *dev);
16: void (*shutdown) (struct device *dev);
17: int (*suspend) (struct device *dev, pm_message_t state);
18: int (*resume) (struct device *dev);
19: const struct attribute_group **groups;
20:
21: const struct dev_pm_ops *pm;
22:
23: struct driver_private *p;
24: };
“
device_driver就简单多了（在早期的内核版本中driver的数据结构为”struct driver”，不知道从哪个版本开始，就改成device_driver了）：
name，该driver的名称。和device结构一样，该名称非常重要，后面会再详细说明。
bus，该driver所驱动设备的总线设备。为什么driver需要记录总线设备的指针呢？因为内核要保证在driver运行前，设备所依赖的总线能够正确初始化。
owner、mod_name，內核module相关的变量，暂不描述。
suppress_bind_attrs，是不在sysfs中启用bind和unbind attribute，如下：root@android:/storage/sdcard0 # ls /sys/bus/platform/drivers/switch-gpio/
bind uevent unbind
在kernel中，bind/unbind是从用户空间手动的为driver绑定/解绑定指定的设备的机制。这种机制是在bus.c中完成的，后面会详细解释。probe、remove，这两个接口函数用于实现driver逻辑的开始和结束。Driver是一段软件code，因此会有开始和结束两个代码逻辑，就像PC程序，会有一个main函数，main函数的开始就是开始，return的地方就是结束。而内核driver却有其特殊性：在设备模型的结构下，只有driver和device同时存在时，才需要开始执行driver的代码逻辑。这也是probe和remove两个接口名称的由来：检测到了设备和移除了设备（就是为热拔插起的！）。
shutdown、suspend、resume、pm，电源管理相关的内容，会在电源管理专题中详细说明。
groups，和struct device结构中的同名变量类似，driver也可以定义一些默认attribute，这样在将driver注册到内核中时，内核设备模型部分的代码（driver/base/driver.c）会自动将这些attribute添加到sysfs中。
p，私有数据的指针，具体的driver代码可以把任何需要的内容放在这里，反正设备模型代码不关心。
”
3. 设备模型框架下驱动开发的基本步骤
在设备模型框架下，设备驱动的开发是一件很简单的事情，主要包括2个步骤：
步骤1：分配一个struct device类型的变量，填充必要的信息后，把它注册到内核中。
步骤2：分配一个struct device_driver类型的变量，填充必要的信息后，把它注册到内核中。
这两步完成后，内核会在合适的时机（后面会讲），调用struct device_driver变量中的probe、remove、suspend、resume等回调函数，从而触发或者终结设备驱动的执行。而所有的驱动程序逻辑，都会由这些回调函数实现，此时，驱动开发者眼中便不再有“设备模型”，转而只关心驱动本身的实现。
“
以上两个步骤的补充说明：
\1. 一般情况下，Linux驱动开发很少直接使用device和device_driver，因为内核在它们之上又封装了一层，如soc device、platform device等等，而这些层次提供的接口更为简单、易用（也正是因为这个原因，本文并不会过多涉及device、device_driver等模块的实现细节）。
\2. 内核提供很多struct device结构的操作接口（具体可以参考include/linux/device.h和drivers/base/core.c的代码），主要包括初始化（device_initialize）、注册到内核（device_register）、分配存储空间+初始化+注册到内核（device_create）等等，可以根据需要使用。
\3. device和device_driver必须具备相同的名称，内核才能完成匹配操作，进而调用device_driver中的相应接口。这里的同名，作用范围是同一个bus下的所有device和device_driver。
\4. device和device_driver必须挂载在一个bus之下，该bus可以是实际存在的，也可以是虚拟的。
\5. driver开发者可以在struct device变量中，保存描述设备特征的信息，如寻址空间、依赖的GPIOs等，因为device指针会在执行probe等接口时传入，这时driver就可以根据这些信息，执行相应的逻辑操作了。
”
4. 设备驱动probe的时机
所谓的”probe”，是指在Linux内核中，如果存在相同名称的device和device_driver（注：还存在其它方式，我们先不关注了），内核就会执行device_driver中的probe回调函数，而该函数就是所有driver的入口，可以执行诸如硬件设备初始化、字符设备注册、设备文件操作ops注册等动作（”remove”是它的反操作，发生在device或者device_driver任何一方从内核注销时，其原理类似，就不再单独说明了）。
设备驱动prove的时机有如下几种（分为自动触发和手动触发）：
“
注2：probe动作实际是由bus模块（会在下一篇文章讲解）实现的，这不难理解：device和device_driver都是挂载在bus这根线上，因此只有bus最清楚应该为哪些device、哪些driver配对。
注3：每个bus都有一个drivers_autoprobe变量，用于控制是否在device或者driver注册时，自动probe。该变量默认为1（即自动probe），bus模块将它开放到sysfs中了，因而可在用户空间修改，进而控制probe行为。
”
5. 其它杂项
5.1 device_attribute和driver_attribute
在”Linux设备模型(4)_sysfs”中，我们有讲到，大多数时候，attribute文件的读写数据流为：vfs—->sysfs—->kobject—->attibute—->kobj_type—->sysfs_ops—->xxx_attribute，其中kobj_type、sysfs_ops和xxx_attribute都是由包含kobject的上层数据结构实现。
Linux内核中关于该内容的例证到处都是，device也不无例外的提供了这种例子，如下：
1: /* driver/base/core.c, line 118 */
2: static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr,
3: char *buf)
4: {
5: struct device_attribute *dev_attr = to_dev_attr(attr);
6: struct device *dev = kobj_to_dev(kobj);
7: ssize_t ret = -EIO;
8:
9: if (dev_attr->show)
10: ret = dev_attr->show(dev, dev_attr, buf);
11: if (ret >= (ssize_t)PAGE_SIZE) {
12: print_symbol("dev_attr_show: %s returned bad count\n",
13: (unsigned long)dev_attr->show);
14: }
15: return ret;
16: }
17:
18: static ssize_t dev_attr_store(struct kobject *kobj, struct attribute *attr,
19: const char *buf, size_t count)
20: {
21: struct device_attribute *dev_attr = to_dev_attr(attr);
22: struct device *dev = kobj_to_dev(kobj);
23: ssize_t ret = -EIO;
24:
25: if (dev_attr->store)
26: ret = dev_attr->store(dev, dev_attr, buf, count);
27: return ret;
28: }
29:
30: static const struct sysfs_ops dev_sysfs_ops = {
31: .show = dev_attr_show,
32: .store = dev_attr_store,
33: };
34:
35: /* driver/base/core.c, line 243 */
36: static struct kobj_type device_ktype = {
37: .release = device_release,
38: .sysfs_ops = &dev_sysfs_ops,
39: .namespace = device_namespace,
40: };
41:
42: /* include/linux/device.h, line 478 */
43: /* interface for exporting device attributes */
44: struct device_attribute {
45: struct attribute attr;
46: ssize_t (*show)(struct device *dev, struct device_attribute *attr,
47: char *buf);
48: ssize_t (*store)(struct device *dev, struct device_attribute *attr,
49: const char *buf, size_t count);
50: };
至于driver的attribute，则要简单的多，其数据流为：vfs—->sysfs—->kobject—->attribute—->driver_attribute，如下：
1: /* include/linux/device.h, line 247 */
2: /* sysfs interface for exporting driver attributes */
3:
4: struct driver_attribute {
5: struct attribute attr;
6: ssize_t (*show)(struct device_driver *driver, char *buf);
7: ssize_t (*store)(struct device_driver *driver, const char *buf,
8: size_t count);
9: };
10:
11: #define DRIVER_ATTR(_name, _mode, _show, _store) \
12: struct driver_attribute driver_attr_##_name = \
13: __ATTR(_name, _mode, _show, _store)
5.2 device_type
device_type是内嵌在struct device结构中的一个数据结构，用于指明设备的类型，并提供一些额外的辅助功能。它的的形式如下：
1: /* include/linux/device.h, line 467 */
2: struct device_type {
3: const char *name;
4: const struct attribute_group **groups;
5: int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
6: char *(*devnode)(struct device *dev, umode_t *mode,
7: kuid_t *uid, kgid_t *gid);
8: void (*release)(struct device *dev);
9:
10: const struct dev_pm_ops *pm;
11: };
“
device_type的功能包括：
- name表示该类型的名称，当该类型的设备添加到内核时，内核会发出”DEVTYPE=‘name’”类型的uevent，告知用户空间某个类型的设备available了
- groups，该类型设备的公共attribute集合。设备注册时，会同时注册这些attribute。这就是面向对象中“继承”的概念
- uevent，同理，所有相同类型的设备，会有一些共有的uevent需要发送，由该接口实现
- devnode，devtmpfs有关的内容，暂不说明
- release，如果device结构没有提供release接口，就要查询它所属的type是否提供。用于释放device变量所占的空间
”
5.3 root device
在sysfs中有这样一个目录：/sys/devices，系统中所有的设备，都归集在该目录下。有些设备，是通过device_register注册到Kernel并体现在/sys/devices/xxx/下。但有时候我们仅仅需要在/sys/devices/下注册一个目录，该目录不代表任何的实体设备，这时可以使用下面的接口：
1: /* include/linux/device.h, line 859 */ 2: /* 3: * Root device objects for grouping under /sys/devices 4: */ 5: extern struct device *__root_device_register(const char *name, 6: struct module *owner); 7: 8: /* 9: * This is a macro to avoid include problems with THIS_MODULE, 10: * just as per what is done for device_schedule_callback() above. 11: */ 12: #define root_device_register(name) \ 13: __root_device_register(name, THIS_MODULE) 14: 15: extern void root_device_unregister(struct device *root);
该接口会调用device_register函数，向内核中注册一个设备，但是（你也想到了），没必要注册与之对应的driver（顺便提一下，内核中有很多不需要driver的设备，这是之一）。
以上是Linux設備模型(5)_device和device driver的詳細內容。更多資訊請關注PHP中文網其他相關文章！
