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