動開發(fā)：Platform總線設(shè)備與驅(qū)動匹配機制全解析)
做i.MX6ULL的Linux驅(qū)動開發(fā)很多人第一次接觸Platform總線時都是一頭霧水明明照著教程寫完了一個platform_driverinsmod也成功了但probe函數(shù)就是不執(zhí)行設(shè)備號也申請不到折騰一整天最后發(fā)現(xiàn)是設(shè)備樹里compatible字段和驅(qū)動里的of_match_table沒有對上。這個坑我踩過帶過的不少新同事也踩過所以我想把i.MX6ULL平臺下這套設(shè)備與驅(qū)動匹配機制徹底講透從內(nèi)核為什么要搞Platform這一套東西到匹配流程內(nèi)部到底發(fā)生了什么事再到怎么自己寫一個能被正常probe的驅(qū)動、怎么排查匹配失敗的問題一次說清楚。這篇文章適合正在學(xué)嵌入式Linux驅(qū)動開發(fā)、尤其是用i.MX6ULL或者類似Cortex-A7核心板做項目的朋友閱讀不管你是剛看完字符設(shè)備驅(qū)動、準(zhǔn)備往設(shè)備樹和Platform模型過渡還是已經(jīng)寫了不少驅(qū)動但一直沒認真搞明白匹配原理都能從里面得到能直接拿去用的東西。1. 先搞清楚Platform機制到底解決了什么問題1.1 早期字符設(shè)備驅(qū)動寫法為什么撐不住了咱們先把時間拉回到Linux 2.6之前。早期寫驅(qū)動最常見的方式就是把板子上的硬件資源寫死在驅(qū)動代碼里。比如你要操作一個LED對應(yīng)的GPIO寄存器直接在驅(qū)動里硬編碼物理地址ioremap之后對著寄存器地址寫值如果要注冊一個中斷也是直接寫死中斷號。這種方式在嵌入式開發(fā)早期確實簡單粗暴能用但問題很快就暴露出來了。首先是資源沖突。同一個芯片可能被用在幾十種板卡上A板子LED接在GPIO1_IO03B板子LED接在GPIO1_IO05同一份驅(qū)動代碼在兩塊板子上就沒法通用。其次是設(shè)備變更帶來的維護地獄硬件工程師說改一下引腳連接驅(qū)動開發(fā)就得跟著改源碼重新編譯版本管理一混亂哪天改錯了哪個地址排查起來極其痛苦。這就引出了Linux設(shè)備模型里最重要的思路驅(qū)動是驅(qū)動設(shè)備是設(shè)備兩者分開維護通過一種統(tǒng)一的機制在運行時完成匹配和綁定。驅(qū)動只負責(zé)描述“我能操作什么類型的外設(shè)、怎么操作”設(shè)備則描述“這塊板子上實際有哪些外設(shè)、外設(shè)的資源寄存器地址、中斷號、GPIO等在哪里”。誰也不要寫死誰。1.2 總線、設(shè)備、驅(qū)動三角色如何分工Linux為了解決上面的問題抽象出了總線bus、設(shè)備device、驅(qū)動driver三個角色。PCI設(shè)備有PCI總線USB設(shè)備有USB總線它們都是真實存在的物理總線設(shè)備和驅(qū)動都掛在這種總線上由總線子系統(tǒng)負責(zé)匹配。問題來了SoC內(nèi)部的很多外設(shè)控制器比如I2C控制器、SPI控制器、UART、GPIO控制器、以太網(wǎng)MAC它們并不是掛在PCI或者USB這種物理枚舉總線上面的。系統(tǒng)啟動時這些設(shè)備是固定存在的不需要像USB設(shè)備那樣去掃描發(fā)現(xiàn)。為了讓這些“天生就存在”的片上外設(shè)也能套用總線-設(shè)備-驅(qū)動模型內(nèi)核提供了一個虛擬總線叫platform_bus也就是咱們常說的Platform總線。Platform總線上掛的“設(shè)備”叫platform_device可以是芯片內(nèi)部集成的外設(shè)控制器也可以是指定為platform_device的外部設(shè)備。在Device Tree設(shè)備樹普及之后內(nèi)核在啟動階段會解析設(shè)備樹把其中匹配到的節(jié)點一個一個轉(zhuǎn)換成platform_device掛到platform總線上。驅(qū)動這邊只要你寫的是platform_driver注冊時就會掛到同一條虛擬總線上。總線負責(zé)撮合新來了一個platform_device總線就去看看現(xiàn)有的platform_driver有沒有能匹配上它的新注冊了一個platform_driver總線又會反過來掃描現(xiàn)有的platform_device。一旦匹配成功總線就會調(diào)用driver里的probe函數(shù)把設(shè)備相關(guān)的資源信息交給你你的驅(qū)動從這一刻才開始真正初始化硬件。1.3 i.MX6ULL上哪些資源依賴這套機制i.MX6ULL是NXP基于Cortex-A7內(nèi)核設(shè)計的低功耗應(yīng)用處理器內(nèi)部集成了大量的外設(shè)控制器?？梢赃@么說除了內(nèi)存控制器等極少數(shù)基礎(chǔ)組件芯片上幾乎你能用到的所有外設(shè)控制器在Linux內(nèi)核里都是以platform_device的形式存在或者由設(shè)備樹節(jié)點轉(zhuǎn)換而來的。舉個例子你就會明白設(shè)備樹里經(jīng)?？吹筋愃七@樣的節(jié)點i2c1 { clock-frequency 100000; pinctrl-names default; pinctrl-0 pinctrl_i2c1; status okay; };這個i2c1節(jié)點在內(nèi)核啟動階段會被轉(zhuǎn)換成platform_device然后去匹配I2C控制器驅(qū)動里的platform_driver匹配成功進入probe之后驅(qū)動才會去初始化i2c適配器、注冊i2c總線。之后再發(fā)現(xiàn)掛在這條i2c總線上的客戶端設(shè)備就又是另一套i2c_client的匹配邏輯了。搞懂這個流程你就能明白為什么很多時候我們給某個外設(shè)控制器寫驅(qū)動第一個函數(shù)入口不是file_operations里的open/release而是probe函數(shù)。因為你的驅(qū)動首先要被“系統(tǒng)認識”通過Platform匹配機制綁定到對應(yīng)設(shè)備上才有資格去操作硬件資源。2. 匹配機制全解析一條probe是怎么被叫醒的2.1 驅(qū)動和設(shè)備在什么時機相互打量一個platform_driver從注冊到它的probe被調(diào)用中間經(jīng)歷的過程非常關(guān)鍵。很多人只知道寫驅(qū)動時要注冊platform_driver但不知道probe調(diào)用的完整時機。當(dāng)你在驅(qū)動里調(diào)用platform_driver_register的時候內(nèi)核會把driver掛到platform_bus_type這根虛擬總線上然后立刻執(zhí)行一次總線對已有設(shè)備的掃描。內(nèi)核會遍歷platform bus上所有的device對每一個設(shè)備調(diào)用platform_match函數(shù)看看你的driver跟哪個設(shè)備能配對。只要找到一個配對的設(shè)備立刻執(zhí)行probe。反過來設(shè)備是怎么來的有兩種常見來源。傳統(tǒng)方式是通過platform_device_register主動注冊平臺代碼里構(gòu)造platform_device結(jié)構(gòu)體然后塞給內(nèi)核這在老內(nèi)核或者不使用設(shè)備樹的場景中很常見?，F(xiàn)在的主流方式則是設(shè)備樹內(nèi)核在啟動時用of_platform_default_populate_init遍歷設(shè)備樹根節(jié)點下的所有節(jié)點把 compatible 屬性匹配的節(jié)點變成platform_device隨后掃描驅(qū)動列表完成匹配。所以probe被調(diào)用的時機其實有兩種典型場景如果你先加載驅(qū)動后注冊設(shè)備比如設(shè)備樹節(jié)點本來就在但驅(qū)動是后面insmod的那么在platform_driver_register內(nèi)部掃描設(shè)備時就會觸發(fā)probe。如果設(shè)備在你驅(qū)動的probe執(zhí)行過程中又創(chuàng)建了子設(shè)備比如MFD多功能設(shè)備驅(qū)動創(chuàng)建子平臺設(shè)備那是設(shè)備注冊時反向掃描驅(qū)動觸發(fā)probe。理解這個雙向掃描邏輯后面排查“為什么probe沒跑”時就能有個清晰的方向到底是設(shè)備始終沒被創(chuàng)建還是設(shè)備與驅(qū)動的匹配條件不滿足。2.2 內(nèi)核源碼里platform_match的匹配順序要真正理解匹配機制不能只看概念我建議你打開內(nèi)核源碼里drivers/base/platform.c找到platform_match函數(shù)。不同內(nèi)核版本可能會有細微差別但核心邏輯基本穩(wěn)定。整個匹配過程大概分這么幾步static int platform_match(struct device *dev, struct device_driver *drv) { struct platform_device *pdev to_platform_device(dev); struct platform_driver *pdrv to_platform_driver(drv); /* 1. 嘗試設(shè)備樹匹配 */ if (of_driver_match_device(dev, drv)) return 1; /* 2. 嘗試ACPI匹配 */ if (acpi_driver_match_device(dev, drv)) return 1; /* 3. 嘗試platform專用id_table匹配 */ if (pdrv-id_table) if (platform_match_id(pdrv-id_table, pdev) ! NULL) return 1; /* 4. 嘗試驅(qū)動名字與設(shè)備名字直接匹配 */ return (strcmp(pdev-name, drv-name) 0); }需要注意的是在沒有使能ACPI的嵌入式ARM平臺上第二步通常不會生效關(guān)鍵的匹配路徑就是設(shè)備樹compatible匹配、id_table匹配和名字匹配三路。最初級的匹配方法是驅(qū)動程序名和設(shè)備名相同。早期platform驅(qū)動在driver結(jié)構(gòu)體和platform_device結(jié)構(gòu)體的name字段直接保持一致即可。這種匹配路線現(xiàn)在仍然存在但更多是兜底邏輯。設(shè)備樹普及之后絕大多數(shù)場景走的是第一條of_driver_match_device。設(shè)備樹匹配的核心是compatible屬性。設(shè)備樹里的每個節(jié)點只要是代表一個真實的設(shè)備基本都要寫compatible屬性。比如某個外設(shè)節(jié)點長得這樣mydevice: mydevice020c406c { compatible myvendor,mydevice; reg 0x020c406c 0x4; ... };驅(qū)動側(cè)就要在of_device_id數(shù)組里提供一個同樣的compatible字符串static const struct of_device_id mydevice_of_match[] { { .compatible myvendor,mydevice, }, { /* sentinel */ }, }; MODULE_DEVICE_TABLE(of, mydevice_of_match); static struct platform_driver mydevice_driver { .probe mydevice_probe, .remove mydevice_remove, .driver { .name mydevice, .of_match_table mydevice_of_match, }, }; module_platform_driver(mydevice_driver);匹配時內(nèi)核拿設(shè)備樹節(jié)點的compatible屬性字符串和of_match_table數(shù)組里所有compatible字段逐一比較只要有一個相等就算匹配成功。2.3 of_device_id里藏的小秘密data指針很多基礎(chǔ)教程在講of_device_id時只強調(diào)compatible字段必須對齊卻忽略了一個很實用的字段data。我在這兒重點說一下。of_device_id結(jié)構(gòu)體的data成員是一個void指針用于在驅(qū)動側(cè)攜帶與某個compatible關(guān)聯(lián)的私有數(shù)據(jù)。比如同一顆芯片上可能有多個功能相近但寄存器細節(jié)不同的IP核驅(qū)動里可以共用同一個probe函數(shù)但在of_device_id里通過data來區(qū)分IP版本probe時用of_match_device取出當(dāng)前匹配到的of_device_id然后強轉(zhuǎn)data拿到不同的硬件信息。我給你一個實際場景。假設(shè)板子上有兩個LED控制器一個老版本寄存器地址偏移不同一個新版本兩者的compatible分別是“myvendor,led-v1”和“myvendor,led-v2”。如果用兩套of_match_table分別寫兩個驅(qū)動顯然很蠢。更聰明的做法是一個驅(qū)動of_match_table里放兩個條目data分別指向不同的led_hw_cfg結(jié)構(gòu)體static struct led_hw_cfg led_v1_cfg { .reg_offset 0x00, .max_brightness 255, }; static struct led_hw_cfg led_v2_cfg { .reg_offset 0x10, .max_brightness 1023, }; static const struct of_device_id myled_of_match[] { { .compatible myvendor,led-v1, .data led_v1_cfg }, { .compatible myvendor,led-v2, .data led_v2_cfg }, { /* sentinel */ }, }; static int myled_probe(struct platform_device *pdev) { const struct of_device_id *match; struct led_hw_cfg *cfg; match of_match_device(myled_of_match, pdev-dev); if (match) cfg (struct led_hw_cfg *)match-data; ... }這個用法在NXP官方內(nèi)核以及很多主流驅(qū)動里都能看到做好之后板級差異就被壓縮到一個結(jié)構(gòu)體數(shù)據(jù)里驅(qū)動代碼的復(fù)用性明顯提升。2.4 匹配成功后內(nèi)核額外做的幾件事匹配成功后內(nèi)核會自動補齊一些基礎(chǔ)信息接著才會調(diào)用你的probe。首先是dev_set_drvdata一類內(nèi)部關(guān)聯(lián)操作讓設(shè)備與驅(qū)動之間建立關(guān)聯(lián)之后你在probe內(nèi)部用的dev_get_drvdata才有效。其次是sysfs文件系統(tǒng)視角下/sys/bus/platform/devices目錄下的設(shè)備會出現(xiàn)一個driver符號鏈接指向/sys/bus/platform/drivers下面你的驅(qū)動目錄。還有一點很多剛?cè)腴T的新人會困惑為什么probe里已經(jīng)用misc_register注冊了字符設(shè)備但insmod之后/dev下并沒有立刻出現(xiàn)對應(yīng)節(jié)點這跟Platform匹配機制無關(guān)但發(fā)生場景經(jīng)常重合。insmod執(zhí)行后probe成功調(diào)用了設(shè)備注冊動作在probe里也完成了但用戶空間的udev或者mdev嵌入式環(huán)境常用busybox mdev需要在收到uevent事件后去創(chuàng)建/dev節(jié)點。如果你的系統(tǒng)里沒有配置udev/mdev自動處理那/dev下確實不會自動出現(xiàn)設(shè)備節(jié)點。這一點在之后的調(diào)試過程中非常常見別把板子本身的問題和匹配機制混為一談。另外如果設(shè)備節(jié)點被設(shè)置為status disabled那么內(nèi)核掃描設(shè)備樹時一般不會為該節(jié)點創(chuàng)建platform_device。注意是“一般不會”。有些場合下節(jié)點會被創(chuàng)建但驅(qū)動會被禁止綁定具體取決于內(nèi)核的配置。在i.MX6ULL這種主流BSP中disabled節(jié)點基本不會生成platform_device因此你的驅(qū)動永遠得不到probe的機會。這是一個非常隱蔽的坑后面排查部分我會專門提到。3. 在i.MX6ULL上實操寫一個能匹配上的Platform驅(qū)動3.1 環(huán)境準(zhǔn)備與基礎(chǔ)工程建議咱們動手寫一個完整的Platform驅(qū)動別空談理論。我用的是i.MX6ULL開發(fā)板內(nèi)核版本以4.1.15或者4.9.x為主這也是目前市面上不少i.MX6ULL開發(fā)板BSP的常見內(nèi)核版本。交叉編譯工具鏈一般是arm-linux-gnueabihf-根據(jù)你自己開發(fā)板配套的SDK來定。寫驅(qū)動之前我建議先確認三件事內(nèi)核源碼目錄已經(jīng)準(zhǔn)備好并且編譯過一遍生成了Module.symvers。開發(fā)板內(nèi)核里設(shè)備樹已經(jīng)支持你將要修改的節(jié)點或者你知道怎么把新的dtb燒進去。板子上的文件系統(tǒng)能夠加載內(nèi)核模塊比如insmod/modprobe命令可用。寫驅(qū)動文件之前先在板子上執(zhí)行下面這條命令看看當(dāng)前系統(tǒng)里platform設(shè)備的大致情況ls /sys/bus/platform/devices/你會看到很多設(shè)備比如soc、1001000.uart、2000000.spi之類名字一般是“寄存器地址.設(shè)備名”的格式這些就是內(nèi)核從設(shè)備樹里解析出來后掛到platform總線上的設(shè)備。等下咱們自己通過設(shè)備樹創(chuàng)建的設(shè)備也會以類似的形式出現(xiàn)在這個目錄。3.2 設(shè)備樹中定義自己的平臺設(shè)備節(jié)點我們的目標(biāo)是創(chuàng)建一個叫“myled”的平臺設(shè)備然后讓驅(qū)動程序通過compatible匹配到它進入probe最后操作一個GPIO點燈。你需要在設(shè)備樹源文件里找到根節(jié)點或者合適的父節(jié)點添加以下這個節(jié)點。很多i.MX6ULL開發(fā)板的設(shè)備樹頂層是板級dts文件如imx6ull-14x14-evk.dts里面有根節(jié)點“/”往根節(jié)點里加就行了。有些為了方便管理會放在根節(jié)點的某個子節(jié)點中只要能被內(nèi)核正常解析到就行放在根下最直觀。/ { myled { compatible myvendor,myled; pinctrl-names default; pinctrl-0 pinctrl_myled; led-gpio gpio1 3 GPIO_ACTIVE_LOW; status okay; }; };注意這個節(jié)點里我引用了pinctrl_myled你必須在設(shè)備樹里對應(yīng)的iomuxc節(jié)點下添加這個引腳復(fù)用配置。以i.MX6ULL為例通常在設(shè)備樹中可以找到類似這么一段iomuxc { pinctrl_myled: myledgrp { fsl,pins MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0x10b0 ; }; };引腳的宏定義MX6UL_PAD_GPIO1_IO03__GPIO1_IO03在設(shè)備樹頭文件里已經(jīng)定義好不同開發(fā)板這個宏可能不一樣具體看你的BSP設(shè)備樹。我這里只是給你一個示例實際操作時必須以自己板卡上的引腳為依據(jù)。改完設(shè)備樹之后重新編譯dtb然后燒錄或者通過tftp/nfs方式加載到板子上啟動。啟動后在板子上執(zhí)行l(wèi)s /sys/bus/platform/devices/myled如果設(shè)備樹解析正常你應(yīng)該能看到這個目錄存在。到這一步你的“平臺設(shè)備”已經(jīng)創(chuàng)建成功內(nèi)核里已經(jīng)存在一個platform_device就等著驅(qū)動來匹配了。如果看不到設(shè)備目錄優(yōu)先檢查設(shè)備樹有沒有被正確編譯加載compatible、status屬性有沒有問題。3.3 編寫Platform驅(qū)動并正確注冊接下來寫驅(qū)動。為了把注意力集中在Platform機制上我直接用一個最簡單的點燈驅(qū)動示例通過miscdevice注冊字符設(shè)備用戶程序用ioctl控制亮滅極簡版。完整代碼示例#include linux/module.h #include linux/platform_device.h #include linux/of.h #include linux/of_gpio.h #include linux/gpio/consumer.h #include linux/miscdevice.h #include linux/uaccess.h #include linux/fs.h #define MYLED_ON 0x01 #define MYLED_OFF 0x00 struct myled_dev { struct gpio_desc *led_gpio; }; static struct myled_dev *myled_data; static long myled_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { switch (cmd) { case MYLED_ON: gpiod_set_value(myled_data-led_gpio, 1); break; case MYLED_OFF: gpiod_set_value(myled_data-led_gpio, 0); break; default: return -EINVAL; } return 0; } static const struct file_operations myled_fops { .owner THIS_MODULE, .unlocked_ioctl myled_ioctl, }; static struct miscdevice myled_miscdev { .minor MISC_DYNAMIC_MINOR, .name myled, .fops myled_fops, }; static int myled_probe(struct platform_device *pdev) { struct device *dev pdev-dev; int ret; dev_info(dev, myled probe success\n); myled_data devm_kzalloc(dev, sizeof(*myled_data), GFP_KERNEL); if (!myled_data) return -ENOMEM; myled_data-led_gpio devm_gpiod_get(dev, led, GPIOD_OUT_LOW); if (IS_ERR(myled_data-led_gpio)) { ret PTR_ERR(myled_data-led_gpio); dev_err(dev, failed to get led gpio: %d\n, ret); return ret; } gpiod_set_consumer_name(myled_data-led_gpio, myled); ret misc_register(myled_miscdev); if (ret) { dev_err(dev, failed to register misc device\n); return ret; } return 0; } static int myled_remove(struct platform_device *pdev) { misc_deregister(myled_miscdev); return 0; } static const struct of_device_id myled_of_match[] { { .compatible myvendor,myled, }, { /* sentinel */ }, }; MODULE_DEVICE_TABLE(of, myled_of_match); static struct platform_driver myled_driver { .probe myled_probe, .remove myled_remove, .driver { .name myled, .of_match_table myled_of_match, }, }; module_platform_driver(myled_driver); MODULE_LICENSE(GPL); MODULE_AUTHOR(Your Name); MODULE_DESCRIPTION(i.MX6ULL platform device match demo);這個驅(qū)動用module_platform_driver宏完成platform_driver_register和platform_driver_unregister的封裝。加載時注冊驅(qū)動總線掃描設(shè)備后如果匹配成功probe就會被調(diào)用。3.4 編譯、加載與查看匹配效果對應(yīng)的Makefile非常簡單obj-m : myled.o KERNELDIR : /path/to/your/kernel CROSS_COMPILE : arm-linux-gnueabihf- CC : $(CROSS_COMPILE)gcc all: $(MAKE) -C $(KERNELDIR) M$(PWD) ARCHarm CROSS_COMPILE$(CROSS_COMPILE) modules clean: $(MAKE) -C $(KERNELDIR) M$(PWD) ARCHarm CROSS_COMPILE$(CROSS_COMPILE) clean編譯之后得到myled.ko拷貝到板子上insmod加載insmod myled.ko正常的話dmesg里能看到myled myled: myled probe success此時查看platform總線的設(shè)備與驅(qū)動綁定關(guān)系ls -l /sys/bus/platform/devices/myled/driver如果驅(qū)動已經(jīng)成功綁定這個符號鏈接會指向drivers目錄下的myled驅(qū)動。再用設(shè)備名匹配方式來驗證一下純名字匹配路徑的優(yōu)先級問題如果設(shè)備樹里沒有compatible而你的platform_device是內(nèi)核代碼直接注冊的driver結(jié)構(gòu)體里的name字段和設(shè)備name相同也可能匹配成功。這一點雖然老派在兼容舊代碼時很有用。3.5 GPIO子系統(tǒng)在Platform機制中扮演的輔助角色在剛才的驅(qū)動里我用到了devm_gpiod_get和gpiod_set_value這是內(nèi)核GPIO子系統(tǒng)提供的基于描述符的接口。你可能會疑惑這跟Platform匹配機制有什么關(guān)系關(guān)系其實不直接但屬于Platform設(shè)備操作最典型的資源獲取方式。傳統(tǒng)開發(fā)中要操作GPIO需要ioremap并配置引腳復(fù)用寄存器很繁瑣?，F(xiàn)在的推薦姿勢是在設(shè)備樹節(jié)點里通過led-gpio這樣的屬性描述“我需要哪個引腳”驅(qū)動中通過devm_gpiod_get獲取GPIO描述符。這個API能正常工作前提是你傳入了指向struct device的指針也就是platform_device里的pdev-dev。設(shè)備樹、GPIO子系統(tǒng)、Platform驅(qū)動模型這三者是緊密配合的。Platform總線匹配只是給你一個“入場券”入場之后怎么拿資源、怎么使用硬件又注冊了另一套內(nèi)核API。很多教程把這幾個維度混在一起新手就容易懵。我建議你在實驗時把這條鏈路拆開理解設(shè)備樹節(jié)點 設(shè)備說明書描述有什么資源。Platform驅(qū)動匹配 驗證“這個驅(qū)動能管這個設(shè)備”。probe函數(shù) 驅(qū)動讀取說明書實際操作資源。misc或者字符設(shè)備框架 把操作能力暴露給用戶空間。3.6 id_table匹配方式與非設(shè)備樹場景聊完設(shè)備樹方式咱們也花點時間說說id_table匹配。畢竟并非所有內(nèi)核和所有平臺都使用設(shè)備樹而老平臺代碼里大量存在platform_device_id的使用方式。如果你有一個平臺設(shè)備它不是從設(shè)備樹生成的而是通過platform_device_register注冊的例如內(nèi)核板級文件里這么寫static struct resource myled_resources[] { { .start 0x020c406c, .end 0x020c406f, .flags IORESOURCE_MEM, }, }; static struct platform_device myled_device { .name myled, .id -1, .num_resources ARRAY_SIZE(myled_resources), .resource myled_resources, }; static int __init myled_device_init(void) { return platform_device_register(myled_device); }你的驅(qū)動需要通過platform_driver里的id_table來匹配而不只是名字。使用示例static const struct platform_device_id myled_id_table[] { { myled, 0 }, { }, }; MODULE_DEVICE_TABLE(platform, myled_id_table); static struct platform_driver myled_driver { .probe myled_probe, .remove myled_remove, .driver { .name myled, }, .id_table myled_id_table, };platform_match內(nèi)部執(zhí)行順序是先查of_match_table再查ACPI再查id_table最后才是driver name與device name直接比較。但這里有個細節(jié)如果驅(qū)動同時配置了of_match_table和id_table設(shè)備樹匹配又是首要路徑許多時候驅(qū)動作者會把compatible匹配的設(shè)備也放進id_table里主要是為了MODULE_DEVICE_TABLE生成模塊別名方便modprobe自動加載模塊。“為什么我明明把驅(qū)動編譯成模塊放到文件系統(tǒng)了modprobe能識別到模塊卻還是會找不到設(shè)備”這類問題經(jīng)常就是模塊別名機制的問題。modprobe在加載模塊前要根據(jù)設(shè)備uevent里的MODALIAS環(huán)境變量去尋找對應(yīng)的模塊MODALIAS內(nèi)容與設(shè)備樹compatible相關(guān)而模塊中通過MODULE_DEVICE_TABLE導(dǎo)出的表決定了內(nèi)核知道這個模塊能支持哪些設(shè)備。如果你只寫了of_match_table沒有同步MODULE_DEVICE_TABLE自動加載時可能就會出問題。這個知識點一般很少人講透遇到了先檢查這里不會錯。4. 匹配失敗排查與調(diào)試經(jīng)驗4.1 最常見的匹配失敗原因匹配失敗是驅(qū)動開發(fā)里最磨人的問題之一。根據(jù)我?guī)ы椖康慕?jīng)驗下面這些原因幾乎覆蓋了八成以上的失敗場景你排查時不妨按順序過一遍。compatible字符串不一致這是頭號問題。設(shè)備樹里寫著myvendor,myled驅(qū)動of_match_table里寫的是myvendor,myled 多了個空格或者大小寫不一致都匹配不上。排查方法很簡單在板子上執(zhí)行cat /sys/bus/platform/devices/myled/uevent看輸出的MODALIAS字段OF_NAMEmyled OF_FULLNAME/myled OF_COMPATIBLE_0myvendor,myled MODALIASof:NmyledTNULLCmyvendor,myled然后對比驅(qū)動模塊中由of_match_table生成的模塊別名。也可以直接看/proc/device-tree下設(shè)備樹節(jié)點里的屬性是否和你期望的一致。設(shè)備樹沒過。這個問題尤其隱蔽因為很多開發(fā)板啟動時用的不是最新編譯的dtb你改了dts但忘了重新編譯或者編譯了沒有傳到板子對應(yīng)的啟動分區(qū)。排查方法很直接在板子上重新查看設(shè)備樹里你添加的節(jié)點是否存在例如ls /proc/device-tree/myled/ cat /proc/device-tree/myled/compatiblestatus屬性被設(shè)成disabled。如前所述disabled狀態(tài)可能導(dǎo)致platform_device根本不創(chuàng)建。檢查節(jié)點status是否為okay或者干脆去掉status屬性。有些BSP中特定父節(jié)點下的status控制邏輯還會有差異需要具體問題具體分析但第一懷疑對象一定是這里。pinctrl配置出錯。節(jié)點里的pinctrl-0引用了不存在的pinctrl_myled節(jié)點或者引用的引腳宏跟iomuxc里實際配置不一致雖然不直接影響Platform匹配但probe里GPIO請求時會失敗導(dǎo)致probe返回錯誤碼驅(qū)動被卸載現(xiàn)象看起來跟匹配失敗一樣。排查時可以先用以下命令確認這個設(shè)備是否綁定過驅(qū)動ls -l /sys/bus/platform/devices/myled/driver如果driver鏈接存在說明匹配成功過probe里報錯的可能性更大如果不存在才說明匹配階段都沒走通。GPIO號沖突或者重復(fù)申請。i.MX6ULL的GPIO資源管理通過GPIO子系統(tǒng)完成如果你在設(shè)備樹里把同一個引腳用在兩個不同節(jié)點或者驅(qū)動里重復(fù)請求了同一個GPIOdevm_gpiod_get會返回錯誤。典型報錯是EBUSY或者EINVAL同樣會讓probe失敗。這類問題和Platform匹配本身無關(guān)但極易干擾判斷建議出現(xiàn)probe失敗時先把dmesg完整拉出來看最終錯誤碼而不是只盯著最前面的日志。拿不到寄存器資源。如果節(jié)點里聲明了reg屬性驅(qū)動用platform_get_resource和devm_ioremap_resource去獲取但寄存器地址范圍跟別的設(shè)備重疊devm_ioremap_resource也會返回錯誤。很多人在probe失敗時只看到return -EBUSY卻不會想到是物理地址資源沖突。4.2 如何快速定位匹配路徑到底走到哪一步匹配失敗時核心問題是搞清楚內(nèi)核到底在哪個環(huán)節(jié)放棄了。我常用的辦法有以下幾步第一步打開內(nèi)核的驅(qū)動調(diào)試信息。在cmdline里加上ignore_loglevel和dyndbg或者簡單點使用dmesg -n 8。由于Platform總線匹配在出錯時不一定都有日志輸出這個方法有時不夠直觀但先把日志級別放到最高沒壞處。第二步在驅(qū)動里加打印。如果你不確定自己的probe是否被調(diào)用過直接在probe入口加一條dev_info或者pr_info。很多人會嫌打印土但實際調(diào)試中這永遠是最直接有效的辦法。注意probe里返回錯誤碼時內(nèi)核會打印類似“myled: probe of myled failed with error -16”的消息看到這類log就知道驅(qū)動和設(shè)備已經(jīng)匹配成功是probe內(nèi)部處理出了問題。第三步利用sysfs節(jié)點檢查匹配狀態(tài)。這是最高效的方式# 查看設(shè)備是否綁定驅(qū)動 ls -l /sys/bus/platform/devices/myled/driver # 查看驅(qū)動的名字和它支持的設(shè)備id cat /sys/bus/platform/drivers/myled/uevent ls /sys/bus/platform/drivers/myled/如果設(shè)備下driver鏈接指向了你的驅(qū)動說明已經(jīng)綁定成功probe被調(diào)用過。如果驅(qū)動目錄完全是空的說明設(shè)備樹里根本沒有符合條件的設(shè)備或者設(shè)備的compatible和你驅(qū)動里的of_match_table不一致。走到這一步匹配路徑基本就能定位出來。第四步抓總線級調(diào)試日志。內(nèi)核的驅(qū)動模型在drivers/base/dd.c里提供了許多調(diào)試信息輸出需要把CONFIG_DEBUG_DRIVER打開編譯內(nèi)核時啟用這個選項然后dmesg里會出現(xiàn)“matched device”之類的日志。這類信息量很大但如果你懷疑是匹配邏輯本身出了問題它是最權(quán)威的排查工具。4.3 一個真實的踩坑案例設(shè)備樹改名引發(fā)的詭異問題我之前在一個項目里調(diào)試一款外設(shè)驅(qū)動遇到過一個特別迷惑的現(xiàn)象驅(qū)動模塊加載沒報錯但probe就是不執(zhí)行。設(shè)備樹節(jié)點添加到dts里了也確認過dtb燒錄成功/sys/bus/platform/devices目錄下能看到設(shè)備的目錄名字也跟我預(yù)期的一樣。按照常規(guī)排查compatible我也對比過兩者看起來一模一樣。最后我實在沒辦法把兩個字符串逐個字符用十六進制打了出來這才發(fā)現(xiàn)問題設(shè)備樹里寫了“myvendor,my-led”但驅(qū)動里of_device_id寫的是“myvendor,myled”中間少了一個連字符“-”肉眼看久了確實很難發(fā)現(xiàn)。這就是為什么我強烈建議用uevent里的MODALIAS字段做嚴格比對而不是憑肉眼去檢查dts和代碼。還有一次是同事反饋說insmod之后probe沒執(zhí)行我過去查看發(fā)現(xiàn)/sys/bus/platform/devices下設(shè)備目錄能看到了但內(nèi)核日志里沒有任何關(guān)于這個設(shè)備probe失敗的記錄。通過對比dtb和dts源碼才發(fā)現(xiàn)板子實際加載的dtb是一份舊的備份文件壓根沒有他改的這個節(jié)點目錄雖然能看到但那是另一份設(shè)備樹里本來就有的同名設(shè)備compatible和寄存器地址都不同。這種環(huán)境問題最容易浪費時間排查時一定先確認板子真正加載的設(shè)備樹是不是你改的那個。4.4 probe成功后卻被移除的常見原因定位到probe被調(diào)用了但執(zhí)行到一半驅(qū)動就被移除了這類問題也很典型。最常見的原因是probe返回了錯誤碼。例如我讓你看內(nèi)核在probe失敗時打印的那行信息myled: probe of myled failed with error -16這個-16對應(yīng)- EBUSY。它可能來自platform_get_resource返回NULL后你直接return -EINVAL也可能來自gpiod_get返回錯誤。需要注意的是probe一旦返回非零內(nèi)核的driver core會認為驅(qū)動綁定失敗之后會自動執(zhí)行清理操作驅(qū)動和設(shè)備會被解除關(guān)聯(lián)看起來就像模塊被卸載了一樣。所以當(dāng)dmesg里能看到probe被調(diào)用但隨后設(shè)備driver鏈接消失不要盯著Platform匹配機制看問題基本都在probe內(nèi)部邏輯里。要做的就是把probe里每一步可能的錯誤碼都打印出來確定是哪一步返回的再去排查對應(yīng)子系統(tǒng)的問題。很多人不知道一個小細節(jié)如果probe在某個子系統(tǒng)返回EPROBE_DEFER延遲探測內(nèi)核不會立刻判定失敗而是把設(shè)備掛到一個等待隊列等對應(yīng)依賴的驅(qū)動加載完成后再重新觸發(fā)probe。這在多驅(qū)動依賴場景里非常重要。在i.MX6ULL的驅(qū)動開發(fā)中如果設(shè)備樹里引用的某個時鐘或中斷控制器對應(yīng)的驅(qū)動還沒就緒你的驅(qū)動probe可能會被反復(fù)推遲執(zhí)行。dmesg里看到“deferred probe”相關(guān)的字眼別慌這是內(nèi)核的合理等待機制你需要回頭檢查自己依賴的外設(shè)驅(qū)動有沒有加載成功。4.5 使用內(nèi)核deferred probe機制多說一句EPROBE_DEFER因為我發(fā)現(xiàn)很多新手第一次遇到它都會誤判成匹配失敗。在你的probe函數(shù)中當(dāng)你請求某個資源但該資源對應(yīng)的設(shè)備驅(qū)動還沒準(zhǔn)備好時比如調(diào)用clk_get、regulator_get、gpiod_get時返回了-EPROBE_DEFER你應(yīng)該直接把這個錯誤碼原樣返回給內(nèi)核。內(nèi)核的driver core看到返回-EPROBE_DEFER會把你的設(shè)備放到一個延遲列表中后續(xù)每當(dāng)有新的driver注冊都會重新嘗試對這些設(shè)備進行綁定和probe。這個機制保證了設(shè)備之間的依賴關(guān)系可以通過“你等我一會”的方式動態(tài)解決而不是簡單在probe里死循環(huán)等待資源就緒。實際調(diào)試時你可以在內(nèi)核cmdline中添加deferred_probe_timeout2這樣系統(tǒng)啟動后如果還存在EPROBE_DEFER的設(shè)備會在超時后打印詳細信息提示你到底在等待哪個資源。這個功能在排查啟動早期驅(qū)動順序問題時幾乎是救命稻草。4.6 常見問題速查表我把上面所有問題整理成一張速查表方便你日后直接對照排查?，F(xiàn)象常見原因排查與解決方向probe完全沒有執(zhí)行compatible不匹配對比uevent的MODALIAS與of_match_tableprobe完全沒有執(zhí)行設(shè)備節(jié)點不存在或statusdisabled檢查/proc/device-tree下節(jié)點與statusprobe沒有執(zhí)行但設(shè)備目錄存在設(shè)備驅(qū)動匹配沒觸發(fā)確認驅(qū)動有沒有注冊成功查看/sys/bus/platform/driversprobe執(zhí)行后打印錯誤GPIO或寄存器資源沖突查看dmesg錯誤碼檢查pinctrl和reg地址范圍insmod后/dev節(jié)點不出現(xiàn)udev/mdev規(guī)則未配置手動mknod或配置mdev自動創(chuàng)建規(guī)則probe反復(fù)不執(zhí)行出現(xiàn)deferred probe依賴資源尚未就緒查詢相關(guān)驅(qū)動是否加載成功必要時deferred_probe_timeout模塊無法modprobe自動加載MODULE_DEVICE_TABLE缺失或alias生成異常檢查模塊的modinfo輸出與MODALIAS匹配情況這張表你保存下來遇到問題時先對號入座。別小看這些檢查項很多資深工程師排查這類問題也基本走的是這套流程只不過他們已經(jīng)把每一步都內(nèi)化成了肌肉記憶。5. 升級認知從一套機制到整個設(shè)備模型思維5.1 Platform只是Linux設(shè)備模型里的一個縮影如果你只是想在i.MX6ULL上調(diào)通一個點燈驅(qū)動其實上面4節(jié)內(nèi)容已經(jīng)足夠。但如果你想把Linux驅(qū)動的知識體系搭得更完整我建議你從Platform這套機制中跳出來思考一下它背后統(tǒng)一的Linux內(nèi)核設(shè)備模型。Platform總線設(shè)備驅(qū)動模型本質(zhì)上只是Linux通用設(shè)備模型的一個應(yīng)用。Linux內(nèi)核維護了一個設(shè)備模型的骨架包括kobject、kset、uevent、sysfs等底層設(shè)施在這個骨架上衍生出不同類型的總線。不管是platform_bus_type、i2c_bus_type、spi_bus_type還是pci_bus_type它們都有共同的語義設(shè)備注冊、驅(qū)動注冊、總線匹配、probe調(diào)用、電源管理回調(diào)等。你在這篇文章里學(xué)到的compatible匹配、driver綁定、sysfs節(jié)點檢查這些技能在后續(xù)接觸I2C客戶端驅(qū)動、SPI設(shè)備驅(qū)動時同樣適用區(qū)別只是總線類型和匹配函數(shù)不一樣。I2C設(shè)備的client與driver通過id_table或者設(shè)備樹compatible匹配SPI設(shè)備也是類似邏輯。很多講Platform總線的教程喜歡鋪陳各種概念但我覺得內(nèi)核設(shè)備模型背后的核心設(shè)計思想才是真正值得玩味的東西把易變的、板級相關(guān)的設(shè)備描述從穩(wěn)定的驅(qū)動邏輯中剝離出來。設(shè)備樹解決了設(shè)備描述“寫在哪”的問題Platform總線解決了設(shè)備與驅(qū)動“怎么見面”的問題而GPIO、時鐘、中斷等內(nèi)核子系統(tǒng)則解決了資源“怎么共享不沖突”的問題。5.2 理解匹配機制對日常開發(fā)的實際影響哪怕你已經(jīng)能熟練地照著別人的驅(qū)動模板抄代碼我也建議你花時間把匹配機制吃透。因為不理解匹配機制你在調(diào)試時會缺少一個方向感只知道代碼寫出來沒反應(yīng)抓不住“系統(tǒng)如何認識我的設(shè)備”這條主線。舉個例子。設(shè)備樹里如果出現(xiàn)這個節(jié)點uart1 { status okay; };按我們前面說的流程內(nèi)核會把uart1節(jié)點轉(zhuǎn)換成platform_device去匹配IMX6ULL的uart驅(qū)動。如果你哪天發(fā)現(xiàn)一個串口設(shè)備死活打不開第一步就應(yīng)該去確認uart1節(jié)點是否成功創(chuàng)建了platform_device然后再看uart驅(qū)動有沒有綁定到這個設(shè)備、probe有沒有執(zhí)行。理解了這套機制之后你排查硬件驅(qū)動的順序就會變得很清晰從設(shè)備樹到平臺設(shè)備再到驅(qū)動綁定最后才是驅(qū)動內(nèi)部硬件初始化的邏輯。另一個常見場景是外設(shè)的時鐘和電源管理。Platform驅(qū)動在probe里拿到設(shè)備之后往往要操作clk和regulator子系統(tǒng)比如打開外設(shè)時鐘、調(diào)節(jié)電壓。這些資源同樣可以在設(shè)備樹節(jié)點中描述。如果資源描述不正確probe里clk_prepare_enable就會失敗。你只有理解了整個鏈條才能在設(shè)備樹、驅(qū)動代碼、內(nèi)核日志三個視角之間來回切換定位問題而不是逮著compatible死磕。5.3 如何繼續(xù)深入學(xué)習(xí)Platform相關(guān)技術(shù)如果你想在這個方向上有更扎實的積累我給幾條具體建議。第一條翻內(nèi)核源碼時別只看platform.c還要看device.h、platform_device.h、of_device.h這幾個頭文件把platform_device、platform_driver、of_device_id這幾個結(jié)構(gòu)體的字段都弄明白尤其是resource結(jié)構(gòu)體理解IORESOURCE_MEM、IORESOURCE_IRQ的用法。probe里那些platform_get_resource、platform_get_irq之類的API其實都是在操作resource結(jié)構(gòu)體明白了數(shù)據(jù)結(jié)構(gòu)你再去看接口函數(shù)不會覺得它們散亂。第二條自己獨立完成一次從設(shè)備樹建節(jié)點到用戶空間應(yīng)用程序調(diào)用完整鏈路的實驗。別只抄教程看完文章后關(guān)掉網(wǎng)頁自己憑理解寫一版踩過的坑記得越牢成長越快。實驗時可以刻意制造幾個錯誤比如把compatible故意寫錯、把status設(shè)為disabled觀察probe失敗的具體表現(xiàn)然后再修正回來。這種做法比重復(fù)抄代碼有用得多。第三條條件允許的話用QEMU或者虛擬平臺去讀內(nèi)核源碼里更多總線模型的實現(xiàn)。i.MX6ULL開發(fā)板適合做真實的硬件對接但如果你想在更深層面理解Linux設(shè)備模型比如分析bus_type結(jié)構(gòu)體的match、uevent、probe回調(diào)在driver core里如何被調(diào)度一臺能編譯內(nèi)核的Linux主機配合QEMU的virt平臺調(diào)試效率可能比反復(fù)燒錄板子更高。6. 最后再分享幾個調(diào)試小技巧調(diào)試Platform驅(qū)動時有幾條經(jīng)驗我覺得很有用分享給你們。第一dmesg一定要養(yǎng)成隨手清空的習(xí)慣。開發(fā)板長期運行內(nèi)核日志緩沖區(qū)會被各種無關(guān)消息占滿容易把關(guān)鍵日志沖掉。每次insmod之前先dmesg -c把舊日志清掉加載之后再看dmesg輸出這樣probe里打印的信息一目了然不會遺漏。第二多利用sysfs少依賴暴力加打印。sysfs是內(nèi)核設(shè)備模型的實時投影/sys/bus/platform/devices目錄下的每個符號鏈接和uevent文件都是判斷設(shè)備狀態(tài)的最可靠依據(jù)。很多問題看一眼驅(qū)動鏈接、cat一下uevent就能定位完全不需要重新編譯模塊加打印。雖然加打印在調(diào)試probe內(nèi)部邏輯時仍然必要但先通過sysfs確認匹配狀態(tài)能幫你少走很多彎路。第三改設(shè)備樹之后一定要確認板子加載的是你編譯的新dtb。嵌入式開發(fā)中啟動流程各有差異有的從SD卡讀dtb有的從EMMC指定分區(qū)讀有的通過u-boot環(huán)境變量指定tftp加載。改完設(shè)備樹卻忘記更新對應(yīng)位置的dtb是我見過最頻繁的低級錯誤。調(diào)試設(shè)備樹相關(guān)問題時先在板子上執(zhí)行l(wèi)s /proc/device-tree/看看節(jié)點是否真實存在再往下排查能省掉大量無意義的工作。第四合理使用devm系列的資源管理API。我在示例驅(qū)動里大量使用了devm_kzalloc、devm_gpiod_get這些devm前綴的函數(shù)本質(zhì)上是把資源釋放的責(zé)任掛在struct device的生命周期上。probe成功之后設(shè)備與驅(qū)動解除綁定時內(nèi)核會自動幫你釋放這些資源。這能有效避免probe失敗時忘記釋放之前申請的資源導(dǎo)致的問題。不夸張地說內(nèi)核里devm系列API的出現(xiàn)讓驅(qū)動資源管理的出錯率降低了一個量級。第五也是我覺得最重要的一點不要急著一次寫完整個驅(qū)動。你可以先把probe函數(shù)只留一條打印確認匹配鏈路通順再一步步加上GPIO申請、寄存器映射、設(shè)備注冊等邏輯。每一次小步驗證都能讓問題邊界變得非常清晰。真按這種方式做大多數(shù)Platform匹配類問題在半個小時內(nèi)就能定位遠比你一股腦寫完兩百行驅(qū)動再調(diào)半天高效得多。我在實際項目里用這套方法解決過的問題不計其數(shù)甚至有時候不是i.MX6ULL平臺換成其它ARM SoC或者RISC-V芯片只要內(nèi)核還是Linux這套Platform設(shè)備與驅(qū)動匹配機制基本不會變調(diào)試思路也是相通的。這就是花時間把機制理解透的價值。 i.MX6ULL Linux驅(qū)動開發(fā)：Platform總線設(shè)備與驅(qū)動匹配機制全解析
做i.MX6ULL的Linux驅(qū)動開發(fā)很多人第一次接觸Platform總線時都是一頭霧水明明照著教程寫完了一個platform_driverinsmod也成功了但probe函數(shù)就是不執(zhí)行設(shè)備號也申請不到折騰一整天最后發(fā)現(xiàn)是設(shè)備樹里compatible字段和驅(qū)動里的of_match_table沒有對上。這個坑我踩過帶過的不少新同事也踩過所以我想把i.MX6ULL平臺下這套設(shè)備與驅(qū)動匹配機制徹底講透從內(nèi)核為什么要搞Platform這一套東西到匹配流程內(nèi)部到底發(fā)生了什么事再到怎么自己寫一個能被正常probe的驅(qū)動、怎么排查匹配失敗的問題一次說清楚。這篇文章適合正在學(xué)嵌入式Linux驅(qū)動開發(fā)、尤其是用i.MX6ULL或者類似Cortex-A7核心板做項目的朋友閱讀不管你是剛看完字符設(shè)備驅(qū)動、準(zhǔn)備往設(shè)備樹和Platform模型過渡還是已經(jīng)寫了不少驅(qū)動但一直沒認真搞明白匹配原理都能從里面得到能直接拿去用的東西。1. 先搞清楚Platform機制到底解決了什么問題1.1 早期字符設(shè)備驅(qū)動寫法為什么撐不住了咱們先把時間拉回到Linux 2.6之前。早期寫驅(qū)動最常見的方式就是把板子上的硬件資源寫死在驅(qū)動代碼里。比如你要操作一個LED對應(yīng)的GPIO寄存器直接在驅(qū)動里硬編碼物理地址ioremap之后對著寄存器地址寫值如果要注冊一個中斷也是直接寫死中斷號。這種方式在嵌入式開發(fā)早期確實簡單粗暴能用但問題很快就暴露出來了。首先是資源沖突。同一個芯片可能被用在幾十種板卡上A板子LED接在GPIO1_IO03B板子LED接在GPIO1_IO05同一份驅(qū)動代碼在兩塊板子上就沒法通用。其次是設(shè)備變更帶來的維護地獄硬件工程師說改一下引腳連接驅(qū)動開發(fā)就得跟著改源碼重新編譯版本管理一混亂哪天改錯了哪個地址排查起來極其痛苦。這就引出了Linux設(shè)備模型里最重要的思路驅(qū)動是驅(qū)動設(shè)備是設(shè)備兩者分開維護通過一種統(tǒng)一的機制在運行時完成匹配和綁定。驅(qū)動只負責(zé)描述“我能操作什么類型的外設(shè)、怎么操作”設(shè)備則描述“這塊板子上實際有哪些外設(shè)、外設(shè)的資源寄存器地址、中斷號、GPIO等在哪里”。誰也不要寫死誰。1.2 總線、設(shè)備、驅(qū)動三角色如何分工Linux為了解決上面的問題抽象出了總線bus、設(shè)備device、驅(qū)動driver三個角色。PCI設(shè)備有PCI總線USB設(shè)備有USB總線它們都是真實存在的物理總線設(shè)備和驅(qū)動都掛在這種總線上由總線子系統(tǒng)負責(zé)匹配。問題來了SoC內(nèi)部的很多外設(shè)控制器比如I2C控制器、SPI控制器、UART、GPIO控制器、以太網(wǎng)MAC它們并不是掛在PCI或者USB這種物理枚舉總線上面的。系統(tǒng)啟動時這些設(shè)備是固定存在的不需要像USB設(shè)備那樣去掃描發(fā)現(xiàn)。為了讓這些“天生就存在”的片上外設(shè)也能套用總線-設(shè)備-驅(qū)動模型內(nèi)核提供了一個虛擬總線叫platform_bus也就是咱們常說的Platform總線。Platform總線上掛的“設(shè)備”叫platform_device可以是芯片內(nèi)部集成的外設(shè)控制器也可以是指定為platform_device的外部設(shè)備。在Device Tree設(shè)備樹普及之后內(nèi)核在啟動階段會解析設(shè)備樹把其中匹配到的節(jié)點一個一個轉(zhuǎn)換成platform_device掛到platform總線上。驅(qū)動這邊只要你寫的是platform_driver注冊時就會掛到同一條虛擬總線上。總線負責(zé)撮合新來了一個platform_device總線就去看看現(xiàn)有的platform_driver有沒有能匹配上它的新注冊了一個platform_driver總線又會反過來掃描現(xiàn)有的platform_device。一旦匹配成功總線就會調(diào)用driver里的probe函數(shù)把設(shè)備相關(guān)的資源信息交給你你的驅(qū)動從這一刻才開始真正初始化硬件。1.3 i.MX6ULL上哪些資源依賴這套機制i.MX6ULL是NXP基于Cortex-A7內(nèi)核設(shè)計的低功耗應(yīng)用處理器內(nèi)部集成了大量的外設(shè)控制器?？梢赃@么說除了內(nèi)存控制器等極少數(shù)基礎(chǔ)組件芯片上幾乎你能用到的所有外設(shè)控制器在Linux內(nèi)核里都是以platform_device的形式存在或者由設(shè)備樹節(jié)點轉(zhuǎn)換而來的。舉個例子你就會明白設(shè)備樹里經(jīng)?？吹筋愃七@樣的節(jié)點i2c1 { clock-frequency 100000; pinctrl-names default; pinctrl-0 pinctrl_i2c1; status okay; };這個i2c1節(jié)點在內(nèi)核啟動階段會被轉(zhuǎn)換成platform_device然后去匹配I2C控制器驅(qū)動里的platform_driver匹配成功進入probe之后驅(qū)動才會去初始化i2c適配器、注冊i2c總線。之后再發(fā)現(xiàn)掛在這條i2c總線上的客戶端設(shè)備就又是另一套i2c_client的匹配邏輯了。搞懂這個流程你就能明白為什么很多時候我們給某個外設(shè)控制器寫驅(qū)動第一個函數(shù)入口不是file_operations里的open/release而是probe函數(shù)。因為你的驅(qū)動首先要被“系統(tǒng)認識”通過Platform匹配機制綁定到對應(yīng)設(shè)備上才有資格去操作硬件資源。2. 匹配機制全解析一條probe是怎么被叫醒的2.1 驅(qū)動和設(shè)備在什么時機相互打量一個platform_driver從注冊到它的probe被調(diào)用中間經(jīng)歷的過程非常關(guān)鍵。很多人只知道寫驅(qū)動時要注冊platform_driver但不知道probe調(diào)用的完整時機。當(dāng)你在驅(qū)動里調(diào)用platform_driver_register的時候內(nèi)核會把driver掛到platform_bus_type這根虛擬總線上然后立刻執(zhí)行一次總線對已有設(shè)備的掃描。內(nèi)核會遍歷platform bus上所有的device對每一個設(shè)備調(diào)用platform_match函數(shù)看看你的driver跟哪個設(shè)備能配對。只要找到一個配對的設(shè)備立刻執(zhí)行probe。反過來設(shè)備是怎么來的有兩種常見來源。傳統(tǒng)方式是通過platform_device_register主動注冊平臺代碼里構(gòu)造platform_device結(jié)構(gòu)體然后塞給內(nèi)核這在老內(nèi)核或者不使用設(shè)備樹的場景中很常見?，F(xiàn)在的主流方式則是設(shè)備樹內(nèi)核在啟動時用of_platform_default_populate_init遍歷設(shè)備樹根節(jié)點下的所有節(jié)點把 compatible 屬性匹配的節(jié)點變成platform_device隨后掃描驅(qū)動列表完成匹配。所以probe被調(diào)用的時機其實有兩種典型場景如果你先加載驅(qū)動后注冊設(shè)備比如設(shè)備樹節(jié)點本來就在但驅(qū)動是后面insmod的那么在platform_driver_register內(nèi)部掃描設(shè)備時就會觸發(fā)probe。如果設(shè)備在你驅(qū)動的probe執(zhí)行過程中又創(chuàng)建了子設(shè)備比如MFD多功能設(shè)備驅(qū)動創(chuàng)建子平臺設(shè)備那是設(shè)備注冊時反向掃描驅(qū)動觸發(fā)probe。理解這個雙向掃描邏輯后面排查“為什么probe沒跑”時就能有個清晰的方向到底是設(shè)備始終沒被創(chuàng)建還是設(shè)備與驅(qū)動的匹配條件不滿足。2.2 內(nèi)核源碼里platform_match的匹配順序要真正理解匹配機制不能只看概念我建議你打開內(nèi)核源碼里drivers/base/platform.c找到platform_match函數(shù)。不同內(nèi)核版本可能會有細微差別但核心邏輯基本穩(wěn)定。整個匹配過程大概分這么幾步static int platform_match(struct device *dev, struct device_driver *drv) { struct platform_device *pdev to_platform_device(dev); struct platform_driver *pdrv to_platform_driver(drv); /* 1. 嘗試設(shè)備樹匹配 */ if (of_driver_match_device(dev, drv)) return 1; /* 2. 嘗試ACPI匹配 */ if (acpi_driver_match_device(dev, drv)) return 1; /* 3. 嘗試platform專用id_table匹配 */ if (pdrv-id_table) if (platform_match_id(pdrv-id_table, pdev) ! NULL) return 1; /* 4. 嘗試驅(qū)動名字與設(shè)備名字直接匹配 */ return (strcmp(pdev-name, drv-name) 0); }需要注意的是在沒有使能ACPI的嵌入式ARM平臺上第二步通常不會生效關(guān)鍵的匹配路徑就是設(shè)備樹compatible匹配、id_table匹配和名字匹配三路。最初級的匹配方法是驅(qū)動程序名和設(shè)備名相同。早期platform驅(qū)動在driver結(jié)構(gòu)體和platform_device結(jié)構(gòu)體的name字段直接保持一致即可。這種匹配路線現(xiàn)在仍然存在但更多是兜底邏輯。設(shè)備樹普及之后絕大多數(shù)場景走的是第一條of_driver_match_device。設(shè)備樹匹配的核心是compatible屬性。設(shè)備樹里的每個節(jié)點只要是代表一個真實的設(shè)備基本都要寫compatible屬性。比如某個外設(shè)節(jié)點長得這樣mydevice: mydevice020c406c { compatible myvendor,mydevice; reg 0x020c406c 0x4; ... };驅(qū)動側(cè)就要在of_device_id數(shù)組里提供一個同樣的compatible字符串static const struct of_device_id mydevice_of_match[] { { .compatible myvendor,mydevice, }, { /* sentinel */ }, }; MODULE_DEVICE_TABLE(of, mydevice_of_match); static struct platform_driver mydevice_driver { .probe mydevice_probe, .remove mydevice_remove, .driver { .name mydevice, .of_match_table mydevice_of_match, }, }; module_platform_driver(mydevice_driver);匹配時內(nèi)核拿設(shè)備樹節(jié)點的compatible屬性字符串和of_match_table數(shù)組里所有compatible字段逐一比較只要有一個相等就算匹配成功。2.3 of_device_id里藏的小秘密data指針很多基礎(chǔ)教程在講of_device_id時只強調(diào)compatible字段必須對齊卻忽略了一個很實用的字段data。我在這兒重點說一下。of_device_id結(jié)構(gòu)體的data成員是一個void指針用于在驅(qū)動側(cè)攜帶與某個compatible關(guān)聯(lián)的私有數(shù)據(jù)。比如同一顆芯片上可能有多個功能相近但寄存器細節(jié)不同的IP核驅(qū)動里可以共用同一個probe函數(shù)但在of_device_id里通過data來區(qū)分IP版本probe時用of_match_device取出當(dāng)前匹配到的of_device_id然后強轉(zhuǎn)data拿到不同的硬件信息。我給你一個實際場景。假設(shè)板子上有兩個LED控制器一個老版本寄存器地址偏移不同一個新版本兩者的compatible分別是“myvendor,led-v1”和“myvendor,led-v2”。如果用兩套of_match_table分別寫兩個驅(qū)動顯然很蠢。更聰明的做法是一個驅(qū)動of_match_table里放兩個條目data分別指向不同的led_hw_cfg結(jié)構(gòu)體static struct led_hw_cfg led_v1_cfg { .reg_offset 0x00, .max_brightness 255, }; static struct led_hw_cfg led_v2_cfg { .reg_offset 0x10, .max_brightness 1023, }; static const struct of_device_id myled_of_match[] { { .compatible myvendor,led-v1, .data led_v1_cfg }, { .compatible myvendor,led-v2, .data led_v2_cfg }, { /* sentinel */ }, }; static int myled_probe(struct platform_device *pdev) { const struct of_device_id *match; struct led_hw_cfg *cfg; match of_match_device(myled_of_match, pdev-dev); if (match) cfg (struct led_hw_cfg *)match-data; ... }這個用法在NXP官方內(nèi)核以及很多主流驅(qū)動里都能看到做好之后板級差異就被壓縮到一個結(jié)構(gòu)體數(shù)據(jù)里驅(qū)動代碼的復(fù)用性明顯提升。2.4 匹配成功后內(nèi)核額外做的幾件事匹配成功后內(nèi)核會自動補齊一些基礎(chǔ)信息接著才會調(diào)用你的probe。首先是dev_set_drvdata一類內(nèi)部關(guān)聯(lián)操作讓設(shè)備與驅(qū)動之間建立關(guān)聯(lián)之后你在probe內(nèi)部用的dev_get_drvdata才有效。其次是sysfs文件系統(tǒng)視角下/sys/bus/platform/devices目錄下的設(shè)備會出現(xiàn)一個driver符號鏈接指向/sys/bus/platform/drivers下面你的驅(qū)動目錄。還有一點很多剛?cè)腴T的新人會困惑為什么probe里已經(jīng)用misc_register注冊了字符設(shè)備但insmod之后/dev下并沒有立刻出現(xiàn)對應(yīng)節(jié)點這跟Platform匹配機制無關(guān)但發(fā)生場景經(jīng)常重合。insmod執(zhí)行后probe成功調(diào)用了設(shè)備注冊動作在probe里也完成了但用戶空間的udev或者mdev嵌入式環(huán)境常用busybox mdev需要在收到uevent事件后去創(chuàng)建/dev節(jié)點。如果你的系統(tǒng)里沒有配置udev/mdev自動處理那/dev下確實不會自動出現(xiàn)設(shè)備節(jié)點。這一點在之后的調(diào)試過程中非常常見別把板子本身的問題和匹配機制混為一談。另外如果設(shè)備節(jié)點被設(shè)置為status disabled那么內(nèi)核掃描設(shè)備樹時一般不會為該節(jié)點創(chuàng)建platform_device。注意是“一般不會”。有些場合下節(jié)點會被創(chuàng)建但驅(qū)動會被禁止綁定具體取決于內(nèi)核的配置。在i.MX6ULL這種主流BSP中disabled節(jié)點基本不會生成platform_device因此你的驅(qū)動永遠得不到probe的機會。這是一個非常隱蔽的坑后面排查部分我會專門提到。3. 在i.MX6ULL上實操寫一個能匹配上的Platform驅(qū)動3.1 環(huán)境準(zhǔn)備與基礎(chǔ)工程建議咱們動手寫一個完整的Platform驅(qū)動別空談理論。我用的是i.MX6ULL開發(fā)板內(nèi)核版本以4.1.15或者4.9.x為主這也是目前市面上不少i.MX6ULL開發(fā)板BSP的常見內(nèi)核版本。交叉編譯工具鏈一般是arm-linux-gnueabihf-根據(jù)你自己開發(fā)板配套的SDK來定。寫驅(qū)動之前我建議先確認三件事內(nèi)核源碼目錄已經(jīng)準(zhǔn)備好并且編譯過一遍生成了Module.symvers。開發(fā)板內(nèi)核里設(shè)備樹已經(jīng)支持你將要修改的節(jié)點或者你知道怎么把新的dtb燒進去。板子上的文件系統(tǒng)能夠加載內(nèi)核模塊比如insmod/modprobe命令可用。寫驅(qū)動文件之前先在板子上執(zhí)行下面這條命令看看當(dāng)前系統(tǒng)里platform設(shè)備的大致情況ls /sys/bus/platform/devices/你會看到很多設(shè)備比如soc、1001000.uart、2000000.spi之類名字一般是“寄存器地址.設(shè)備名”的格式這些就是內(nèi)核從設(shè)備樹里解析出來后掛到platform總線上的設(shè)備。等下咱們自己通過設(shè)備樹創(chuàng)建的設(shè)備也會以類似的形式出現(xiàn)在這個目錄。3.2 設(shè)備樹中定義自己的平臺設(shè)備節(jié)點我們的目標(biāo)是創(chuàng)建一個叫“myled”的平臺設(shè)備然后讓驅(qū)動程序通過compatible匹配到它進入probe最后操作一個GPIO點燈。你需要在設(shè)備樹源文件里找到根節(jié)點或者合適的父節(jié)點添加以下這個節(jié)點。很多i.MX6ULL開發(fā)板的設(shè)備樹頂層是板級dts文件如imx6ull-14x14-evk.dts里面有根節(jié)點“/”往根節(jié)點里加就行了。有些為了方便管理會放在根節(jié)點的某個子節(jié)點中只要能被內(nèi)核正常解析到就行放在根下最直觀。/ { myled { compatible myvendor,myled; pinctrl-names default; pinctrl-0 pinctrl_myled; led-gpio gpio1 3 GPIO_ACTIVE_LOW; status okay; }; };注意這個節(jié)點里我引用了pinctrl_myled你必須在設(shè)備樹里對應(yīng)的iomuxc節(jié)點下添加這個引腳復(fù)用配置。以i.MX6ULL為例通常在設(shè)備樹中可以找到類似這么一段iomuxc { pinctrl_myled: myledgrp { fsl,pins MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0x10b0 ; }; };引腳的宏定義MX6UL_PAD_GPIO1_IO03__GPIO1_IO03在設(shè)備樹頭文件里已經(jīng)定義好不同開發(fā)板這個宏可能不一樣具體看你的BSP設(shè)備樹。我這里只是給你一個示例實際操作時必須以自己板卡上的引腳為依據(jù)。改完設(shè)備樹之后重新編譯dtb然后燒錄或者通過tftp/nfs方式加載到板子上啟動。啟動后在板子上執(zhí)行l(wèi)s /sys/bus/platform/devices/myled如果設(shè)備樹解析正常你應(yīng)該能看到這個目錄存在。到這一步你的“平臺設(shè)備”已經(jīng)創(chuàng)建成功內(nèi)核里已經(jīng)存在一個platform_device就等著驅(qū)動來匹配了。如果看不到設(shè)備目錄優(yōu)先檢查設(shè)備樹有沒有被正確編譯加載compatible、status屬性有沒有問題。3.3 編寫Platform驅(qū)動并正確注冊接下來寫驅(qū)動。為了把注意力集中在Platform機制上我直接用一個最簡單的點燈驅(qū)動示例通過miscdevice注冊字符設(shè)備用戶程序用ioctl控制亮滅極簡版。完整代碼示例#include linux/module.h #include linux/platform_device.h #include linux/of.h #include linux/of_gpio.h #include linux/gpio/consumer.h #include linux/miscdevice.h #include linux/uaccess.h #include linux/fs.h #define MYLED_ON 0x01 #define MYLED_OFF 0x00 struct myled_dev { struct gpio_desc *led_gpio; }; static struct myled_dev *myled_data; static long myled_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { switch (cmd) { case MYLED_ON: gpiod_set_value(myled_data-led_gpio, 1); break; case MYLED_OFF: gpiod_set_value(myled_data-led_gpio, 0); break; default: return -EINVAL; } return 0; } static const struct file_operations myled_fops { .owner THIS_MODULE, .unlocked_ioctl myled_ioctl, }; static struct miscdevice myled_miscdev { .minor MISC_DYNAMIC_MINOR, .name myled, .fops myled_fops, }; static int myled_probe(struct platform_device *pdev) { struct device *dev pdev-dev; int ret; dev_info(dev, myled probe success\n); myled_data devm_kzalloc(dev, sizeof(*myled_data), GFP_KERNEL); if (!myled_data) return -ENOMEM; myled_data-led_gpio devm_gpiod_get(dev, led, GPIOD_OUT_LOW); if (IS_ERR(myled_data-led_gpio)) { ret PTR_ERR(myled_data-led_gpio); dev_err(dev, failed to get led gpio: %d\n, ret); return ret; } gpiod_set_consumer_name(myled_data-led_gpio, myled); ret misc_register(myled_miscdev); if (ret) { dev_err(dev, failed to register misc device\n); return ret; } return 0; } static int myled_remove(struct platform_device *pdev) { misc_deregister(myled_miscdev); return 0; } static const struct of_device_id myled_of_match[] { { .compatible myvendor,myled, }, { /* sentinel */ }, }; MODULE_DEVICE_TABLE(of, myled_of_match); static struct platform_driver myled_driver { .probe myled_probe, .remove myled_remove, .driver { .name myled, .of_match_table myled_of_match, }, }; module_platform_driver(myled_driver); MODULE_LICENSE(GPL); MODULE_AUTHOR(Your Name); MODULE_DESCRIPTION(i.MX6ULL platform device match demo);這個驅(qū)動用module_platform_driver宏完成platform_driver_register和platform_driver_unregister的封裝。加載時注冊驅(qū)動總線掃描設(shè)備后如果匹配成功probe就會被調(diào)用。3.4 編譯、加載與查看匹配效果對應(yīng)的Makefile非常簡單obj-m : myled.o KERNELDIR : /path/to/your/kernel CROSS_COMPILE : arm-linux-gnueabihf- CC : $(CROSS_COMPILE)gcc all: $(MAKE) -C $(KERNELDIR) M$(PWD) ARCHarm CROSS_COMPILE$(CROSS_COMPILE) modules clean: $(MAKE) -C $(KERNELDIR) M$(PWD) ARCHarm CROSS_COMPILE$(CROSS_COMPILE) clean編譯之后得到myled.ko拷貝到板子上insmod加載insmod myled.ko正常的話dmesg里能看到myled myled: myled probe success此時查看platform總線的設(shè)備與驅(qū)動綁定關(guān)系ls -l /sys/bus/platform/devices/myled/driver如果驅(qū)動已經(jīng)成功綁定這個符號鏈接會指向drivers目錄下的myled驅(qū)動。再用設(shè)備名匹配方式來驗證一下純名字匹配路徑的優(yōu)先級問題如果設(shè)備樹里沒有compatible而你的platform_device是內(nèi)核代碼直接注冊的driver結(jié)構(gòu)體里的name字段和設(shè)備name相同也可能匹配成功。這一點雖然老派在兼容舊代碼時很有用。3.5 GPIO子系統(tǒng)在Platform機制中扮演的輔助角色在剛才的驅(qū)動里我用到了devm_gpiod_get和gpiod_set_value這是內(nèi)核GPIO子系統(tǒng)提供的基于描述符的接口。你可能會疑惑這跟Platform匹配機制有什么關(guān)系關(guān)系其實不直接但屬于Platform設(shè)備操作最典型的資源獲取方式。傳統(tǒng)開發(fā)中要操作GPIO需要ioremap并配置引腳復(fù)用寄存器很繁瑣?，F(xiàn)在的推薦姿勢是在設(shè)備樹節(jié)點里通過led-gpio這樣的屬性描述“我需要哪個引腳”驅(qū)動中通過devm_gpiod_get獲取GPIO描述符。這個API能正常工作前提是你傳入了指向struct device的指針也就是platform_device里的pdev-dev。設(shè)備樹、GPIO子系統(tǒng)、Platform驅(qū)動模型這三者是緊密配合的。Platform總線匹配只是給你一個“入場券”入場之后怎么拿資源、怎么使用硬件又注冊了另一套內(nèi)核API。很多教程把這幾個維度混在一起新手就容易懵。我建議你在實驗時把這條鏈路拆開理解設(shè)備樹節(jié)點 設(shè)備說明書描述有什么資源。Platform驅(qū)動匹配 驗證“這個驅(qū)動能管這個設(shè)備”。probe函數(shù) 驅(qū)動讀取說明書實際操作資源。misc或者字符設(shè)備框架 把操作能力暴露給用戶空間。3.6 id_table匹配方式與非設(shè)備樹場景聊完設(shè)備樹方式咱們也花點時間說說id_table匹配。畢竟并非所有內(nèi)核和所有平臺都使用設(shè)備樹而老平臺代碼里大量存在platform_device_id的使用方式。如果你有一個平臺設(shè)備它不是從設(shè)備樹生成的而是通過platform_device_register注冊的例如內(nèi)核板級文件里這么寫static struct resource myled_resources[] { { .start 0x020c406c, .end 0x020c406f, .flags IORESOURCE_MEM, }, }; static struct platform_device myled_device { .name myled, .id -1, .num_resources ARRAY_SIZE(myled_resources), .resource myled_resources, }; static int __init myled_device_init(void) { return platform_device_register(myled_device); }你的驅(qū)動需要通過platform_driver里的id_table來匹配而不只是名字。使用示例static const struct platform_device_id myled_id_table[] { { myled, 0 }, { }, }; MODULE_DEVICE_TABLE(platform, myled_id_table); static struct platform_driver myled_driver { .probe myled_probe, .remove myled_remove, .driver { .name myled, }, .id_table myled_id_table, };platform_match內(nèi)部執(zhí)行順序是先查of_match_table再查ACPI再查id_table最后才是driver name與device name直接比較。但這里有個細節(jié)如果驅(qū)動同時配置了of_match_table和id_table設(shè)備樹匹配又是首要路徑許多時候驅(qū)動作者會把compatible匹配的設(shè)備也放進id_table里主要是為了MODULE_DEVICE_TABLE生成模塊別名方便modprobe自動加載模塊。“為什么我明明把驅(qū)動編譯成模塊放到文件系統(tǒng)了modprobe能識別到模塊卻還是會找不到設(shè)備”這類問題經(jīng)常就是模塊別名機制的問題。modprobe在加載模塊前要根據(jù)設(shè)備uevent里的MODALIAS環(huán)境變量去尋找對應(yīng)的模塊MODALIAS內(nèi)容與設(shè)備樹compatible相關(guān)而模塊中通過MODULE_DEVICE_TABLE導(dǎo)出的表決定了內(nèi)核知道這個模塊能支持哪些設(shè)備。如果你只寫了of_match_table沒有同步MODULE_DEVICE_TABLE自動加載時可能就會出問題。這個知識點一般很少人講透遇到了先檢查這里不會錯。4. 匹配失敗排查與調(diào)試經(jīng)驗4.1 最常見的匹配失敗原因匹配失敗是驅(qū)動開發(fā)里最磨人的問題之一。根據(jù)我?guī)ы椖康慕?jīng)驗下面這些原因幾乎覆蓋了八成以上的失敗場景你排查時不妨按順序過一遍。compatible字符串不一致這是頭號問題。設(shè)備樹里寫著myvendor,myled驅(qū)動of_match_table里寫的是myvendor,myled 多了個空格或者大小寫不一致都匹配不上。排查方法很簡單在板子上執(zhí)行cat /sys/bus/platform/devices/myled/uevent看輸出的MODALIAS字段OF_NAMEmyled OF_FULLNAME/myled OF_COMPATIBLE_0myvendor,myled MODALIASof:NmyledTNULLCmyvendor,myled然后對比驅(qū)動模塊中由of_match_table生成的模塊別名。也可以直接看/proc/device-tree下設(shè)備樹節(jié)點里的屬性是否和你期望的一致。設(shè)備樹沒過。這個問題尤其隱蔽因為很多開發(fā)板啟動時用的不是最新編譯的dtb你改了dts但忘了重新編譯或者編譯了沒有傳到板子對應(yīng)的啟動分區(qū)。排查方法很直接在板子上重新查看設(shè)備樹里你添加的節(jié)點是否存在例如ls /proc/device-tree/myled/ cat /proc/device-tree/myled/compatiblestatus屬性被設(shè)成disabled。如前所述disabled狀態(tài)可能導(dǎo)致platform_device根本不創(chuàng)建。檢查節(jié)點status是否為okay或者干脆去掉status屬性。有些BSP中特定父節(jié)點下的status控制邏輯還會有差異需要具體問題具體分析但第一懷疑對象一定是這里。pinctrl配置出錯。節(jié)點里的pinctrl-0引用了不存在的pinctrl_myled節(jié)點或者引用的引腳宏跟iomuxc里實際配置不一致雖然不直接影響Platform匹配但probe里GPIO請求時會失敗導(dǎo)致probe返回錯誤碼驅(qū)動被卸載現(xiàn)象看起來跟匹配失敗一樣。排查時可以先用以下命令確認這個設(shè)備是否綁定過驅(qū)動ls -l /sys/bus/platform/devices/myled/driver如果driver鏈接存在說明匹配成功過probe里報錯的可能性更大如果不存在才說明匹配階段都沒走通。GPIO號沖突或者重復(fù)申請。i.MX6ULL的GPIO資源管理通過GPIO子系統(tǒng)完成如果你在設(shè)備樹里把同一個引腳用在兩個不同節(jié)點或者驅(qū)動里重復(fù)請求了同一個GPIOdevm_gpiod_get會返回錯誤。典型報錯是EBUSY或者EINVAL同樣會讓probe失敗。這類問題和Platform匹配本身無關(guān)但極易干擾判斷建議出現(xiàn)probe失敗時先把dmesg完整拉出來看最終錯誤碼而不是只盯著最前面的日志。拿不到寄存器資源。如果節(jié)點里聲明了reg屬性驅(qū)動用platform_get_resource和devm_ioremap_resource去獲取但寄存器地址范圍跟別的設(shè)備重疊devm_ioremap_resource也會返回錯誤。很多人在probe失敗時只看到return -EBUSY卻不會想到是物理地址資源沖突。4.2 如何快速定位匹配路徑到底走到哪一步匹配失敗時核心問題是搞清楚內(nèi)核到底在哪個環(huán)節(jié)放棄了。我常用的辦法有以下幾步第一步打開內(nèi)核的驅(qū)動調(diào)試信息。在cmdline里加上ignore_loglevel和dyndbg或者簡單點使用dmesg -n 8。由于Platform總線匹配在出錯時不一定都有日志輸出這個方法有時不夠直觀但先把日志級別放到最高沒壞處。第二步在驅(qū)動里加打印。如果你不確定自己的probe是否被調(diào)用過直接在probe入口加一條dev_info或者pr_info。很多人會嫌打印土但實際調(diào)試中這永遠是最直接有效的辦法。注意probe里返回錯誤碼時內(nèi)核會打印類似“myled: probe of myled failed with error -16”的消息看到這類log就知道驅(qū)動和設(shè)備已經(jīng)匹配成功是probe內(nèi)部處理出了問題。第三步利用sysfs節(jié)點檢查匹配狀態(tài)。這是最高效的方式# 查看設(shè)備是否綁定驅(qū)動 ls -l /sys/bus/platform/devices/myled/driver # 查看驅(qū)動的名字和它支持的設(shè)備id cat /sys/bus/platform/drivers/myled/uevent ls /sys/bus/platform/drivers/myled/如果設(shè)備下driver鏈接指向了你的驅(qū)動說明已經(jīng)綁定成功probe被調(diào)用過。如果驅(qū)動目錄完全是空的說明設(shè)備樹里根本沒有符合條件的設(shè)備或者設(shè)備的compatible和你驅(qū)動里的of_match_table不一致。走到這一步匹配路徑基本就能定位出來。第四步抓總線級調(diào)試日志。內(nèi)核的驅(qū)動模型在drivers/base/dd.c里提供了許多調(diào)試信息輸出需要把CONFIG_DEBUG_DRIVER打開編譯內(nèi)核時啟用這個選項然后dmesg里會出現(xiàn)“matched device”之類的日志。這類信息量很大但如果你懷疑是匹配邏輯本身出了問題它是最權(quán)威的排查工具。4.3 一個真實的踩坑案例設(shè)備樹改名引發(fā)的詭異問題我之前在一個項目里調(diào)試一款外設(shè)驅(qū)動遇到過一個特別迷惑的現(xiàn)象驅(qū)動模塊加載沒報錯但probe就是不執(zhí)行。設(shè)備樹節(jié)點添加到dts里了也確認過dtb燒錄成功/sys/bus/platform/devices目錄下能看到設(shè)備的目錄名字也跟我預(yù)期的一樣。按照常規(guī)排查compatible我也對比過兩者看起來一模一樣。最后我實在沒辦法把兩個字符串逐個字符用十六進制打了出來這才發(fā)現(xiàn)問題設(shè)備樹里寫了“myvendor,my-led”但驅(qū)動里of_device_id寫的是“myvendor,myled”中間少了一個連字符“-”肉眼看久了確實很難發(fā)現(xiàn)。這就是為什么我強烈建議用uevent里的MODALIAS字段做嚴格比對而不是憑肉眼去檢查dts和代碼。還有一次是同事反饋說insmod之后probe沒執(zhí)行我過去查看發(fā)現(xiàn)/sys/bus/platform/devices下設(shè)備目錄能看到了但內(nèi)核日志里沒有任何關(guān)于這個設(shè)備probe失敗的記錄。通過對比dtb和dts源碼才發(fā)現(xiàn)板子實際加載的dtb是一份舊的備份文件壓根沒有他改的這個節(jié)點目錄雖然能看到但那是另一份設(shè)備樹里本來就有的同名設(shè)備compatible和寄存器地址都不同。這種環(huán)境問題最容易浪費時間排查時一定先確認板子真正加載的設(shè)備樹是不是你改的那個。4.4 probe成功后卻被移除的常見原因定位到probe被調(diào)用了但執(zhí)行到一半驅(qū)動就被移除了這類問題也很典型。最常見的原因是probe返回了錯誤碼。例如我讓你看內(nèi)核在probe失敗時打印的那行信息myled: probe of myled failed with error -16這個-16對應(yīng)- EBUSY。它可能來自platform_get_resource返回NULL后你直接return -EINVAL也可能來自gpiod_get返回錯誤。需要注意的是probe一旦返回非零內(nèi)核的driver core會認為驅(qū)動綁定失敗之后會自動執(zhí)行清理操作驅(qū)動和設(shè)備會被解除關(guān)聯(lián)看起來就像模塊被卸載了一樣。所以當(dāng)dmesg里能看到probe被調(diào)用但隨后設(shè)備driver鏈接消失不要盯著Platform匹配機制看問題基本都在probe內(nèi)部邏輯里。要做的就是把probe里每一步可能的錯誤碼都打印出來確定是哪一步返回的再去排查對應(yīng)子系統(tǒng)的問題。很多人不知道一個小細節(jié)如果probe在某個子系統(tǒng)返回EPROBE_DEFER延遲探測內(nèi)核不會立刻判定失敗而是把設(shè)備掛到一個等待隊列等對應(yīng)依賴的驅(qū)動加載完成后再重新觸發(fā)probe。這在多驅(qū)動依賴場景里非常重要。在i.MX6ULL的驅(qū)動開發(fā)中如果設(shè)備樹里引用的某個時鐘或中斷控制器對應(yīng)的驅(qū)動還沒就緒你的驅(qū)動probe可能會被反復(fù)推遲執(zhí)行。dmesg里看到“deferred probe”相關(guān)的字眼別慌這是內(nèi)核的合理等待機制你需要回頭檢查自己依賴的外設(shè)驅(qū)動有沒有加載成功。4.5 使用內(nèi)核deferred probe機制多說一句EPROBE_DEFER因為我發(fā)現(xiàn)很多新手第一次遇到它都會誤判成匹配失敗。在你的probe函數(shù)中當(dāng)你請求某個資源但該資源對應(yīng)的設(shè)備驅(qū)動還沒準(zhǔn)備好時比如調(diào)用clk_get、regulator_get、gpiod_get時返回了-EPROBE_DEFER你應(yīng)該直接把這個錯誤碼原樣返回給內(nèi)核。內(nèi)核的driver core看到返回-EPROBE_DEFER會把你的設(shè)備放到一個延遲列表中后續(xù)每當(dāng)有新的driver注冊都會重新嘗試對這些設(shè)備進行綁定和probe。這個機制保證了設(shè)備之間的依賴關(guān)系可以通過“你等我一會”的方式動態(tài)解決而不是簡單在probe里死循環(huán)等待資源就緒。實際調(diào)試時你可以在內(nèi)核cmdline中添加deferred_probe_timeout2這樣系統(tǒng)啟動后如果還存在EPROBE_DEFER的設(shè)備會在超時后打印詳細信息提示你到底在等待哪個資源。這個功能在排查啟動早期驅(qū)動順序問題時幾乎是救命稻草。4.6 常見問題速查表我把上面所有問題整理成一張速查表方便你日后直接對照排查?，F(xiàn)象常見原因排查與解決方向probe完全沒有執(zhí)行compatible不匹配對比uevent的MODALIAS與of_match_tableprobe完全沒有執(zhí)行設(shè)備節(jié)點不存在或statusdisabled檢查/proc/device-tree下節(jié)點與statusprobe沒有執(zhí)行但設(shè)備目錄存在設(shè)備驅(qū)動匹配沒觸發(fā)確認驅(qū)動有沒有注冊成功查看/sys/bus/platform/driversprobe執(zhí)行后打印錯誤GPIO或寄存器資源沖突查看dmesg錯誤碼檢查pinctrl和reg地址范圍insmod后/dev節(jié)點不出現(xiàn)udev/mdev規(guī)則未配置手動mknod或配置mdev自動創(chuàng)建規(guī)則probe反復(fù)不執(zhí)行出現(xiàn)deferred probe依賴資源尚未就緒查詢相關(guān)驅(qū)動是否加載成功必要時deferred_probe_timeout模塊無法modprobe自動加載MODULE_DEVICE_TABLE缺失或alias生成異常檢查模塊的modinfo輸出與MODALIAS匹配情況這張表你保存下來遇到問題時先對號入座。別小看這些檢查項很多資深工程師排查這類問題也基本走的是這套流程只不過他們已經(jīng)把每一步都內(nèi)化成了肌肉記憶。5. 升級認知從一套機制到整個設(shè)備模型思維5.1 Platform只是Linux設(shè)備模型里的一個縮影如果你只是想在i.MX6ULL上調(diào)通一個點燈驅(qū)動其實上面4節(jié)內(nèi)容已經(jīng)足夠。但如果你想把Linux驅(qū)動的知識體系搭得更完整我建議你從Platform這套機制中跳出來思考一下它背后統(tǒng)一的Linux內(nèi)核設(shè)備模型。Platform總線設(shè)備驅(qū)動模型本質(zhì)上只是Linux通用設(shè)備模型的一個應(yīng)用。Linux內(nèi)核維護了一個設(shè)備模型的骨架包括kobject、kset、uevent、sysfs等底層設(shè)施在這個骨架上衍生出不同類型的總線。不管是platform_bus_type、i2c_bus_type、spi_bus_type還是pci_bus_type它們都有共同的語義設(shè)備注冊、驅(qū)動注冊、總線匹配、probe調(diào)用、電源管理回調(diào)等。你在這篇文章里學(xué)到的compatible匹配、driver綁定、sysfs節(jié)點檢查這些技能在后續(xù)接觸I2C客戶端驅(qū)動、SPI設(shè)備驅(qū)動時同樣適用區(qū)別只是總線類型和匹配函數(shù)不一樣。I2C設(shè)備的client與driver通過id_table或者設(shè)備樹compatible匹配SPI設(shè)備也是類似邏輯。很多講Platform總線的教程喜歡鋪陳各種概念但我覺得內(nèi)核設(shè)備模型背后的核心設(shè)計思想才是真正值得玩味的東西把易變的、板級相關(guān)的設(shè)備描述從穩(wěn)定的驅(qū)動邏輯中剝離出來。設(shè)備樹解決了設(shè)備描述“寫在哪”的問題Platform總線解決了設(shè)備與驅(qū)動“怎么見面”的問題而GPIO、時鐘、中斷等內(nèi)核子系統(tǒng)則解決了資源“怎么共享不沖突”的問題。5.2 理解匹配機制對日常開發(fā)的實際影響哪怕你已經(jīng)能熟練地照著別人的驅(qū)動模板抄代碼我也建議你花時間把匹配機制吃透。因為不理解匹配機制你在調(diào)試時會缺少一個方向感只知道代碼寫出來沒反應(yīng)抓不住“系統(tǒng)如何認識我的設(shè)備”這條主線。舉個例子。設(shè)備樹里如果出現(xiàn)這個節(jié)點uart1 { status okay; };按我們前面說的流程內(nèi)核會把uart1節(jié)點轉(zhuǎn)換成platform_device去匹配IMX6ULL的uart驅(qū)動。如果你哪天發(fā)現(xiàn)一個串口設(shè)備死活打不開第一步就應(yīng)該去確認uart1節(jié)點是否成功創(chuàng)建了platform_device然后再看uart驅(qū)動有沒有綁定到這個設(shè)備、probe有沒有執(zhí)行。理解了這套機制之后你排查硬件驅(qū)動的順序就會變得很清晰從設(shè)備樹到平臺設(shè)備再到驅(qū)動綁定最后才是驅(qū)動內(nèi)部硬件初始化的邏輯。另一個常見場景是外設(shè)的時鐘和電源管理。Platform驅(qū)動在probe里拿到設(shè)備之后往往要操作clk和regulator子系統(tǒng)比如打開外設(shè)時鐘、調(diào)節(jié)電壓。這些資源同樣可以在設(shè)備樹節(jié)點中描述。如果資源描述不正確probe里clk_prepare_enable就會失敗。你只有理解了整個鏈條才能在設(shè)備樹、驅(qū)動代碼、內(nèi)核日志三個視角之間來回切換定位問題而不是逮著compatible死磕。5.3 如何繼續(xù)深入學(xué)習(xí)Platform相關(guān)技術(shù)如果你想在這個方向上有更扎實的積累我給幾條具體建議。第一條翻內(nèi)核源碼時別只看platform.c還要看device.h、platform_device.h、of_device.h這幾個頭文件把platform_device、platform_driver、of_device_id這幾個結(jié)構(gòu)體的字段都弄明白尤其是resource結(jié)構(gòu)體理解IORESOURCE_MEM、IORESOURCE_IRQ的用法。probe里那些platform_get_resource、platform_get_irq之類的API其實都是在操作resource結(jié)構(gòu)體明白了數(shù)據(jù)結(jié)構(gòu)你再去看接口函數(shù)不會覺得它們散亂。第二條自己獨立完成一次從設(shè)備樹建節(jié)點到用戶空間應(yīng)用程序調(diào)用完整鏈路的實驗。別只抄教程看完文章后關(guān)掉網(wǎng)頁自己憑理解寫一版踩過的坑記得越牢成長越快。實驗時可以刻意制造幾個錯誤比如把compatible故意寫錯、把status設(shè)為disabled觀察probe失敗的具體表現(xiàn)然后再修正回來。這種做法比重復(fù)抄代碼有用得多。第三條條件允許的話用QEMU或者虛擬平臺去讀內(nèi)核源碼里更多總線模型的實現(xiàn)。i.MX6ULL開發(fā)板適合做真實的硬件對接但如果你想在更深層面理解Linux設(shè)備模型比如分析bus_type結(jié)構(gòu)體的match、uevent、probe回調(diào)在driver core里如何被調(diào)度一臺能編譯內(nèi)核的Linux主機配合QEMU的virt平臺調(diào)試效率可能比反復(fù)燒錄板子更高。6. 最后再分享幾個調(diào)試小技巧調(diào)試Platform驅(qū)動時有幾條經(jīng)驗我覺得很有用分享給你們。第一dmesg一定要養(yǎng)成隨手清空的習(xí)慣。開發(fā)板長期運行內(nèi)核日志緩沖區(qū)會被各種無關(guān)消息占滿容易把關(guān)鍵日志沖掉。每次insmod之前先dmesg -c把舊日志清掉加載之后再看dmesg輸出這樣probe里打印的信息一目了然不會遺漏。第二多利用sysfs少依賴暴力加打印。sysfs是內(nèi)核設(shè)備模型的實時投影/sys/bus/platform/devices目錄下的每個符號鏈接和uevent文件都是判斷設(shè)備狀態(tài)的最可靠依據(jù)。很多問題看一眼驅(qū)動鏈接、cat一下uevent就能定位完全不需要重新編譯模塊加打印。雖然加打印在調(diào)試probe內(nèi)部邏輯時仍然必要但先通過sysfs確認匹配狀態(tài)能幫你少走很多彎路。第三改設(shè)備樹之后一定要確認板子加載的是你編譯的新dtb。嵌入式開發(fā)中啟動流程各有差異有的從SD卡讀dtb有的從EMMC指定分區(qū)讀有的通過u-boot環(huán)境變量指定tftp加載。改完設(shè)備樹卻忘記更新對應(yīng)位置的dtb是我見過最頻繁的低級錯誤。調(diào)試設(shè)備樹相關(guān)問題時先在板子上執(zhí)行l(wèi)s /proc/device-tree/看看節(jié)點是否真實存在再往下排查能省掉大量無意義的工作。第四合理使用devm系列的資源管理API。我在示例驅(qū)動里大量使用了devm_kzalloc、devm_gpiod_get這些devm前綴的函數(shù)本質(zhì)上是把資源釋放的責(zé)任掛在struct device的生命周期上。probe成功之后設(shè)備與驅(qū)動解除綁定時內(nèi)核會自動幫你釋放這些資源。這能有效避免probe失敗時忘記釋放之前申請的資源導(dǎo)致的問題。不夸張地說內(nèi)核里devm系列API的出現(xiàn)讓驅(qū)動資源管理的出錯率降低了一個量級。第五也是我覺得最重要的一點不要急著一次寫完整個驅(qū)動。你可以先把probe函數(shù)只留一條打印確認匹配鏈路通順再一步步加上GPIO申請、寄存器映射、設(shè)備注冊等邏輯。每一次小步驗證都能讓問題邊界變得非常清晰。真按這種方式做大多數(shù)Platform匹配類問題在半個小時內(nèi)就能定位遠比你一股腦寫完兩百行驅(qū)動再調(diào)半天高效得多。我在實際項目里用這套方法解決過的問題不計其數(shù)甚至有時候不是i.MX6ULL平臺換成其它ARM SoC或者RISC-V芯片只要內(nèi)核還是Linux這套Platform設(shè)備與驅(qū)動匹配機制基本不會變調(diào)試思路也是相通的。這就是花時間把機制理解透的價值。