做PCI設(shè)備驅(qū)動開發(fā)的人大概都有過這種體驗照著范例把struct pci_driver填滿在 probe 里寫上一堆初始化代碼編譯加載然后心提到嗓子眼——設(shè)備到底有沒有被正確掛上BAR 空間夠不夠中斷會不會來我上周調(diào)一塊 PCIe 采集卡時就撞上了pci out of resources這個經(jīng)典報錯排查過程讓我意識到與其零散地搜日志不如把 Linux PCI 驅(qū)動框架的運(yùn)轉(zhuǎn)邏輯完整梳理一遍。這是系列的第二篇上一篇講了 PCIe 拓?fù)浜兔杜e的基本概念這次聚焦驅(qū)動開發(fā)真正繞不開的部分設(shè)備匹配流程、資源映射手法、DMA 與中斷配置以及現(xiàn)場怎么排障。內(nèi)容不追求覆蓋每一個 API而是幫你在腦子里搭出一張設(shè)備從識別到跑數(shù)據(jù)的路線圖。1. 先弄清誰來找誰PCI 設(shè)備與驅(qū)動的匹配機(jī)制剛接觸 PCI 驅(qū)動的人最容易犯的一個錯是把字符設(shè)備驅(qū)動的思路直接搬過來注冊一個 file_operations然后等著用戶 open 設(shè)備文件。但 PCI 驅(qū)動的主動權(quán)根本不在驅(qū)動這邊。內(nèi)核的pci_bus_type會在總線枚舉和后續(xù)熱插拔事件中主動掃描設(shè)備拿著設(shè)備信息去比對所有已注冊的pci_driver找到匹配項之后才調(diào)用你的 probe?？梢哉f設(shè)備是崗位驅(qū)動是候選人內(nèi)核是 HR。1.1 一張 pci_device_id 表就是尋人啟事struct pci_device_id是驅(qū)動和設(shè)備之間的約定。內(nèi)核匹配時就是拿設(shè)備的 vendor、device、subvendor、subdevice、class 等字段逐條遍歷驅(qū)動提供的 id_table只要任何一條能對上就認(rèn)為這個驅(qū)動負(fù)責(zé)這個設(shè)備。struct pci_device_id { __u32 vendor, device; // 主ID必須匹配 __u32 subvendor, subdevice; // 子系統(tǒng)ID可設(shè) PCI_ANY_ID __u32 class, class_mask; // 類別匹配帶掩碼 kernel_ulong_t driver_data; // 透傳給 probe 的私有數(shù)據(jù) };vendor 和 device 是主干匹配項幾乎不會用PCI_ANY_ID去模糊匹配因為那等于對所有設(shè)備喊我是你爹會把別人的設(shè)備搶過來。subvendor 和 subdevice 描述的是具體板卡而不僅僅是芯片。同一顆芯片可能被多家廠商做成不同板卡如果你只寫 vendor/device 而不約束 subdevice驅(qū)動就會錯誤綁定到不是你目標(biāo)的板卡上。我自己就踩過這個坑。當(dāng)時有兩個子型號vendor/device 完全一樣只有 subdevice 不同。我偷懶只寫了PCI_DEVICE(0x1234, 0x5678)結(jié)果兩個型號都被 probe第二個型號的寄存器布局不一樣初始化直接崩。改成PCI_DEVICE_SUB(0x1234, 0x5678, 0x1234, 0x0002)之后才清凈。所以如果你的硬件有子系統(tǒng)標(biāo)識盡量用全約束。1.2 匹配成功之后driver_data 和 MODULE_DEVICE_TABLE 在忙什么driver_data是個kernel_ulong_t按內(nèi)核慣例用來存放指向私有配置結(jié)構(gòu)體的指針取整。probe 的第二個參數(shù)const struct pci_device_id *id會把這一項原樣傳給你這樣同一個驅(qū)動支持多個型號時你可以在 probe 入口直接根據(jù) id 拿到對應(yīng)配置不用到處寫 if/else。static const struct pci_device_id cap_ids[] { { PCI_DEVICE(0x1234, 0x5678), .driver_data (kernel_ulong_t)cap_a_config }, { PCI_DEVICE(0x1234, 0x5679), .driver_data (kernel_ulong_t)cap_b_config }, { } }; MODULE_DEVICE_TABLE(pci, cap_ids);MODULE_DEVICE_TABLE不是給人看的儀式它會在編譯時生成模塊的 alias 信息depmod后寫入modules.alias。系統(tǒng)里 udev 在發(fā)現(xiàn) PCI 設(shè)備時會讀取設(shè)備 sysfs 下的 modalias 文件內(nèi)容像一串編碼比如pci:v00001234d00005678sv...然后用它去 modules.alias 里反查該加載哪個 .ko。所以哪怕你在板子上手動insmod沒問題如果忘了寫MODULE_DEVICE_TABLE開箱時驅(qū)動基本不會被自動加載——這不是內(nèi)核 bug是你不小心砍掉了自動加載鏈路。1.3 class 匹配的適用場景除了精確 ID 匹配pci_device_id 還支持按設(shè)備類別匹配比如匹配某個網(wǎng)卡或者顯卡類別下的所有設(shè)備。class 字段本身是編碼形式class_mask用來屏蔽不需要比較的位。實操中 class 匹配用得少因為同一個類別下不同設(shè)備的寄存器差異巨大強(qiáng)行匹配進(jìn)去probe 里還得再靠 vendor/device 二次區(qū)分不如直接精確匹配干凈。真正的典型用途是某種通用類驅(qū)動比如某些 vendor 提供的通用 PCIe 驅(qū)動先按 class 兜底再在內(nèi)部分流派。新手不建議模仿。一句話總結(jié)匹配機(jī)制id_table 是門禁driver_data 是進(jìn)門后遞給你的工牌MODULE_DEVICE_TABLE 是讓門衛(wèi)知道今天有你這個候選人的通訊錄。三者配合probe 才會在一個設(shè)備真實存在的前提下被調(diào)用。2. probe 不是隨便寫寫驅(qū)動的出生、存活與退休probe是 PCI 驅(qū)動的核心主戰(zhàn)場但很多人把它當(dāng)成初始化硬件的地方這個理解太窄。probe 更準(zhǔn)確的定位是資源申請清單。設(shè)備枚舉是內(nèi)核做的驅(qū)動能做的只是把自己需要的資源申請下來做好映射然后讓設(shè)備可被系統(tǒng)其他子系統(tǒng)使用。2.1 probe 里該干的七件事和對應(yīng)釋放我按自己寫 PCIe 驅(qū)動的習(xí)慣給出 probe 的標(biāo)準(zhǔn)動作static int my_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) { struct my_dev *dev; int ret; dev kzalloc(sizeof(*dev), GFP_KERNEL); if (!dev) return -ENOMEM; dev-pdev pdev; pci_set_drvdata(pdev, dev); ret pci_enable_device(pdev); if (ret) goto err_free; ret pci_request_regions(pdev, my_driver); if (ret) goto err_disable; dev-bar pci_iomap(pdev, 0, pci_resource_len(pdev, 0)); if (!dev-bar) goto err_release; pci_set_master(pdev); ret dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64)); if (ret) { ret dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32)); if (ret) goto err_unmap; } ret pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI | PCI_IRQ_INTX); if (ret 0) goto err_unmap; dev-irq pci_irq_vector(pdev, 0); ret devm_request_irq(pdev-dev, dev-irq, my_irq_handler, 0, my_driver, dev); if (ret) goto err_irq; ret misc_register(dev-miscdev); if (ret) goto err_irq; return 0; err_irq: pci_free_irq_vectors(pdev); err_unmap: pci_iounmap(pdev, dev-bar); err_release: pci_release_regions(pdev); err_disable: pci_disable_device(pdev); err_free: kfree(dev); return ret; }對應(yīng)的 remove 就是把這套動作倒著做一遍首先注銷 miscdev 這類對外接口確保不再有用戶態(tài)路徑能摸到設(shè)備然后 free 中斷、釋放中斷向量、iounmap、release regions、disable device最后 kfree。順序不能亂尤其要記住先斷對外接口再斷內(nèi)部資源否則 remove 過程中有進(jìn)程正在讀寫你這邊把 ioremap 釋放了那邊 read 還在訪問非法地址直接 oops。2.2 devm 資源偷懶的前提是搞清楚生命周期上面的錯誤處理鏈里有一堆 goto寫多了容易漏。內(nèi)核提供了一套 devmmanaged device resources機(jī)制注冊的資源會在設(shè)備解除綁定或驅(qū)動移除時自動釋放。比如devm_kzalloc、devm_ioremap、devm_request_irq以及較新內(nèi)核里的devm_request_pci_regions和pcim_enable_device。用 devm 的好處是 probe 中途失敗時不用一個個手動回滾代碼里可以少寫很多錯誤處理標(biāo)簽。但副作用也很明確這些資源按棧順序逆序釋放也就是后申請的反而先釋放。如果你的資源之間有依賴關(guān)系就必須仔細(xì)設(shè)計申請次序。我現(xiàn)在的習(xí)慣是小驅(qū)動直接用 devm 一把梭減少出錯大驅(qū)動則保持手動管理因為移除順序我想完全掌控。有一點必須強(qiáng)調(diào)用了devm_request_irq之后remove 里絕對不要再手動free_irq否則會重復(fù)釋放內(nèi)核直接炸給你看。2.3 suspend/resume別讓設(shè)備在睡眠中失憶現(xiàn)代 PCI 驅(qū)動很少直接在struct pci_driver里寫 suspend/resume 回調(diào)而是用driver.pm my_pm_ops掛dev_pm_ops。掛起時主要做三件事停掉數(shù)據(jù)流DMA 停、中斷屏蔽、保存需要恢復(fù)的寄存器狀態(tài)、把設(shè)備放到低功耗狀態(tài)?；謴?fù)時反過來先恢復(fù) PCI 配置空間再重新初始化設(shè)備內(nèi)部狀態(tài)最后開中斷、啟動 DMA。這里有個最常見的誤解很多人以為 resume 之后 BAR 地址、DMA 配置由內(nèi)核全包了。內(nèi)核確實會恢復(fù)標(biāo)準(zhǔn) PCI 配置空間pci_restore_state但設(shè)備內(nèi)部私有寄存器和 DMA 描述符狀態(tài)屬于設(shè)備固件上下文內(nèi)核管不著。如果硬件固件設(shè)計得比較偷懶D3 之后內(nèi)部狀態(tài)全丟resume 里不重新初始化開起來的 DMA 會像脫韁野馬一樣訪問無效地址。我碰到過一塊板卡resume 后必須重新下發(fā)整個描述符環(huán)基地址否則中斷永遠(yuǎn)不來數(shù)據(jù)也永遠(yuǎn)不更新。3. 地址空間真相BAR、MMIO 與pci out of resources的根因PCI 設(shè)備不直接知道CPU 物理地址這個概念。它只知道自己有幾個 BARBase Address RegisterBAR 是設(shè)備向系統(tǒng)申報地址空間的窗口。固件在枚舉時讀取 BAR 的寫入行為來判斷窗口大小然后給每個窗口分配一段 PCI 域地址這段地址再經(jīng)過 Host Bridge 映射到 CPU 物理地址空間。驅(qū)動要訪問設(shè)備寄存器本質(zhì)上就是訪問這段被映射進(jìn)來的內(nèi)存或 IO 空間。3.1 從 BAR 描述符讀出你要的資源驅(qū)動不要自己去讀配置空間里的 BAR 原始值那是固件和內(nèi)核枚舉階段的事。內(nèi)核已經(jīng)幫你解析好了直接使用pci_resource_*系列函數(shù)resource_size_t start pci_resource_start(pdev, bar); resource_size_t len pci_resource_len(pdev, bar); unsigned long flags pci_resource_flags(pdev, bar);flags 里需要注意兩位IORESOURCE_IO表示 IO 端口空間IORESOURCE_MEM表示內(nèi)存映射空間。內(nèi)存空間里還有IORESOURCE_PREFETCH標(biāo)志表示可預(yù)取。可預(yù)取的含義是讀這個地址沒有副作用、數(shù)據(jù)可以被 CPU 緩存合并。如果你的 BAR 實際是控制寄存器或者 FIFO讀它本身會改變設(shè)備狀態(tài)那就絕不該標(biāo)成 prefetchable。之前調(diào)試一塊回讀 FIFO 的板卡readl 拿回來的數(shù)據(jù)偶爾亂序查到最后就是硬件工程師把 BAR 配成了 prefetchable軟件這邊讀操作被 CPU 重排合并了。3.2 從 PCI 域地址到 CPU 指針ioremap 的三條路拿到pci_resource_start之后你還需要把它映射成內(nèi)核虛擬地址才能用 C 語言訪問。最省事的是pci_iomap它內(nèi)部會根據(jù)資源類型自動選擇ioremap還是ioport_mapvoid __iomem *bar0 pci_iomap(pdev, 0, pci_resource_len(pdev, 0)); if (!bar0) { ... } u32 val ioread32(bar0 REG_STATUS); iowrite32(0x1, bar0 REG_CTRL);這里我建議統(tǒng)一用ioread32/iowrite32而不是readl/writel。兩者在 x86 上行為差別不大但ioread32的語義就是訪問 MMIO移植到 ARM、RISC-V 上更安全。64 位 BAR 也沒有玄學(xué)pci_resource_len返回的已經(jīng)是resource_size_t64 位只要內(nèi)核開啟 64 位資源支持直接按同樣方式訪問即可。3.3 排障實戰(zhàn)新卡在老機(jī)器上報 no space 的完整排查這個報錯值得單獨立一節(jié)因為它不是驅(qū)動的鍋而是整個系統(tǒng)資源分配的鍋。典型 dmesg 長這樣pci 0000:03:00.0: BAR 0: no space for resource [mem size 0x01000000] pci 0000:03:00.0: BAR 0: cant assign mem (size 0x01000000)第一句的意思是設(shè)備想要 16MB 的 MMIO 窗口但系統(tǒng)當(dāng)前的 PCI 域地址空間里找不到連續(xù) 16MB 的空閑區(qū)間。這在老平臺和虛擬機(jī)上特別常見。PCI 地址空間不是無限的傳統(tǒng) PC 在 32 位時代只把 3G 到 4G 附近一段留給 PCI 設(shè)備多個設(shè)備瓜分完就沒了?，F(xiàn)代主板 BIOS 里有Above 4G Decoding選項打開之后才允許把 PCI 資源放到 4G 以上的高位地址空間。我那次遇到的具體情況是一塊板卡 BAR0 要 16MB插上一臺只有 8MB 空閑 MMIO 窗口的舊工控機(jī)報的正是這個錯。排查順序是那一次排查的節(jié)奏是先看lspci -vvv -s 03:00.0發(fā)現(xiàn) Region 0 顯示[size16M]而不是具體地址說明 BAR 沒被分配再看dmesg | grep -i pci立刻定位到 no space 日志最后進(jìn) BIOS 確認(rèn)平臺上確實沒有 Above 4G 選項。你要是也遇到同樣日志處理手段按優(yōu)先級來BIOS 里打開 Above 4G Decoding有些 BIOS 叫 Large BAR、SR-IOV 支持都得開換插槽避開集顯或其他大 BAR 設(shè)備占用的窗口內(nèi)核啟動參數(shù)加pcirealloc讓內(nèi)核在啟動階段強(qiáng)行重新分配所有 PCI 資源虛擬機(jī)環(huán)境則檢查虛擬機(jī)的 MMIO 窗口配置有些 hypervisor 默認(rèn)給 PCIe 預(yù)留空間很小還有一個容易被忽略的細(xì)節(jié)pci_enable_device失敗時也可能報cant enable device: BAR 0 ... not assigned。很多人以為 enable 只是開電源管理實際上它內(nèi)部也會嘗試為未分配資源的 BAR 爭取空間。如果 BAR 壓根沒分到地址這里的報錯只是把枚舉階段的問題延遲到了驅(qū)動加載階段而已。4. 讓數(shù)據(jù)流動起來DMA 設(shè)置與中斷選擇的若干細(xì)節(jié)設(shè)備識別了、寄存器能訪問了但一塊 PCIe 板卡真正的價值在于數(shù)據(jù)搬運(yùn)。這一步繞不開 DMA 和中斷也是驅(qū)動開發(fā)中出錯率最高的部分。4.1 DMA 掩碼先讓設(shè)備夠得著內(nèi)存設(shè)備做 DMA 時要往內(nèi)存總線地址上寫數(shù)據(jù)但設(shè)備本身不知道自己 CPU 物理地址多寬。你需要用dma_set_mask_and_coherent告訴 DMA 層這個設(shè)備認(rèn)得多少位地址if (dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) { if (dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32))) return -EIO; }先試 64 位失敗再退化 32 位這是標(biāo)準(zhǔn)順序。為什么失敗可能是 IOMMU 限制、設(shè)備硬件本身只支持 32 位尋址或者總線地址寬度不足。注意dma_set_mask和dma_set_coherent_mask可以分開設(shè)置一般情況用dma_set_mask_and_coherent一起設(shè)更省事。忘了設(shè)掩碼的后果是 DMA 映射層不知道設(shè)備能力可能交出 64 位地址而設(shè)備只能寫低 32 位數(shù)據(jù)寫入完全隨機(jī)排查時讓人抓狂。4.2 一致性內(nèi)存與流式映射的分工DMA 內(nèi)存分兩大類使用場景完全不同。一致性內(nèi)存用dma_alloc_coherent分配CPU 和設(shè)備看到的地址不需要額外同步。適合放描述符環(huán)、狀態(tài)區(qū)域、控制塊這類需要頻繁被雙方讀寫的小塊數(shù)據(jù)struct ring { struct desc *cpu; dma_addr_t dma; }; ring-cpu dma_alloc_coherent(pdev-dev, ring_size, ring-dma, GFP_KERNEL);流式映射用dma_map_single/dma_map_sg一次映射一段緩沖區(qū)用完就 unmap。適合網(wǎng)絡(luò)包、塊數(shù)據(jù)這類一次性大塊數(shù)據(jù)傳輸。速度更快但 CPU 訪問前必須dma_sync_single_for_cpu設(shè)備訪問前必須dma_sync_single_for_device。我吃過一次虧DMA 完成中斷里直接讀 data buffer發(fā)現(xiàn)數(shù)據(jù)是舊的折騰了半天根源就是忘了在 CPU 讀之前做 synccache 里的舊數(shù)據(jù)擋住了新鮮結(jié)果。還要提醒一點dma_alloc_coherent分配的是頁對齊內(nèi)存別指望它能分配幾十 MB。大塊數(shù)據(jù)老老實實走流式映射或者自己管理 SG 列表。設(shè)備端用什么驅(qū)動端就用對應(yīng)的映射 APIDMA 地址一定要用 API 返回的dma_addr_t不要自己拿 virt_to_phys 算有 IOMMU 的時候這兩個值可能完全不一樣。4.3 MSI 與 INTx 的取舍以及分配向量代碼模板現(xiàn)代 PCIe 設(shè)備優(yōu)先用 MSI/MSI-XINTx 是針腳共享中斷的舊方案能不用就不用。MSI-X 的優(yōu)勢是每個隊列可以分配獨立中斷向量多個 CPU 核分別處理不同隊列吞吐量完全不一樣。分配代碼一般這樣寫int nvec pci_alloc_irq_vectors(pdev, 1, num_queues, PCI_IRQ_MSIX | PCI_IRQ_MSI); if (nvec 0) { nvec pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_INTX); if (nvec 0) return nvec; } for (i 0; i nvec; i) { unsigned int irq pci_irq_vector(pdev, i); devm_request_irq(pdev-dev, irq, my_irq_handler, 0, dev_name(pdev-dev), queue[i]); }pci_alloc_irq_vectors會按你給的類型優(yōu)先級依次嘗試返回值是實際分配到的向量數(shù)。拿到nvec后每個向量的 IRQ 號必須用pci_irq_vector查詢不能假設(shè)它們是連續(xù)的。如果走到 INTx 兜底request_irq里要加IRQF_SHARED因為 INTx 本來就是共享中斷線handler 里必須先讀取設(shè)備中斷狀態(tài)寄存器確認(rèn)是不是自己的中斷不是就返回IRQ_NONE。中斷 handler 本身的撰寫原則是在原子上下文里只做最少的事。讀狀態(tài)、清中斷、把數(shù)據(jù)搬進(jìn)預(yù)分配緩沖、置一個標(biāo)志位、喚起 workqueue然后返回IRQ_HANDLED。重活放到線程化中斷或 workqueue 里硬中斷里做得越少鎖的問題越少系統(tǒng)延遲越可控。我甚至?xí)裷equest_threaded_irq的線程化 handler 作為大塊數(shù)據(jù)處理的主戰(zhàn)場硬中斷只負(fù)責(zé) ack 和喚醒。5. 現(xiàn)場調(diào)試三板斧sysfs、dmesg 與 lspci 的配合寫 PCI 驅(qū)動不是一次就能成功的準(zhǔn)備一套高效的現(xiàn)場排查手段能省下大量時間。我在調(diào)試中用的最多的是這三個工具組合lspci -vvv看設(shè)備狀態(tài)、dmesg看內(nèi)核日志、sysfs 里的接口做動態(tài)試驗。5.1 從 lspci -vvv 讀設(shè)備當(dāng)前狀態(tài)lspci -nnvvv -s 03:00.0是查看單設(shè)備全貌的標(biāo)準(zhǔn)命令。重點看幾個字段Region 0: Memory at ...如果顯示的是實際地址說明 BAR 已分配如果顯示[size16M]而沒有地址說明資源沒分配Interrupt: pin A routed to IRQ 51能看到中斷路由狀態(tài)Capabilities: ... MSI-X確認(rèn) MSI-X 能力是否可用LnkCap/LnkSta鏈路速率和寬度懷疑物理連接問題時先看這里每次加載驅(qū)動前后都跑一遍對比設(shè)備狀態(tài)變化很多時候問題一眼就能看出來。5.2 模擬熱插拔與強(qiáng)制綁定的正確姿勢sysfs 提供了一套不需要斷電的熱插拔試驗環(huán)境。把設(shè)備從總線邏輯上移除再重新掃描echo 0000:03:00.0 /sys/bus/pci/devices/0000:03:00.0/remove echo 1 /sys/bus/pci/rescan這樣模擬一次完整的設(shè)備消失-重新枚舉流程非常適合驗證 probe/remove 的配對邏輯。手動綁定驅(qū)動則在驅(qū)動目錄下操作echo 0000:03:00.0 /sys/bus/pci/drivers/my_driver/bind echo 0000:03:00.0 /sys/bus/pci/drivers/my_driver/unbind如果設(shè)備已經(jīng)被別的驅(qū)動占用了會綁定失敗。這時可以先去占用的驅(qū)動目錄下 unbind再回來綁定。另外一個技巧是driver_override往設(shè)備 sysfs 里寫驅(qū)動名可以強(qiáng)制指定某個驅(qū)動來匹配這個在測試多個候選驅(qū)動時非常管用。5.3 常見問題速查調(diào)試中反復(fù)出現(xiàn)的幾類問題我整理成一個速查表省得每次現(xiàn)查現(xiàn)象可能原因優(yōu)先排查手段probe 不調(diào)用id_table 沒匹配lspci -nn 核對 vendor/device/subsystemmodinfo 看 aliasBAR 分配失敗BIOS 窗口不足dmesg 搜 BAR開 Above 4Gpcirealloc讀寄存器全是 0xFF設(shè)備未 enable、地址映射錯誤、設(shè)備沒上電先 pci_enable_device核對 bar0 虛擬地址中斷不觸發(fā)中斷向量配置錯、設(shè)備中斷源被 mask/proc/interrupts 看計數(shù)嘗試 pcinomsi 排除 MSI 問題中斷風(fēng)暴沒屏蔽掛起中斷、共享誤判probe 早期先把設(shè)備中斷輸出 disable清 pending再 request_irqDMA 數(shù)據(jù)全零DMA 掩碼沒設(shè)、映射錯地址核對 dma_alloc_coherent 返回的 dma_addr 是否正確寫入設(shè)備我再分享一個調(diào)試 DMA 時屢試不爽的小技巧在硬件還沒有真正跑起來之前先讓設(shè)備寫一段已知 pattern 到一致性內(nèi)存里CPU 這邊輪詢這段內(nèi)存如果能看到 pattern說明 DMA 寫路徑和地址映射是通的再把 CPU 寫好的 pattern 讓設(shè)備讀出去驗證讀路徑。先打通地址對不對再去調(diào)數(shù)據(jù)對不對能少走很多彎路。最后說點實在的。Linux PCI 驅(qū)動框架表面上是一堆結(jié)構(gòu)體和回調(diào)實際上它把設(shè)備發(fā)現(xiàn)、資源分配、驅(qū)動綁定、生命周期管理這些臟活全包了。真正考驗開發(fā)者的往往不是 API 記不記得住而是對匹配規(guī)則、資源窗口、DMA 語義和中斷模型的理解是否到位。如果你照著這個思路把 probe 當(dāng)資源清單、把 remove 當(dāng)逆序拆解、把 sysfs 當(dāng)實驗臺絕大多數(shù) PCI 驅(qū)動問題都能一步步拆到根因上。下一篇文章我會挑一個具體的 PCIe DMA 驅(qū)動示例從零到一把完整流程跑一遍。