電子發燒友App
1. 前言
device和device driver是Linux驅動開發的基本概念。Linux kernel的思路很簡單：驅動開發，就是要開發指定的軟件（driver）以驅動指定的設備，所以kernel就為設備和驅動它的driver定義了兩個數據結構，分別是device和device_driver。因此本文將會圍繞這兩個數據結構，介紹Linux設備模型的核心邏輯，包括：
設備及設備驅動在kernel中的抽象、使用和維護；
設備及設備驅動的注冊、加載、初始化原理；
設備模型在實際驅動開發過程中的使用方法。
注：在介紹device和device_driver的過程中，會遇到很多額外的知識點，如Class、Bus、DMA、電源管理等等，這些知識點都很復雜，任何一個都可以作為一個單獨的專題區闡述，因此本文不會深入解析它們，而會在后續的文章中專門描述。
2. struct device和struct device_driver
在閱讀Linux內核源代碼時，通過核心數據結構，即可理解某個模塊60%以上的邏輯，設備模型部分尤為明顯。
在include/linux/device.h中，Linux內核定義了設備模型中最重要的兩個數據結構，struct device和struct device_driver。
struct device
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:1??
class，該設備屬于哪個class。
groups，該設備的默認attribute集合。將會在設備注冊時自動在sysfs中創建對應的文件。
struct device_driver
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的時機有如下幾種（分為自動觸發和手動觸發）：
將struct device類型的變量注冊到內核中時自動觸發（device_register，device_add，device_create_vargs，device_create）
將struct device_driver類型的變量注冊到內核中時自動觸發（driver_register）
手動查找同一bus下的所有device_driver，如果有和指定device同名的driver，執行probe操作（device_attach）
手動查找同一bus下的所有device，如果有和指定driver同名的device，執行probe操作（driver_attach）
自行調用driver的probe接口，并在該接口中將該driver綁定到某個device結構中----即設置dev->driver（device_bind_driver）
注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的設備，這是之一）。
?
工商網監
評論