前幾天幫同事調(diào)i.MX6ULL的驅(qū)動(dòng)現(xiàn)象非常典型模塊加載了日志里卻沒(méi)有probe函數(shù)的打印。設(shè)備樹里compatible屬性的值和驅(qū)動(dòng)of_match_table里的字符串肉眼看上去一模一樣就是匹配不上。最后我在/sys/bus/platform目錄下翻了半天才發(fā)現(xiàn)設(shè)備樹節(jié)點(diǎn)compatible值的末尾多了一個(gè)不可見的空格。這類問(wèn)題根子都在對(duì)Platform設(shè)備與驅(qū)動(dòng)匹配機(jī)制的理解還停留在“大概知道”的層面。本文就以i.MX6ULL平臺(tái)為例把platform總線的匹配機(jī)制、代碼路徑、實(shí)操套路和排錯(cuò)思路完整串一遍。如果你正準(zhǔn)備入門i.MX6ULL或者其他Cortex-A系列芯片的Linux驅(qū)動(dòng)開發(fā)或者寫過(guò)platform驅(qū)動(dòng)但老是栽在匹配環(huán)節(jié)這篇應(yīng)該能幫你省不少時(shí)間。1. 為什么i.MX6ULL上的外設(shè)多半繞不開platform機(jī)制1.1 從硬件控制器的角度理解platform設(shè)備的來(lái)源i.MX6ULL是一顆Cortex-A7內(nèi)核的處理器但芯片內(nèi)部集成了大量外設(shè)控制器比如UART、I2C、SPI(ECSPI)、SDIO、GPIO、PWM、ADC、LCDIF、ENET等。這些控制器從軟件角度看本質(zhì)就是一段寄存器地址區(qū)域加上若干中斷號(hào)但在Linux設(shè)備模型里它們需要被抽象成設(shè)備節(jié)點(diǎn)掛到某一類總線上。問(wèn)題在于這些控制器不是PCI設(shè)備也無(wú)法枚舉它們的位置和資源在硬件設(shè)計(jì)時(shí)就固定了。Linux內(nèi)核為這類“掛不到真實(shí)總線上的片上外設(shè)”設(shè)計(jì)了一條虛擬總線就是platform總線。i.MX6ULL上幾乎每一個(gè)內(nèi)部外設(shè)控制器在內(nèi)核啟動(dòng)后都會(huì)注冊(cè)成一個(gè)platform_device。設(shè)計(jì)上通常分兩步第一步是描述硬件傳統(tǒng)方式是在arch/arm/mach-imx/目錄下的板級(jí)文件里手動(dòng)填充platform_device結(jié)構(gòu)體并調(diào)用platform_device_register這種方式在內(nèi)核3.x時(shí)代很常見第二步是現(xiàn)在主流的設(shè)備樹方式內(nèi)核在啟動(dòng)過(guò)程中通過(guò)of_platform_default_populate等函數(shù)解析設(shè)備樹把節(jié)點(diǎn)自動(dòng)轉(zhuǎn)換成platform_device。設(shè)備樹之所以能成為主流核心原因是解決了硬件描述與驅(qū)動(dòng)代碼耦合的問(wèn)題更換板卡硬件時(shí)不用重新編譯內(nèi)核只改設(shè)備樹文件。在i.MX6ULL的官方BSP里默認(rèn)就是設(shè)備樹方式。你在設(shè)備樹里寫一個(gè)節(jié)點(diǎn)內(nèi)核啟動(dòng)后就可以在/sys/bus/platform/devices/目錄下看到對(duì)應(yīng)的設(shè)備目錄。1.2 platform設(shè)備與platform驅(qū)動(dòng)的注冊(cè)時(shí)機(jī)剛學(xué)驅(qū)動(dòng)的人很容易有一個(gè)困惑驅(qū)動(dòng)和設(shè)備到底誰(shuí)先注冊(cè)probe函數(shù)什么時(shí)候調(diào)用這里的關(guān)鍵是理解Linux設(shè)備模型的事件驅(qū)動(dòng)機(jī)制。當(dāng)驅(qū)動(dòng)注冊(cè)時(shí)總線會(huì)遍歷所有已經(jīng)注冊(cè)的設(shè)備逐個(gè)調(diào)用匹配函數(shù)尋找合適的設(shè)備找到就立刻調(diào)用驅(qū)動(dòng)的probe反過(guò)來(lái)當(dāng)設(shè)備注冊(cè)時(shí)總線也會(huì)遍歷所有已經(jīng)注冊(cè)的驅(qū)動(dòng)找到匹配項(xiàng)就觸發(fā)probe。所以注冊(cè)順序本身不影響最終是否能匹配上只影響probe觸發(fā)的早晚。如果兩個(gè)都注冊(cè)完成后還沒(méi)匹配上那就是匹配條件本身出了問(wèn)題這也是調(diào)試時(shí)的基本判斷方向。在i.MX6ULL的啟動(dòng)流程里設(shè)備樹解析生成platform_device的動(dòng)作發(fā)生得比較早通常在kernel_init之前。而驅(qū)動(dòng)模塊如果選擇編譯為模塊(.ko)則是在系統(tǒng)啟動(dòng)后由modprobe或insmod加載。操作系統(tǒng)會(huì)先存在設(shè)備再補(bǔ)充驅(qū)動(dòng)如果驅(qū)動(dòng)編譯進(jìn)內(nèi)核(zImage)則設(shè)備和驅(qū)動(dòng)的注冊(cè)順序就不一定了但各自注冊(cè)時(shí)都會(huì)去掃描對(duì)方所以probe依然會(huì)正常觸發(fā)。1.3 platform總線在sysfs中的組織結(jié)構(gòu)/sys/bus/platform/目錄下有兩個(gè)關(guān)鍵子目錄devices/和drivers/。devices目錄下面是所有platform設(shè)備的軟鏈接drivers目錄下面是所有platform驅(qū)動(dòng)的軟鏈接。當(dāng)驅(qū)動(dòng)和設(shè)備匹配成功后設(shè)備目錄下會(huì)多出一個(gè)driver鏈接指向?qū)?yīng)的驅(qū)動(dòng)目錄同時(shí)驅(qū)動(dòng)目錄下也會(huì)出現(xiàn)設(shè)備的鏈接。這個(gè)雙向鏈接是判斷綁定關(guān)系最直觀的依據(jù)。我在調(diào)試時(shí)幾乎離不開這個(gè)目錄。設(shè)備有沒(méi)有注冊(cè)、驅(qū)動(dòng)有沒(méi)有加載、綁定關(guān)系是否建立ls一下馬上就知道。這篇文章后續(xù)的排錯(cuò)環(huán)節(jié)很多操作也是圍繞這個(gè)目錄展開的。2. platform_match的執(zhí)行順序驅(qū)動(dòng)和設(shè)備到底怎么“對(duì)上眼”2.1 內(nèi)核源碼里platform_match的完整邏輯platform_driver和platform_device的匹配入口是platform_match函數(shù)定義在drivers/base/platform.c中。以Linux 5.x/6.x內(nèi)核為例核心邏輯如下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); /* When driver_override is set, only bind to the matching driver */ if (pdev-driver_override) return !strcmp(pdev-driver_override, drv-name); /* Attempt an OF style match first */ if (of_driver_match_device(dev, drv)) return 1; /* Then try ACPI style match */ if (acpi_driver_match_device(dev, drv)) return 1; /* Then try to match against the id table */ if (pdrv-id_table) return platform_match_id(pdev, pdrv-id_table) ! NULL; /* fall-back to driver name match */ return (strcmp(pdev-name, drv-name) 0); }這五步的優(yōu)先級(jí)是硬編碼的從上到下依次執(zhí)行命中即返回。理解這個(gè)順序?qū)φ{(diào)試很多匹配問(wèn)題非常有幫助。2.2 五種匹配方式的適用場(chǎng)景先看driver_override這是留給調(diào)試和特殊場(chǎng)景用的“后門”。如果設(shè)備節(jié)點(diǎn)的driver_override屬性被設(shè)置那么只和這個(gè)字段指定的驅(qū)動(dòng)名進(jìn)行字符串比較其他匹配方式全部跳過(guò)。我一般用它來(lái)強(qiáng)制綁定某個(gè)驅(qū)動(dòng)或者在設(shè)備樹不便于修改的板子上暫時(shí)切換驅(qū)動(dòng)后面排錯(cuò)章節(jié)會(huì)詳細(xì)演示。接著是of_driver_match_device這是i.MX6ULL設(shè)備樹平臺(tái)最常用的匹配路徑。它做的事可以理解為取出device_node的compatible屬性和驅(qū)動(dòng)的of_device_id數(shù)組中每個(gè)成員的compatible字段逐一比較只要有任何一個(gè)字符串相等就返回匹配。注意compatible比較要求完全相等包括廠商前綴和大小寫一個(gè)字符不對(duì)都不行。然后是acpi_driver_match_devicex86平臺(tái)和部分ARM服務(wù)器平臺(tái)會(huì)走ACPI路徑i.MX6ULL這種典型嵌入式平臺(tái)幾乎不用但代碼邏輯存在不影響什么。再然后是platform_match_id這是給沒(méi)有設(shè)備樹的老式驅(qū)動(dòng)用的。驅(qū)動(dòng)可以定義一個(gè)platform_device_id數(shù)組static const struct platform_device_id mybeep_id_table[] { { mybeep, 0 }, { } };platform_match_id會(huì)拿設(shè)備的name字段和id_table里的name做比較。那什么時(shí)候會(huì)走上這條路呢最常見的就是沒(méi)有設(shè)備樹、設(shè)備通過(guò)platform_device_register注冊(cè)的場(chǎng)景設(shè)備名字就是在platform_device結(jié)構(gòu)體里指定的那個(gè)字符串。最后一步是退化匹配直接把pdev-name和drv-driver.name做字符串比較。這種寫法在很老的驅(qū)動(dòng)里能看到比如static struct platform_driver mybeep_driver { .driver { .name mybeep, }, .probe mybeep_probe, .remove mybeep_remove, };如果設(shè)備樹里的節(jié)點(diǎn)沒(méi)有compatible屬性且設(shè)備節(jié)點(diǎn)名為mybeep驅(qū)動(dòng)名也叫mybeep走這一步就能匹配上。但這屬于“祖?zhèn)鲗懛ā痹谛麓a里不推薦依賴它。一方面它太隱晦可讀性差另一方面設(shè)備樹節(jié)點(diǎn)的name字段通常包含總線前綴或單元地址和驅(qū)動(dòng)名不一定對(duì)得上。規(guī)范做法是使用of_match_table或id_table。2.3 設(shè)備樹compatible與of_match_table的對(duì)應(yīng)邏輯static const struct of_device_id mybeep_of_match[] { { .compatible myvendor,mybeep, }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, mybeep_of_match);關(guān)于MODULE_DEVICE_TABLE很多人以為它只是給用戶態(tài)工具看的其實(shí)它還有一層重要含義它會(huì)在編譯時(shí)生成模塊別名把of_device_id里的compatible字符串編碼進(jìn).modinfo段。這樣modprobe在加載模塊時(shí)可以通過(guò)內(nèi)核發(fā)送的uevent事件自動(dòng)匹配設(shè)備。驅(qū)動(dòng)編譯為模塊后用modinfo檢查能看到類似aliasof:NTCmyvendor,mybeep的信息有這個(gè)信息才說(shuō)明模塊別名生成正確。我在寫platform驅(qū)動(dòng)時(shí)的習(xí)慣是只要面對(duì)的是設(shè)備樹平臺(tái)of_match_table一定寫id_table可以不寫name退化匹配基本不考慮。這是最清晰、最不容易出錯(cuò)的路徑。3. 在i.MX6ULL上實(shí)操?gòu)脑O(shè)備樹到probe觸發(fā)的完整過(guò)程3.1 一個(gè)最簡(jiǎn)單的beep硬件設(shè)備與設(shè)備樹描述以一塊i.MX6ULL開發(fā)板上的蜂鳴器為例。蜂鳴器的控制引腳通常接到某個(gè)GPIO上比如GPIO5_IO01具體引腳以你板子原理圖為準(zhǔn)。硬件上無(wú)非是給GPIO輸出高電平就響輸出低電平就停。設(shè)備樹里我習(xí)慣這樣描述/ { mybeep { compatible myvendor,mybeep; pinctrl-names default; pinctrl-0 pinctrl_mybeep; mybeep-gpios gpio5 1 GPIO_ACTIVE_HIGH; status okay; }; };引腳復(fù)用配置放在iomuxc節(jié)點(diǎn)下iomuxc { pinctrl_mybeep: mybeepgrp { fsl,pins MX6ULL_PAD_SNVS_TAMPER1__GPIO5_IO01 0x17059 ; }; };MX6ULL_PAD_SNVS_TAMPER1__GPIO5_IO01這個(gè)宏由SDK提供位于imx6ull-pinfunc.h頭文件具體引腳對(duì)應(yīng)的宏名以你的BSP為準(zhǔn)。0x17059是引腳配置值包含了上下拉、驅(qū)動(dòng)能力、速度等設(shè)置。這里不展開講怎么算直接用SDK推薦的配置值就可以。3.2 platform驅(qū)動(dòng)代碼骨架與加載后的sysfs變化驅(qū)動(dòng)的代碼結(jié)構(gòu)如下#include linux/module.h #include linux/platform_device.h #include linux/of.h #include linux/gpio/consumer.h static int mybeep_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct gpio_desc *desc; desc devm_gpiod_get(dev, mybeep, GPIOD_OUT_LOW); if (IS_ERR(desc)) { dev_err(dev, failed to get mybeep gpio: %ld\n, PTR_ERR(desc)); return PTR_ERR(desc); } dev_info(dev, mybeep probe ok, beep on\n); gpiod_set_value(desc, 1); return 0; } static void mybeep_remove(struct platform_device *pdev) { struct device *dev pdev-dev; dev_info(dev, mybeep removed\n); } static const struct of_device_id mybeep_of_match[] { { .compatible myvendor,mybeep, }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, mybeep_of_match); static struct platform_driver mybeep_driver { .probe mybeep_probe, .remove mybeep_remove, .driver { .name mybeep, .of_match_table mybeep_of_match, }, }; module_platform_driver(mybeep_driver); MODULE_LICENSE(GPL); MODULE_DESCRIPTION(i.MX6ULL beep platform driver);注意編譯鏡像時(shí)設(shè)備樹源文件(dts)要加入編譯列表如果手動(dòng)用fdtdump或dtc工具查看dtb確認(rèn)節(jié)點(diǎn)確實(shí)存在再加載驅(qū)動(dòng)模塊。模塊加載命令insmod mybeep.ko加載后先看dmesgdmesg | tail -20正常情況下會(huì)看到“mybeep probe ok”。再檢查sysfsls -l /sys/bus/platform/devices/mybeep/driver lrwxrwxrwx 1 root root 0 Jan 1 00:00 /sys/bus/platform/devices/mybeep/driver - ../../../bus/platform/drivers/mybeep這個(gè)尾部箭頭指向mybeep驅(qū)動(dòng)說(shuō)明設(shè)備與驅(qū)動(dòng)已經(jīng)綁定probe成功執(zhí)行。3.3 驅(qū)動(dòng)、設(shè)備和probe的對(duì)應(yīng)關(guān)系我見過(guò)不少初學(xué)者在probe里寫了一堆初始化但完全沒(méi)搞懂probe為什么能拿到pdev參數(shù)。platform_driver的probe回調(diào)簽名為int (*probe)(struct platform_device *)這個(gè)參數(shù)就是匹配上的那個(gè)platform_device。probe里通過(guò)pdev-dev拿到struct device指針之后就可以用devm系列API、device_property系列API訪問(wèn)設(shè)備樹屬性、GPIO、中斷等資源。probe的本質(zhì)是“驅(qū)動(dòng)被允許操作設(shè)備”的入口不是驅(qū)動(dòng)模塊加載入口。驅(qū)動(dòng)的模塊加載入口其實(shí)是由module_platform_driver宏展開時(shí)的module_init函數(shù)完成的它負(fù)責(zé)調(diào)用platform_driver_register最終在總線匹配成功后觸發(fā)probe。理解這個(gè)層次排查問(wèn)題思路就會(huì)清晰很多。4. probe沒(méi)調(diào)用怎么排查我在i.MX6ULL上的完整debug鏈路4.1 一次典型的匹配失敗復(fù)現(xiàn)假設(shè)驅(qū)動(dòng)加載后dmesg沒(méi)有probe日志先從最基礎(chǔ)的確認(rèn)開始。第一步確認(rèn)設(shè)備樹節(jié)點(diǎn)是否被內(nèi)核解析ls /proc/device-tree/mybeep/ cat /proc/device-tree/mybeep/compatible/proc/device-tree是設(shè)備樹在內(nèi)存中的展開形式節(jié)點(diǎn)存在就說(shuō)明設(shè)備樹里確實(shí)有這個(gè)節(jié)點(diǎn)而且dtb已經(jīng)正確加載。cat compatible時(shí)建議用xxd或od查看十六進(jìn)制因?yàn)閏ompatible值在設(shè)備樹里是字符串?dāng)?shù)組用cat可能看不到結(jié)尾空格或不可見字符。我當(dāng)初遇到的那個(gè)多一個(gè)空格的坑就是靠xxd查出來(lái)的xxd /proc/device-tree/mybeep/compatible 00000000: 6d79 7665 6e64 6f72 2c6d 7962 6565 700a myvendor,mybeep.看到末尾的0x0a了嗎當(dāng)時(shí)我們?cè)O(shè)備樹里字符串后面多了一個(gè)換行符。compatible的字符串比較是逐字節(jié)進(jìn)行的一個(gè)多余字符就會(huì)導(dǎo)致匹配失敗。如果cat顯示正常、情況又非常詭異一定要用xxd確認(rèn)原始字節(jié)。4.2 確認(rèn)platform_device與platform_driver兩端的注冊(cè)情況設(shè)備樹節(jié)點(diǎn)解析成功后內(nèi)核還未必生成了platform_device。用下面的命令看設(shè)備端ls /sys/bus/platform/devices/如果mybeep目錄不存在說(shuō)明設(shè)備沒(méi)有注冊(cè)成功問(wèn)題出在設(shè)備樹解析階段常見原因包括節(jié)點(diǎn)語(yǔ)法錯(cuò)誤、status屬性為disabled、父節(jié)點(diǎn)狀態(tài)不對(duì)。如果目錄存在再查看驅(qū)動(dòng)注冊(cè)情況ls /sys/bus/platform/drivers/mybeep/如果這個(gè)目錄不存在說(shuō)明驅(qū)動(dòng)模塊沒(méi)有注冊(cè)成功常見原因包括platform_driver結(jié)構(gòu)體初始化錯(cuò)誤、module_platform_driver宏使用不當(dāng)、模塊加載失敗?？梢韵扔胢odprobe或insmod看返回信息再用dmesg查模塊加載階段是否有報(bào)錯(cuò)。如果兩邊都存在卻沒(méi)有綁定鏈接就要看驅(qū)動(dòng)目錄下的uevent或者設(shè)備的ueventcat /sys/bus/platform/drivers/mybeep/uevent cat /sys/bus/platform/devices/mybeep/ueventuevent文件會(huì)顯示模塊名和MODALIAS信息。如果驅(qū)動(dòng)的MODALIAS里有of:N...T...Cmyvendor,mybeep設(shè)備的MODALIAS也是Cmyvendor,mybeep那匹配理論上應(yīng)該成立。這里經(jīng)常出現(xiàn)的問(wèn)題是大小寫不一致、compatible缺少?gòu)S商前綴、或者of_match_table結(jié)尾忘了寫sentinel空條目。4.3 對(duì)比compatible字符串、檢查of_match_table的常見錯(cuò)誤of_match_table的檢查重點(diǎn)有三個(gè)。第一of_device_id數(shù)組必須以空結(jié)構(gòu)體結(jié)束也就是sentinel否則內(nèi)核遍歷數(shù)組時(shí)會(huì)越界或漏匹配。第二compatible字符串必須完整按慣例包含“廠商名,設(shè)備名”兩部分比如“myvendor,mybeep”不少人在設(shè)備樹里少寫了廠商前綴驅(qū)動(dòng)里寫了兩個(gè)字符串當(dāng)然不相等。第三驅(qū)動(dòng)結(jié)構(gòu)體中of_match_table字段是否真的賦值給了.driver的成員而不是賦給了platform_driver的頂層字段。有時(shí)候代碼寫成了static struct platform_driver mybeep_driver { .of_match_table mybeep_of_match, ... };這是錯(cuò)的of_match_table必須放在.driver子結(jié)構(gòu)體里。這個(gè)問(wèn)題編譯不會(huì)報(bào)錯(cuò)但驅(qū)動(dòng)加載后平臺(tái)總線完全不知道匹配表的存在只能退回去走name匹配自然匹配不上。4.4 用driver_override強(qiáng)制綁定與手動(dòng)bind/unbind驗(yàn)證為了快速驗(yàn)證“到底是不是匹配邏輯的問(wèn)題”可以手動(dòng)觸發(fā)綁定。設(shè)備已經(jīng)有了驅(qū)動(dòng)也注冊(cè)了直接寫sysfs# 先解除可能的舊綁定 echo mybeep /sys/bus/platform/drivers/mybeep/unbind 2/dev/null # 強(qiáng)制指定驅(qū)動(dòng) echo my_beep /sys/bus/platform/devices/mybeep/driver_override echo mybeep /sys/bus/platform/drivers/my_beep/bind注意driver_override里寫的是驅(qū)動(dòng)名即.driver.name的值bind里寫的是設(shè)備名。如果這樣手動(dòng)綁定時(shí)probe能執(zhí)行說(shuō)明驅(qū)動(dòng)本身沒(méi)問(wèn)題問(wèn)題一定出在自動(dòng)匹配機(jī)制的某個(gè)環(huán)節(jié)。如果手動(dòng)綁定也失敗驅(qū)動(dòng)代碼本身要回爐檢查重點(diǎn)看probe里有沒(méi)有返回錯(cuò)誤碼。還要強(qiáng)調(diào)一種容易誤導(dǎo)的現(xiàn)象probe函數(shù)被調(diào)用了但設(shè)備狀態(tài)仍然顯示not bound。這時(shí)要區(qū)分probe根本沒(méi)執(zhí)行和probe執(zhí)行后返回錯(cuò)誤。第一種對(duì)應(yīng)匹配失敗第二種對(duì)應(yīng)初始化失敗。初始化失敗時(shí)dmesg里通常有probe函數(shù)的dev_err輸出sysfs下設(shè)備的driver鏈接也會(huì)消失。這種情況需要用driver_override加上echo bind的方式復(fù)現(xiàn)觀察內(nèi)核打印的具體strace或錯(cuò)誤碼。4.5 一張表總結(jié)probe沒(méi)調(diào)用的常見原因現(xiàn)象可能原因驗(yàn)證方法/proc/device-tree下無(wú)節(jié)點(diǎn)設(shè)備樹未編譯/節(jié)點(diǎn)被裁剪/status為disabled檢查dts編譯列表、dtb內(nèi)容、status屬性/sys/bus/platform/devices下無(wú)設(shè)備節(jié)點(diǎn)存在但未生成platform_device檢查節(jié)點(diǎn)語(yǔ)法、父節(jié)點(diǎn)狀態(tài)、of_platform_create/sys/bus/platform/drivers下無(wú)驅(qū)動(dòng)驅(qū)動(dòng)模塊加載失敗/驅(qū)動(dòng)未注冊(cè)dmesg查看模塊加載日志兩邊都存在但無(wú)driver鏈接compatible不匹配/of_match_table錯(cuò)誤xxd對(duì)比compatible字符串檢查of_match_table的sentinel和字段位置probe執(zhí)行但設(shè)備報(bào)錯(cuò)驅(qū)動(dòng)初始化失敗或資源獲取失敗查看dmesg中probe內(nèi)錯(cuò)誤日志檢查GPIO等資源是否沖突5. 容易被忽略的細(xì)節(jié)module_platform_driver宏、remove回調(diào)與資源管理習(xí)慣5.1 module_platform_driver宏到底展開了什么module_platform_driver是一個(gè)宏不是函數(shù)。它把驅(qū)動(dòng)的注冊(cè)和注銷包裝成標(biāo)準(zhǔn)的模塊入口函數(shù)static int __init mybeep_driver_init(void) { return platform_driver_register(mybeep_driver); } module_init(mybeep_driver_init); static void __exit mybeep_driver_exit(void) { platform_driver_unregister(mybeep_driver); } module_exit(mybeep_driver_exit);使用這個(gè)宏的好處是省去手寫入口函數(shù)避免注冊(cè)和注銷邏輯不對(duì)稱。但這也帶來(lái)一個(gè)理解上的盲區(qū)很多新人以為probe函數(shù)是模塊加載入口實(shí)際上模塊加載入口是宏展開出來(lái)的mybeep_driver_init它做了teamplate注冊(cè)工作后立即返回。platform_driver_register內(nèi)部會(huì)同步掃描總線上的設(shè)備如果找到匹配項(xiàng)調(diào)用匹配邏輯后再調(diào)用probe。手動(dòng)載入驅(qū)動(dòng)有時(shí)會(huì)遇到probe在注冊(cè)期間就同步執(zhí)行的情況。如果probe里做了耗時(shí)操作modprobe命令就會(huì)卡住一會(huì)兒這不是系統(tǒng)異常而是probe同步調(diào)用的表現(xiàn)。知道了這一點(diǎn)就不會(huì)誤以為系統(tǒng)死機(jī)了。5.2 remove回調(diào)簽名變化與不同內(nèi)核版本的兼容處理i.MX6ULL的老BSP比如NXP官方4.1.15和5.4內(nèi)核platform_driver的remove回調(diào)簽名是static int mybeep_remove(struct platform_device *pdev)但在Linux 6.1之后內(nèi)核社區(qū)把remove的返回值改成了void引入了一個(gè)過(guò)渡階段新代碼用remove_new成員保存void返回類型的回調(diào)。比如static void mybeep_remove(struct platform_device *pdev) { ... } static struct platform_driver mybeep_driver { .probe mybeep_probe, .remove_new mybeep_remove, ... };如果你在6.1以上內(nèi)核里直接寫.remove mybeep_remove(舊式int返回版本)編譯會(huì)收到warning甚至報(bào)錯(cuò)。如果你的驅(qū)動(dòng)需要同時(shí)兼容老內(nèi)核和新內(nèi)核可以使用內(nèi)核提供的宏或者條件編譯處理。這不是i.MX6ULL專有問(wèn)題但很多用老SDK的工程師升級(jí)內(nèi)核時(shí)都會(huì)撞上。5.3 資源管理為什么推薦devm_platform_ioremap_resource與devm_gpiod_get在probe里獲取硬件資源時(shí)我強(qiáng)烈建議使用devm系列API這類API把資源的申請(qǐng)和釋放綁定到了struct device的生命周期。驅(qū)動(dòng)卸載時(shí)probe里用devm_獲取的資源會(huì)自動(dòng)釋放不需要在remove里逐個(gè)手動(dòng)釋放。少了release步驟不僅代碼簡(jiǎn)潔還減少了內(nèi)存泄漏和資源泄漏的風(fēng)險(xiǎn)。對(duì)于寄存器地址映射老式寫法是res platform_get_resource(pdev, IORESOURCE_MEM, 0); regs devm_ioremap_resource(pdev-dev, res);或者直接一步到位regs devm_platform_ioremap_resource(pdev, 0);devm_platform_ioremap_resource內(nèi)部會(huì)做platform_get_resource、devm_request_mem_region、devm_ioremap三件事返回映射后的虛擬地址。如果資源不存在或已被占用返回ERR_PTR錯(cuò)誤。GPIO的獲取同理用devm_gpiod_get系列。設(shè)備樹屬性名mybeep-gpios會(huì)被轉(zhuǎn)換成con_id“mybeep”這正好對(duì)應(yīng)我們?cè)O(shè)備樹里的寫法。devm_gpiod_get返回struct gpio_desc指針后續(xù)可以使用gpiod_set_value、gpiod_get_value等操作函數(shù)。5.4 關(guān)于“什么情況下才應(yīng)該寫platform驅(qū)動(dòng)”的思考最后聊一個(gè)偏設(shè)計(jì)的話題。這個(gè)細(xì)節(jié)是我?guī)氯藭r(shí)總被問(wèn)到的是不是驅(qū)動(dòng)都必須寫成platform驅(qū)動(dòng)并沒(méi)有這個(gè)要求。platform驅(qū)動(dòng)適合描述“掛在CPU總線上的外設(shè)控制器”這類實(shí)體硬件。如果設(shè)備樹里能用一個(gè)物理節(jié)點(diǎn)描述它probe后需要訪問(wèn)寄存器或GPIO等硬件資源就適合platform驅(qū)動(dòng)。但如果只是一個(gè)純軟件邏輯比如一個(gè)內(nèi)核線程配合procfs提供調(diào)試接口沒(méi)有對(duì)應(yīng)的實(shí)體硬件那寫成platform驅(qū)動(dòng)更多是套了一套框架反而顯得繞。在i.MX6ULL上像beep這種簡(jiǎn)單GPIO輸出設(shè)備其實(shí)還可以考慮用內(nèi)核自帶的led-class框架或者pwm-leds驅(qū)動(dòng)不需要自己寫platform驅(qū)動(dòng)。自己寫platform驅(qū)動(dòng)更適合那些需要訪問(wèn)私有寄存器、處理特定中斷、做硬件狀態(tài)管理的設(shè)備。選型時(shí)先把內(nèi)核現(xiàn)成子系統(tǒng)找一遍能復(fù)用就復(fù)用這才是驅(qū)動(dòng)開發(fā)的省力之道。我在實(shí)際調(diào)試中養(yǎng)成了一個(gè)習(xí)慣遇到匹配問(wèn)題先看/sys/bus/platform下設(shè)備與驅(qū)動(dòng)兩端是否存在再對(duì)比/proc/device-tree里的compatible原始字節(jié)最后才去翻源碼。這套流程跑下來(lái)大部分platform驅(qū)動(dòng)匹配問(wèn)題都能定位到根因。希望這篇文章能幫你把i.MX6ULL上的platform機(jī)制這塊拼圖補(bǔ)完整。