寫明白一個(gè)底層機(jī)制往往比寫下十層業(yè)務(wù)邏輯更有價(jià)值。Linux 設(shè)備驅(qū)動(dòng)模型就是這樣一類東西它不像進(jìn)程調(diào)度、內(nèi)存管理那樣“顯眼”但無(wú)論是嵌入式開(kāi)發(fā)、內(nèi)核驅(qū)動(dòng)編寫還是系統(tǒng)穩(wěn)定性排查你繞不開(kāi)它。很多時(shí)候你覺(jué)得驅(qū)動(dòng)“莫名其妙”不工作或者設(shè)備節(jié)點(diǎn)時(shí)有時(shí)無(wú)根子都在設(shè)備模型這一層。這篇文章不堆概念我把我從看源碼到實(shí)際改驅(qū)動(dòng)、調(diào)硬件過(guò)程中對(duì)設(shè)備驅(qū)動(dòng)模型的理解從頭到尾拆一遍。如果你是想搞懂內(nèi)核底層的開(kāi)發(fā)者不管你是做嵌入式 Linux、內(nèi)核驅(qū)動(dòng)還是上層應(yīng)用想深入理解sysfs、uevent、設(shè)備熱插拔背后的原理這篇文章都值得你花點(diǎn)時(shí)間。設(shè)備模型不是一塊孤立的“知識(shí)”它是連接內(nèi)核各子系統(tǒng)、暴露硬件拓?fù)浣o用戶態(tài)的樞紐。1. 設(shè)備驅(qū)動(dòng)模型到底在解決什么問(wèn)題——三個(gè)關(guān)鍵詞講清楚很多人一上來(lái)就背struct device、struct device_driver、struct bus_type背完還是懵因?yàn)椴恢肋@些東西到底解決什么問(wèn)題。我們先退一步想想內(nèi)核在沒(méi)有這套模型之前是什么狀態(tài)。早期內(nèi)核里寫一個(gè)驅(qū)動(dòng)基本是“直接干活”驅(qū)動(dòng)初始化時(shí)申請(qǐng)中斷號(hào)、映射 IO 地址、注冊(cè)字符設(shè)備、建/dev節(jié)點(diǎn)。聽(tīng)起來(lái)也沒(méi)啥不行但系統(tǒng)一復(fù)雜就亂了。第一個(gè)關(guān)鍵詞資源沖突。同一個(gè)物理中斷號(hào)可不能被八個(gè)驅(qū)動(dòng)同時(shí)請(qǐng)求同一段 IO 地址你映射我也映射誰(shuí)來(lái)仲裁第二個(gè)關(guān)鍵詞熱插拔與動(dòng)態(tài)加載。USB、SD 卡這些設(shè)備都是中途插進(jìn)來(lái)的內(nèi)核怎么知道該把這個(gè)新設(shè)備交給哪個(gè)驅(qū)動(dòng)第三個(gè)關(guān)鍵詞用戶態(tài)視角。應(yīng)用層ls /sys/class/或者udevadm info為什么能查出設(shè)備的層級(jí)關(guān)系這背后總得有一個(gè)組織良好的對(duì)象模型。設(shè)備驅(qū)動(dòng)模型就是內(nèi)核為回答這三個(gè)問(wèn)題搭建的“中間層”和“調(diào)度室”。它不是某一個(gè)具體驅(qū)動(dòng)的功能而是驅(qū)動(dòng)框架的公共服務(wù)。你可以把它理解成一套“內(nèi)核內(nèi)部的登記與查詢系統(tǒng)”所有的設(shè)備、驅(qū)動(dòng)、總線都在這個(gè)系統(tǒng)里注冊(cè)、匹配、綁定然后向用戶態(tài)暴露統(tǒng)一接口。這套模型的核心對(duì)象就四個(gè)device設(shè)備、device_driver(驅(qū)動(dòng))、bus_type總線、class類。你記住一句話就夠了——總線上掛著設(shè)備和驅(qū)動(dòng)總線的職責(zé)是讓它們“配對(duì)”配對(duì)成功后驅(qū)動(dòng)負(fù)責(zé)操作設(shè)備設(shè)備通過(guò) class 向用戶態(tài)“拋頭露面”。2. device/driver/bus/class 四件套設(shè)備、驅(qū)動(dòng)、總線、類各自干啥這四件套是設(shè)備模型的骨架。我建議你從這四個(gè)結(jié)構(gòu)體本身入手去理解不要跳過(guò)struct的定義直接去看 API那樣永遠(yuǎn)是浮在表面。2.1 struct device一個(gè)設(shè)備在內(nèi)核里的“身份證”struct device是整個(gè)模型最底層的抽象它是“一個(gè)硬件設(shè)備”在內(nèi)核中的表示。這里要特別注意device只管“設(shè)備本身是什么”不管“怎么操作它”。struct device { struct device *parent; // 誰(shuí)生了我父設(shè)備 struct device_private *p; // 私有的、不對(duì)外的數(shù)據(jù) struct kobject kobj; // 所有 sysfs 表現(xiàn)的基礎(chǔ) const char *init_name; // 設(shè)備在 sysfs 里的名字 struct bus_type *bus; // 掛在哪個(gè)總線上 struct device_driver *driver; // 配對(duì)成功的驅(qū)動(dòng) void *platform_data; void *driver_data; // 驅(qū)動(dòng)自定義私有數(shù)據(jù)常用 dev_t devt; // 設(shè)備號(hào)用于創(chuàng)建設(shè)備節(jié)點(diǎn) ... }這個(gè)結(jié)構(gòu)體里最關(guān)鍵的幾個(gè)問(wèn)題parent表示設(shè)備在拓?fù)浣Y(jié)構(gòu)中的位置比如 USB 設(shè)備掛在 USB 控制器下面bus指向它所在的總線類型driver一旦被賦值就說(shuō)明這個(gè)設(shè)備已經(jīng)被“認(rèn)領(lǐng)”了devt是設(shè)備號(hào)有了設(shè)備號(hào)device_create()才能生成/dev節(jié)點(diǎn)。還有一個(gè)非常容易踩坑的點(diǎn)release回調(diào)函數(shù)。struct device里有個(gè)release函數(shù)指針?biāo)谠O(shè)備引用計(jì)數(shù)歸零時(shí)被調(diào)用用來(lái)釋放設(shè)備占用的內(nèi)存。如果你自己動(dòng)態(tài)kzalloc了一個(gè)device并device_register注冊(cè)它而沒(méi)有初始化release內(nèi)核在注銷時(shí)會(huì)直接報(bào)錯(cuò)并崩潰。這個(gè)我在第 8 章會(huì)再展開(kāi)。2.2 struct device_driver驅(qū)動(dòng)只是“能力的聲明”驅(qū)動(dòng)對(duì)象struct device_driver同樣掛在內(nèi)核的對(duì)象系統(tǒng)里但它本身不包含“操作函數(shù)”它的核心是聲明自己能匹配哪些設(shè)備以及匹配成功后如何初始化/釋放。struct device_driver { const char *name; struct bus_type *bus; const struct of_device_id *of_match_table; int (*probe)(struct device *dev); // 匹配成功后被調(diào)用 void (*remove)(struct device *dev); // 設(shè)備被移除時(shí)調(diào)用 const struct dev_pm_ops *pm; // 電源管理 ... }驅(qū)動(dòng)本身不干活真正干活的是probe函數(shù)。所謂“寫驅(qū)動(dòng)”本質(zhì)上是填好probe和remove在probe里把硬件初始化、注冊(cè)中斷、建立數(shù)據(jù)通路然后把操作接口暴露給用戶態(tài)。你可能會(huì)問(wèn)那讀寫函數(shù)read/write呢那不叫device_driver那是file_operations是字符設(shè)備層的事。設(shè)備驅(qū)動(dòng)模型管的是“設(shè)備與驅(qū)動(dòng)匹配”這件事數(shù)據(jù)通路是匹配成功之后注冊(cè)到具體子系統(tǒng)里的。先有匹配后有業(yè)務(wù)。2.3 struct bus_type總線不是物理線是“匹配中介”這是最容易誤解的地方。bus_type不是指 PCB 上的線而是內(nèi)核定義的一種“聚合與匹配規(guī)則”。struct bus_type { const char *name; int (*match)(struct device *dev, struct device_driver *drv); int (*probe)(struct device *dev); int (*remove)(struct device *dev); struct device_attribute *dev_attrs; ... }內(nèi)核里最典型的就是platform_bus_type這是一個(gè)虛擬總線叫platform。它專門用來(lái)掛載那些不依附于 USB、PCI、I2C 等物理總線的設(shè)備——比如 SoC 內(nèi)部的 UART、GPIO 控制器、以太網(wǎng) MAC。你會(huì)發(fā)現(xiàn)在/sys/bus/platform/devices/下面躺著大量 SoC 內(nèi)部外設(shè)這就是虛擬總線把所有“板級(jí)設(shè)備”統(tǒng)一管理起來(lái)的實(shí)例。總線的match函數(shù)是配對(duì)規(guī)則的裁判。platform_bus的配對(duì)順序我在下一章詳細(xì)拆這里你先記住設(shè)備想要被驅(qū)動(dòng)找到必須先掛到總線上驅(qū)動(dòng)想找設(shè)備也得先注冊(cè)到同一個(gè)總線上。兩頭缺一頭永遠(yuǎn)配不上。2.4 struct class給設(shè)備“分類”讓用戶態(tài)看得懂class解決的是“用戶態(tài)視角”問(wèn)題。一個(gè)設(shè)備硬件上在某個(gè)總線上但從應(yīng)用層的角度看你更關(guān)心它是一個(gè)輸入設(shè)備、一個(gè)網(wǎng)絡(luò)設(shè)備還是一個(gè) LED而不是它掛在哪條總線上。struct class { const char *name; struct module *owner; ... }class_create()會(huì)在/sys/class/下創(chuàng)建一個(gè)以類名命名的目錄device_create()則在這個(gè)類目錄下創(chuàng)建一個(gè)設(shè)備子目錄并生成/dev節(jié)點(diǎn)。比如你寫一個(gè) GPIO LED 驅(qū)動(dòng)通常會(huì)class_create(led_class)然后device_create(led_class, ...)于是/dev/led出現(xiàn)應(yīng)用層直接 open/write。這就是設(shè)備模型向用戶態(tài)“拋頭露面”的標(biāo)準(zhǔn)路徑。很多驅(qū)動(dòng)開(kāi)發(fā)者把class僅僅當(dāng)成“創(chuàng)建設(shè)備節(jié)點(diǎn)的工具”這么理解不算錯(cuò)但要知道它本質(zhì)是設(shè)備模型的一部分是用戶態(tài) sidecar。3. 設(shè)備與驅(qū)動(dòng)怎么“配對(duì)”match 機(jī)制與匹配優(yōu)先級(jí)設(shè)備模型的核心操作就是“配對(duì)”。每一次device_register()或driver_register()的發(fā)生內(nèi)核都會(huì)觸發(fā)一次總線掃描看新來(lái)的這個(gè)家伙能不能和已有對(duì)象配對(duì)成功。以platform總線為例platform_match()是配對(duì)的實(shí)際執(zhí)行者。它按下面的順序依次嘗試誰(shuí)先命中算誰(shuí)的設(shè)備樹(shù)匹配of_driver_match_device()。它會(huì)比較設(shè)備樹(shù)節(jié)點(diǎn)里的compatible字符串和驅(qū)動(dòng)的of_match_table中的.compatible。這是現(xiàn)代 ARM/ARM64/RISC-V 平臺(tái)最主流的匹配方式。ACPI 匹配acpi_driver_match_device()。在 x86 和某些服務(wù)器平臺(tái)上固件用 ACPI 表描述硬件匹配邏輯走的是 ACPI 路徑。ID 表匹配driver_match_device()會(huì)查找驅(qū)動(dòng)里的id_table。比如 I2C 驅(qū)動(dòng)有i2c_device_idSPI 驅(qū)動(dòng)有spi_device_id。對(duì)于 platform 驅(qū)動(dòng)platform_driver中也有id_table里面保存的是設(shè)備的name。設(shè)備名/驅(qū)動(dòng)名匹配platform_match_id()如果都沒(méi)命中內(nèi)核會(huì)直接比較driver-driver.name和platform_device-name是否一致。很多早期 platform 驅(qū)動(dòng)就是這么干的現(xiàn)在仍然兼容。這個(gè)順序非常重要。你在調(diào)試時(shí)如果發(fā)現(xiàn)“明明 compatible 不一致驅(qū)動(dòng)還是 probe 了”很可能就是第 4 步的 name 匹配兜底了反過(guò)來(lái)你要想確認(rèn)設(shè)備是通過(guò)哪種方式匹配上的可以在probe里打印dev-driver或者用ls /sys/bus/platform/devices/.../driver看驅(qū)動(dòng)符號(hào)鏈接是否存在。我當(dāng)初調(diào)一個(gè)傳感器驅(qū)動(dòng)DTS 里的compatible寫成了vendor,sensor-v1驅(qū)動(dòng)of_match_table里寫的是vendor,sensor-v2。按我的預(yù)期是匹配失敗結(jié)果驅(qū)動(dòng)照樣 probe。查了很久才發(fā)現(xiàn)驅(qū)動(dòng)內(nèi)嵌的 platform_driver 的.name和 platform_device 的name恰好一致走了第 4 步。你以為的設(shè)備樹(shù)匹配實(shí)際是 name 兜底匹配。這不算 bug但確實(shí)容易讓人誤判。還有一個(gè)概念叫-EPROBE_DEFER全稱是 probe defer推遲探測(cè)。當(dāng)一個(gè)設(shè)備的 probe 依賴另一個(gè)設(shè)備比如依賴某個(gè) regulator、某個(gè)時(shí)鐘或者某個(gè) GPIO 控制器而依賴對(duì)象還沒(méi)就緒時(shí)驅(qū)動(dòng)返回-EPROBE_DEFER內(nèi)核不會(huì)報(bào)錯(cuò)而是把這個(gè)設(shè)備扔回隊(duì)列等下次有驅(qū)動(dòng)注冊(cè)時(shí)再嘗試。這是設(shè)備模型里最優(yōu)雅的機(jī)制之一。沒(méi)有它你要自己寫依賴排序麻煩得多。static int my_probe(struct platform_device *pdev) { struct clk *clk devm_clk_get(pdev-dev, axi); if (IS_ERR(clk)) { if (PTR_ERR(clk) -EPROBE_DEFER) return -EPROBE_DEFER; // 告訴內(nèi)核我再等等 return PTR_ERR(clk); } ... }4. probe 之后的資源生命周期內(nèi)核對(duì)設(shè)備的“全生命周期管理”配對(duì)成功之后probe被調(diào)用驅(qū)動(dòng)和設(shè)備正式“綁定”。但設(shè)備模型的故事并沒(méi)有結(jié)束它最強(qiáng)大的地方在于對(duì)設(shè)備資源生命周期的統(tǒng)一管理。我見(jiàn)過(guò)不少開(kāi)發(fā)者寫的驅(qū)動(dòng)probe里kzalloc分配內(nèi)存request_irq注冊(cè)中斷ioremap映射 IO然后在remove里一步步手動(dòng)釋放。這樣做本身沒(méi)錯(cuò)但效率低而且容易泄漏。設(shè)備模型提供了一套devmmanaged device resourcesAPI讓你的資源自動(dòng)綁定到設(shè)備生命周期上。struct my_dev { void __iomem *base; int irq; }; static int my_probe(struct platform_device *pdev) { struct resource *res; struct my_dev *mdev; int irq, ret; mdev devm_kzalloc(pdev-dev, sizeof(*mdev), GFP_KERNEL); if (!mdev) return -ENOMEM; res platform_get_resource(pdev, IORESOURCE_MEM, 0); mdev-base devm_ioremap_resource(pdev-dev, res); if (IS_ERR(mdev-base)) return PTR_ERR(mdev-base); irq platform_get_irq(pdev, 0); if (irq 0) return irq; ret devm_request_irq(pdev-dev, irq, my_isr, 0, mydev, mdev); if (ret) return ret; platform_set_drvdata(pdev, mdev); return 0; }注意devm_kzalloc、devm_ioremap_resource、devm_request_irq全程看不到一次手動(dòng)釋放。這就是devm的威力——當(dāng)設(shè)備被移除remove被調(diào)用或者驅(qū)動(dòng)從總線上解綁之后內(nèi)核會(huì)按照“后注冊(cè)的資源先釋放”的順序自動(dòng)把內(nèi)存、IO 映射、中斷請(qǐng)求、時(shí)鐘、GPIO 等全部清理干凈。devm_系列 API 幾乎是所有現(xiàn)代內(nèi)核驅(qū)動(dòng)的默認(rèn)選擇。它省下來(lái)的不僅是代碼量更是一整類“誰(shuí)負(fù)責(zé)釋放、什么時(shí)候釋放”的 bug。我甚至見(jiàn)過(guò)一個(gè)驅(qū)動(dòng)因?yàn)槭謩?dòng)kfree順序?qū)懛磳?dǎo)致use-after-free崩潰的案例。用devm_之后這類問(wèn)題從根上消失了。當(dāng)然devm_不是萬(wàn)能藥。如果資源生命周期和設(shè)備生命周期不一致——比如你要保留一塊內(nèi)存供另一個(gè)驅(qū)動(dòng)使用——你就需要手動(dòng)管理不能用devm_kzalloc。所以理解devm_的本質(zhì)比記住函數(shù)名更重要devm_就是把這個(gè)資源登記到設(shè)備上讓設(shè)備替你做善后工作。設(shè)備模型的另一個(gè)重要生命周期節(jié)點(diǎn)是uevent。當(dāng)設(shè)備注冊(cè)或注銷時(shí)內(nèi)核會(huì)向用戶態(tài)發(fā)送uevent事件udev或者mdev、eudev收到事件后在用戶態(tài)完成設(shè)備節(jié)點(diǎn)的創(chuàng)建、權(quán)限設(shè)置、固件加載等動(dòng)作。內(nèi)核創(chuàng)建設(shè)備、用戶態(tài)生成節(jié)點(diǎn)這解釋了一個(gè)現(xiàn)象嵌入式板子上如果沒(méi)跑udev即使驅(qū)動(dòng) probe 成功/dev下也不會(huì)有節(jié)點(diǎn)。你需要手動(dòng)mknod或者直接在驅(qū)動(dòng)里用device_create時(shí)配合devtmpfs來(lái)自動(dòng)生成。5. kobject 與 sysfs看不見(jiàn)的底層架構(gòu)如何變成你能摸到的文件說(shuō)到/sys就得把設(shè)備模型的底層地基翻出來(lái)——kobject和kset組成的“內(nèi)核對(duì)象系統(tǒng)”。你可以把kobject理解成一塊“標(biāo)簽”任何想納入設(shè)備模型管理的對(duì)象都要內(nèi)嵌一個(gè)kobject。設(shè)備有struct device里的kobj驅(qū)動(dòng)有kobj總線也有kobj。kobject負(fù)責(zé)三件事引用計(jì)數(shù)生命周期、父子關(guān)系拓?fù)?、sysfs 入口可視化。kset則是同一類kobject的集合你可以把它理解成一個(gè)分組容器。設(shè)備模型里的bus、class、subsystem本質(zhì)上就是kset或者由kset擴(kuò)展開(kāi)來(lái)的。sysfs 是這個(gè)對(duì)象系統(tǒng)在用戶態(tài)的一面鏡子。你在終端里看到的一切都是kobject樹(shù)在內(nèi)存中的投影/sys/devices/以物理拓?fù)浞绞浇M織的所有設(shè)備這是最真實(shí)的視圖/sys/bus/按總線分組每個(gè)bus下有devices/和drivers/兩個(gè)目錄/sys/class/按功能類型分組比如net、input、gpio、leds方便應(yīng)用層掃描/sys/block/塊設(shè)備專用視圖你打開(kāi)一個(gè)設(shè)備目錄里面會(huì)有大量屬性文件。這些文件背后就是device_attribute或者driver_attribute在驅(qū)動(dòng)里對(duì)應(yīng)的show()和store()函數(shù)。在 sysfs 里cat一個(gè)文件等于內(nèi)核執(zhí)行了一次show()函數(shù)echo 1 file等于內(nèi)核調(diào)用了一次store()函數(shù)。舉個(gè)例子如果你想在 sysfs 里暴露一個(gè)可讀寫的寄存器static ssize_t reg_show(struct device *dev, struct device_attribute *attr, char *buf) { struct my_dev *mdev dev_get_drvdata(dev); u32 val readl(mdev-base REG_OFFSET); return sysfs_emit(buf, 0x%08x\n, val); } static ssize_t reg_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { struct my_dev *mdev dev_get_drvdata(dev); u32 val; if (kstrtou32(buf, 0, val)) return -EINVAL; writel(val, mdev-base REG_OFFSET); return count; } static DEVICE_ATTR_RO(reg_show); static DEVICE_ATTR_WO(reg_store);然后在probe里用device_create_file()注冊(cè)屬性文件或者在驅(qū)動(dòng)里用一個(gè)宏表一次性創(chuàng)建多個(gè)屬性文件。對(duì)于底層調(diào)試來(lái)說(shuō)這是最直接的“人機(jī)接口”——不用寫應(yīng)用層工具直接 shell 里讀寫寄存器非常方便。還有一個(gè)細(xì)節(jié)值得提/sys/bus/platform/drivers/xxx/下面有一個(gè)bind和一個(gè)unbind文件。你可以手動(dòng)把一個(gè)設(shè)備從驅(qū)動(dòng)上解綁或者強(qiáng)制綁定另一個(gè)驅(qū)動(dòng)。這在調(diào)試階段極其有用比如某個(gè)驅(qū)動(dòng)probe時(shí)中斷申請(qǐng)失敗你可以echo device-name /sys/bus/platform/drivers/xxx/unbind修改參數(shù)后再 bind 回去不用反復(fù)卸載加載模塊。ls /sys/bus/platform/drivers/mydev/ echo mydev.0 /sys/bus/platform/drivers/mydev/unbind echo mydev.0 /sys/bus/platform/drivers/mydev/bind這套“對(duì)象系統(tǒng) 文件系統(tǒng)”的配合讓內(nèi)核里最復(fù)雜的結(jié)構(gòu)在你面前變成了一棵可以自由瀏覽、操作的目錄樹(shù)?？梢哉f(shuō) sysfs 是開(kāi)發(fā)者理解設(shè)備模型最趁手的地圖。6. 設(shè)備樹(shù)入局后驅(qū)動(dòng)模型發(fā)生了什么變化聊設(shè)備模型不可能繞開(kāi)設(shè)備樹(shù)。設(shè)備樹(shù)Device TreeDT對(duì)于驅(qū)動(dòng)模型來(lái)說(shuō)最大的變化是設(shè)備的描述從 C 語(yǔ)言代碼里挪到了 DTS 文件里。在設(shè)備樹(shù)之前內(nèi)核里每個(gè)板子都會(huì)寫一堆platform_device靜態(tài)定義來(lái)描述板載硬件代碼冗余、依賴硬編碼地址、不同板子無(wú)法復(fù)用。設(shè)備樹(shù)引入后硬件信息變成數(shù)據(jù)——compatible、reg、interrupts、clocks、gpios等屬性在 DTS 里聲明內(nèi)核啟動(dòng)時(shí)把這些節(jié)點(diǎn)解析成platform_device或者i2c_client、spi_device等具體總線設(shè)備。這就引出了驅(qū)動(dòng)開(kāi)發(fā)者要掌握的另一個(gè)匹配表——of_match_tablestatic const struct of_device_id my_of_match[] { { .compatible vendor,mydev-v2, }, { .compatible vendor,mydev-v1, }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, my_of_match); static struct platform_driver my_driver { .probe my_probe, .remove my_remove, .driver { .name mydev, .of_match_table my_of_match, }, }; module_platform_driver(my_driver);大概在compatible這塊有三個(gè)容易出問(wèn)題的點(diǎn)一個(gè)是of_match_table結(jié)尾必須要有哨兵條目也就是{ /* sentinel */ }。很多人抄代碼漏掉這個(gè)空條目導(dǎo)致驅(qū)動(dòng)加載時(shí)越界讀取probe莫名異常甚至內(nèi)核 panic。另一個(gè)是MODULE_DEVICE_TABLE。這個(gè)宏的作用是讓modinfo能查看驅(qū)動(dòng)支持的 compatible 列表同時(shí)讓內(nèi)核在模塊熱插拔時(shí)能根據(jù)設(shè)備樹(shù)節(jié)點(diǎn)自動(dòng)加載對(duì)應(yīng)模塊。不寫這個(gè)宏如果驅(qū)動(dòng)是編譯成模塊的很容易出現(xiàn)“設(shè)備樹(shù)節(jié)點(diǎn)在驅(qū)動(dòng)也在卻沒(méi)人 probe”的現(xiàn)象——因?yàn)轵?qū)動(dòng)壓根沒(méi)被自動(dòng)加載。你手動(dòng)modprobe才有效但一重啟又不行了。還有一個(gè)是compatible的命名規(guī)范一般建議使用廠商名,設(shè)備型號(hào)的形式比如fsl,imx6ull-uart。如果你在 DTS 里寫的是全小寫字母在驅(qū)動(dòng)里寫的是帶大寫字母字符匹配失敗probe不執(zhí)行但 dmesg 里往往沒(méi)有明確報(bào)錯(cuò)。排查這類問(wèn)題要靠of_device_is_compatible()或直接在probe前打印調(diào)試信息。設(shè)備樹(shù)還引入了reg和interrupts的屬性解析方式。對(duì)于一個(gè) platform 設(shè)備platform_get_resource()會(huì)根據(jù)索引獲取內(nèi)存區(qū)域或中斷號(hào)而不需要像老式驅(qū)動(dòng)那樣從靜態(tài)定義里硬讀地址。資源分離讓同一份驅(qū)動(dòng)源碼支持多個(gè)不同基地址的設(shè)備節(jié)點(diǎn)這正是設(shè)備樹(shù)設(shè)計(jì)的初衷——驅(qū)動(dòng)程序只關(guān)心“這個(gè)我適配的設(shè)備”不關(guān)心“它具體在哪個(gè)地址”。我想特別強(qiáng)調(diào)一點(diǎn)設(shè)備樹(shù)并不是只有 ARM 在用RISC-V、x86ACPI 不可用或缺失時(shí)也會(huì)用扁平設(shè)備樹(shù)。設(shè)備樹(shù)本身就是設(shè)備模型在這類嵌入式平臺(tái)上的“描述組織方式”。理解了設(shè)備和驅(qū)動(dòng)模型再看 DTS 里那些uart1 { status okay; };的片段你就知道那其實(shí)是在修改一個(gè)device節(jié)點(diǎn)的一些屬性最終影響的是設(shè)備能否被創(chuàng)建、能否被匹配。7. 手寫一個(gè) platform 驅(qū)動(dòng)從零看完整鏈路理論說(shuō)再多不如手寫一遍。我準(zhǔn)備用一個(gè)最小的 platform 設(shè)備驅(qū)動(dòng)走通“DTS 描述 → 設(shè)備創(chuàng)建 → 總線匹配 → probe → sysfs 暴露 → 用戶態(tài)訪問(wèn)”這條完整鏈路。第一步DTS 中描述設(shè)備// arch/arm/boot/dts/myboard.dts iomuxc { mydev { compatible vendor,mydev; reg 0x02200000 0x1000; interrupts GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH; }; };這段描述告訴內(nèi)核在某個(gè)總線上掛了一個(gè)設(shè)備廠商是vendor型號(hào)是mydev它的寄存器基地址在0x02200000長(zhǎng)度是0x1000中斷號(hào)是GIC_SPI 42在 ARM GIC 中斷控制器上。第二步寫驅(qū)動(dòng)骨架#include linux/module.h #include linux/platform_device.h #include linux/of.h #include linux/interrupt.h #include linux/io.h #define REG_DATA 0x00 struct mydev_data { void __iomem *base; unsigned int irq; }; static irqreturn_t mydev_isr(int irq, void *dev_id) { struct mydev_data *data dev_id; u32 status readl(data-base REG_DATA); pr_info(mydev: interrupt, status0x%08x\n, status); return IRQ_HANDLED; } static int mydev_probe(struct platform_device *pdev) { struct resource *res; struct mydev_data *data; int ret; data devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; res platform_get_resource(pdev, IORESOURCE_MEM, 0); >insmod mydev.ko ls /sys/bus/platform/devices/ | grep mydev ls /sys/bus/platform/drivers/mydev/ cat /proc/interrupts | grep mydev如果一切正常你會(huì)看到設(shè)備枚舉成功中斷號(hào)被分配。這里我要特別推薦module_platform_driver()這個(gè)宏它本質(zhì)上是module_init(mydev_driver_init); module_exit(mydev_driver_exit);自動(dòng)幫你生成了platform_driver_register/platform_driver_unregister的包裹函數(shù)。這樣寫出來(lái)的驅(qū)動(dòng)結(jié)構(gòu)極其清晰probe做初始化remove做清理剩下的是匹配表信息。在這個(gè)基礎(chǔ)上你還可以利用DEVICE_ATTR加幾個(gè)屬性文件然后在 shell 里直接讀寫寄存器驗(yàn)證硬件。從設(shè)備模型的角度看一個(gè)驅(qū)動(dòng)做完 probe、注冊(cè)好資源、暴露 sysfs 屬性就已經(jīng)是一個(gè)“合格”的驅(qū)動(dòng)了。至于字符設(shè)備、網(wǎng)絡(luò)子系統(tǒng)、輸入子系統(tǒng)之類的業(yè)務(wù)層都是在 probe 之后往具體框架里注冊(cè)的結(jié)果。8. 調(diào)試設(shè)備模型時(shí)我踩過(guò)的坑與排查路徑最后一部分我寫點(diǎn)實(shí)戰(zhàn)里最常遇到的問(wèn)題。設(shè)備模型的好處是高度結(jié)構(gòu)化所以排查問(wèn)題的路徑也比較固定?？右或?qū)動(dòng)加載了probe 卻不執(zhí)行這是最典型的“設(shè)備模型問(wèn)題”。排查時(shí)按下面的鏈路走先確認(rèn)設(shè)備確實(shí)被枚舉出來(lái)了ls /sys/bus/platform/devices/ | grep xxx。沒(méi)有設(shè)備說(shuō)明 DTS 沒(méi)生效檢查 DTS 語(yǔ)法、編譯的 dtb 是否真的加載了compatible字符串有沒(méi)有拼錯(cuò)。確認(rèn)驅(qū)動(dòng)注冊(cè)成功ls /sys/bus/platform/drivers/xxx/。沒(méi)有驅(qū)動(dòng)目錄檢查模塊是否加載成功platform_driver_register是否真的執(zhí)行。確認(rèn)匹配條件滿足cat /sys/bus/platform/devices/xxx/uevent看OF_NAME、OF_COMPATIBLE和驅(qū)動(dòng)modinfo顯示的匹配表是否一致。dmesg里搜platform或者驅(qū)動(dòng)的名字。如果設(shè)備確實(shí)嘗試過(guò)匹配但驅(qū)動(dòng)返回了-EPROBE_DEFER你不會(huì)看到錯(cuò)誤只能看到probe defer的信息?？佣O(shè)備節(jié)點(diǎn)時(shí)有時(shí)無(wú)如果你沒(méi)有跑udev或者跑的是精簡(jiǎn)版mdev經(jīng)常遇到內(nèi)核明明已經(jīng)注冊(cè)了設(shè)備但/dev下沒(méi)節(jié)點(diǎn)。排查思路是看/sys/class/你的類名/下面有沒(méi)有對(duì)應(yīng)的設(shè)備目錄。有目錄但/dev沒(méi)有那是devtmpfs或udev的問(wèn)題連/sys/class下都沒(méi)有那是你的class_createdevice_create沒(méi)調(diào)用成功?？尤齬elease回調(diào)沒(méi)實(shí)現(xiàn)導(dǎo)致 panic前面提過(guò)這里展開(kāi)講。如果你自己kzalloc了一個(gè)struct device然后注冊(cè)到總線最后注銷時(shí)內(nèi)核會(huì)調(diào)用device-release來(lái)釋放這塊內(nèi)存。平臺(tái)總線上的平臺(tái)設(shè)備一般由內(nèi)核框架統(tǒng)一管理但你自己device_register一個(gè)裸的device時(shí)必須初始化releasestatic void mydev_release(struct device *dev) { kfree(dev); } static int create_my_device(void) { struct device *dev kzalloc(sizeof(*dev), GFP_KERNEL); dev-release mydev_release; dev-bus platform_bus_type; dev_set_name(dev, mydev.0); return device_register(dev); }我當(dāng)初第一次寫類似代碼時(shí)忘了給release賦值device_unregister時(shí)內(nèi)核直接報(bào)BUG: unable to handle kernel NULL pointer dereference然后整個(gè)系統(tǒng) panic。這一坑在中級(jí)內(nèi)核開(kāi)發(fā)者中極其常見(jiàn)。坑四屬性文件的讀寫返回值問(wèn)題show()函數(shù)返回的值必須是你實(shí)際寫入buf的字節(jié)數(shù)不能多不能少。echo時(shí)store()返回count。如果你在store()里做了一次strncmp匹配后忘記return countshell 會(huì)一直報(bào)echo: write error。新版內(nèi)核還提供了sysfs_emit()之類的安全接口推薦優(yōu)先使用?？游錺robe里用了msleep()慢啟動(dòng)設(shè)備模型的匹配和 probe 是在內(nèi)核線程里串行執(zhí)行的。如果你在probe里加了一個(gè)大延時(shí)系統(tǒng)啟動(dòng)時(shí)間會(huì)肉眼可見(jiàn)地變長(zhǎng)。排查慢啟動(dòng)時(shí)initcall_debug是個(gè)好幫手打開(kāi)后能打印每個(gè) initcall 的耗時(shí)但 platform 驅(qū)動(dòng)的 probe 發(fā)生得更早你可以用ftrace的probe事件追蹤。echo 1 /sys/kernel/debug/tracing/events/initcall/enable cat /sys/kernel/debug/tracing/trace坑六驅(qū)動(dòng)編成模塊但沒(méi)自動(dòng)加載很多板子把驅(qū)動(dòng)編成.ko放在根文件系統(tǒng)里但沒(méi)有跑depmod沒(méi)有把模塊路徑加到/etc/modules-load.d/也沒(méi)有配置modprobe的別名。設(shè)備樹(shù)里明明有兼容節(jié)點(diǎn)驅(qū)動(dòng)模塊就是不被自動(dòng)加載。如果你用的 buildroot建議在 rootfs 的/etc/modules里加模塊名或者干脆把驅(qū)動(dòng)編進(jìn)內(nèi)核——對(duì)產(chǎn)品發(fā)布來(lái)說(shuō)編進(jìn)內(nèi)核更省心更新也少。設(shè)備模型這個(gè)抽象層強(qiáng)就強(qiáng)在它把“設(shè)備發(fā)現(xiàn)”“驅(qū)動(dòng)匹配”“資源生命周期”“用戶態(tài)可視化”全部統(tǒng)一到一個(gè)框架里?；〞r(shí)間把device、device_driver、bus_type、class這四件事想透再看具體子系統(tǒng)的驅(qū)動(dòng)代碼你會(huì)發(fā)現(xiàn)所有套路基本一致總線上有設(shè)備有驅(qū)動(dòng)匹配之后probe然后注冊(cè)業(yè)務(wù)接口。這個(gè)過(guò)程熟悉之后內(nèi)核那些看似復(fù)雜的子系統(tǒng)源碼你讀起來(lái)會(huì)輕松太多。