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