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