調試一顆SPI接口的傳感器時最讓人抓狂的場景往往不是波形完全沒動靜而是片選拉低了、時鐘也出來了代碼里spi_read()返回 0 表示成功緩沖區(qū)里卻清一色是 0xFF或者單字節(jié)讀 ID 一切正常一旦連續(xù)讀幾十字節(jié)就后半段全是臟數據。前面折騰寄存器手冊、上電時序、Mode 配錯最后發(fā)現問題出在對spi_message和spi_transfer的理解上——消息被拆成了幾段cs_change位置放錯片選在中間被抬高了一次從機狀態(tài)機直接復位。這篇內容圍繞 Linux 下 SPI 設備驅動的數據收發(fā)處理流程把這條鏈路上真正起作用的結構體和函數逐個拆開講。包括spi_device、spi_driver、spi_controller這三者怎么湊到一起spi_message和spi_transfer怎么組織一次完整的事務spi_sync與spi_async的調用鏈差在哪里控制器側的transfer_one_message與set_cs又是怎么把數據真正推到時序線上的。適合已經能寫字符設備、但一遇到 SPI 時序問題就卡住的驅動開發(fā)者也適合想把現有驅動從能跑改到穩(wěn)跑的老手。下面這些內容全部基于內核 SPI 子系統的通用實現邏輯不同版本在字段命名上有差異比如老的spi_master后來并入spi_controller我會在關鍵處點出來。1. 從設備樹節(jié)點到 probe 函數spi_device 與 spi_driver 的匹配鏈路很多人寫 SPI 驅動是照著模板抄的of_match_table填了、probe寫了、spi_setup()調了設備能起來但問到spi_device里的max_speed_hz到底是誰填的、什么時候填的就說不清了。而恰恰是這幾個字段決定了后面每一次傳輸的時鐘頻率、字長和片選行為配錯了就是上面那種讀回全 FF的經典故障。1.1 spi_device 不是驅動 new 出來的是總線枚舉出來的這一點必須先掰清楚。你寫的驅動里沒有kzalloc(sizeof(struct spi_device))spi_device是 SPI 總線在枚舉階段創(chuàng)建的驅動只是認領其中一個。整條鏈路大致是設備樹里有一個掛在 SPI 控制器下面的子節(jié)點帶compatible、reg、spi-max-frequency等屬性控制器驅動在probe里注冊控制器devm_spi_register_controller內核遍歷該控制器下的子節(jié)點每個子節(jié)點對應調用一次spi_alloc_device()分配spi_device再由of_spi_parse_dt()或spi_device_parse_dt這類平臺相關的解析函數把 DTS 屬性灌進去接著spi_add_device()把這個spi_device掛到總線設備鏈表上注冊到設備模型總線開始匹配找到spi_driver調用你的probe。所以probe被調用的時候spi-max_speed_hz、spi-mode、spi-chip_select、spi-bits_per_word這些字段已經是從設備樹里解析好的初值。你的probe里再調spi_setup(spi)作用是把驅動想用的配置和控制器能力做一次協商和下發(fā)而不是從零開始填。這里有個實際影響如果你在probe里手改spi-mode但忘了重新調spi_setup()控制器寄存器還是舊配置波形不會變。反過來如果 DTS 里根本沒有spi-max-frequency解析出來的max_speed_hz可能是 0很多控制器會退化成默認頻率常見是幾百 kHz 到 1 MHz這時候你會發(fā)現明明寫了 10M示波器上只有 500k根子不在驅動代碼里。1.2 關鍵字段逐個說清楚它們的生效位置spi_device字段不少但真正影響數據收發(fā)的就這幾個我把它們和在哪一層生效對應起來字段來源生效位置配錯的典型表現max_speed_hzDTSspi-max-frequency驅動可下調spi_transfer.speed_hz為空時用它頻率過高導致采樣錯位讀回數據高位錯亂modeDTSspi-cpol/spi-cpha或spi-tx/rx-*spi_setup()下發(fā)到控制器CPOL/CPHA 反了數據整體偏移一位bits_per_wordDTS 或驅動設置每次 transfer 繼承8/16 位混用字節(jié)序錯亂chip_selectDTSreg控制器set_cs使用片選錯位多個從機同時被選中cs_gpiodDTScs-gpios控制器用 GPIO 做片選時GPIO 方向或電平反了從機永遠不被選中irqDTSinterrupts驅動request_irq使用中斷觸發(fā)類型不對讀數據永遠等不到mode這個字段值得單獨說一句。它的低兩位是 CPOL 和 CPHA高位還有SPI_CS_HIGH、SPI_LSB_FIRST、SPI_3WIRE、SPI_LOOP、SPI_NO_CS、SPI_READY這些標志位。很多人只關心 CPOL/CPHA忽略了SPI_CS_HIGH——如果你的從機片選是高電平有效DTS 里沒寫spi-cs-high那控制器會一直按低有效處理結果就是從機上電后始終處于選中態(tài)你發(fā)什么它都在聽但片選松開的動作永遠不發(fā)生從機內部狀態(tài)機就不會復位。這類問題在單次讀 ID 時可能碰巧能過連續(xù)讀寫時必然出錯。1.3 spi_driver 的兩條匹配路徑OF 匹配與 modalias 匹配spi_driver結構體本身很簡單核心就三塊struct device_driver driver內含of_match_table、name、pm回調、const struct spi_device_id *id_table、probe/remove。匹配走的是 SPI 總線的match函數邏輯順序是先看of_driver_match_device()也就是of_match_table里的compatible和設備樹節(jié)點比對如果不匹配再看spi_match_device()用id_table里的名字和spi-modalias比對兩條都不中設備就掛著沒人管/sys/bus/spi/devices/下能看到它但driver鏈接是空的。提示modalias一般由compatible字符串轉換而來斜杠、逗號之類的字符會被替換所以只寫of_match_table通常也能匹配上但在某些用spi_board_info靜態(tài)注冊設備的平臺上modalias來自spi_board_info.modalias這時候id_table就是必須的。兩種都寫是最穩(wěn)的做法。probe的返回值也有講究。返回 0 表示接管成功返回-ENODEV或-ENXIO表示這個設備我不認識總線會繼續(xù)嘗試其他驅動在有多驅動競爭同一 compatible 時有用返回其他負值則是硬失敗設備進入probe failed狀態(tài)不會再重試。我見過把-EPROBE_DEFER寫成-EAGAIN的結果電源管理芯片還沒就緒SPI 設備直接放棄注冊后續(xù)永遠起不來。2. spi_message 與 spi_transfer一次事務到底被拆成了什么如果說spi_device是跟誰說話那spi_message就是這一趟要說幾句、每句多長。這是整個 SPI 驅動里最需要動腦子設計的地方也是最容易埋坑的地方。因為 SPI 是全雙工但半雙工時序的總線一次片選拉低期間可以連續(xù)發(fā)多段數據、中間夾延時、甚至在中途抬片選這些復雜行為全靠spi_message里掛的spi_transfer鏈表來描述。2.1 spi_transfer 的字段決定了每一段的物理形態(tài)一個spi_transfer描述一段連續(xù)傳輸核心字段tx_buf/rx_buf發(fā)送和接收緩沖區(qū)指針可以為 NULL。兩個都為 NULL 就是純延時配合delay用。len這一段傳輸的字節(jié)數。speed_hz本段專用頻率為 0 則繼承spi_device.max_speed_hz。bits_per_word本段專用字長為 0 則繼承。delay這一段結束后、下一段開始前的延時結構體spi_delay支持微秒和納秒兩種單位。cs_change這一段結束后是否改變片選狀態(tài)語義在不同上下文下不一樣后面細講。tx_nbits/rx_nbits單線、雙線、四線、八線模式用于 QSPI/OctalSPI。tx_dma/rx_dmaDMA 地址僅當is_dma_mapped為真時有效老式用法新代碼基本不用。這里最容易搞錯的是delay和cs_change的組合語義。舉個真實場景讀一個 SPI 接口的 ADC協議要求發(fā)命令字 → 等 10 微秒轉換 → 讀結果。正確做法是三段 transfer第一段tx_buf cmd, len 1發(fā)命令第二段tx_buf NULL, rx_buf NULL, len 0, delay 10us純延時第三段rx_buf buf, len 2讀結果。如果圖省事把延時塞在第二段的delay上然后直接讀你會發(fā)現時鐘線在延時期間的狀態(tài)不符合從機要求——因為延時發(fā)生在段與段之間片選保持低電平但時鐘停在最后一個邊沿某些從機會把這當成一次額外的時鐘跳變。這種情況在手冊里通常寫成CS must remain low during conversion但沒告訴你 SCLK 要保持什么電平只能靠示波器驗證。2.2 棧上分配 message 是常見做法但異步場景下是致命錯誤標準寫法是這樣的struct spi_transfer xfer { .tx_buf tx, .rx_buf rx, .len len, }; struct spi_message msg; spi_message_init(msg); spi_message_add_tail(xfer, msg); ret spi_sync(spi, msg);spi_message_init()做的是INIT_LIST_HEAD(msg-transfers)加上若干字段清零spi_message_add_tail()把 transfer 掛到鏈表尾部并累加frame_length。這兩個函數本身沒有內存分配所以把 message 和 transfer 放在棧上是完全合法且最常見的做法——前提是用spi_sync。換成spi_async就完全不一樣了。spi_async在把消息掛進控制器的隊列后就返回了真正的傳輸是異步完成的。如果你在函數里定義棧上的spi_message函數一返回棧幀被覆蓋控制器后面再去訪問msg-transfers鏈表讀到的就是垃圾指針。表現出來往往是隨機的內核 oops而且現場很難復現因為取決于棧被覆寫的時機。正確做法是用spi_async時把spi_message和spi_transfer一起嵌進驅動的私有結構體用kzalloc分配或作為設備結構體成員并在complete回調里統一釋放。這個坑我在早期項目里踩過一次現象是高負載下偶發(fā) panic查了兩天才定位到。2.3 什么時候必須拆成多段什么時候一段就夠判斷標準其實只有一條從機的協議是否要求在某段數據之間插入片選變化或延時空檔。不需要就合并成一段需要就拆。合并的好處很實際減少 message 內部循環(huán)次數、減少控制器與驅動的交互開銷、對 DMA 更友好長連續(xù)緩沖區(qū)比多段短緩沖區(qū)更容易映射成大塊。有些控制器對單個 transfer 有長度上限controller-max_transfer_size超過需要驅動自己拆但這個是控制器能力限制和協議要求是兩回事。需要拆的典型情況命令與數據之間有轉換時間要求如某些溫濕度傳感器讀操作要求先寫地址、抬片選、再拉低片選讀數據部分 EEPROM 的時序需要在同一片選周期內切換頻率speed_hz是 per-transfer 的整段 message 共享頻率的話就不需要拆全雙工通信里發(fā)送和接收長度不對稱且硬件 FIFO 深度有限。spi_write_then_read()這個輔助函數就是兩段合并的封裝它內部構造兩段 transfer寫 讀中間不抬片選適合絕大多數寄存器地址 讀數據的場景。但要注意它有棧上分配內部 buffer 的行為傳輸長度受SPI_BUFSIZ限制通常是 32 字節(jié)左右超過就得自己拼 message。3. spi_sync 與 spi_async調用鏈一同步一異步語義差別很大很多驅動里spi_sync和spi_async是混著用的初始化讀 ID 用spi_sync中斷里讀數據用spi_async。但兩者的調用鏈和控制流完全不同混用不當就會出問題——最常見的是在原子上下文里調spi_sync導致睡眠告警或者spi_async的返回值被誤當成傳輸完成。3.1 spi_sync 的執(zhí)行路徑與返回值語義spi_sync(spi, message)內部大致是加總線鎖spi_bus_lock保證同一時刻一個控制器上只有一個 message 在處理把 message 掛進controller-queue調用控制器的transfer老接口或transfer_one_message新接口啟動傳輸用completion等待傳輸結束wait_for_completion喚醒后返回message-status。關鍵點在于spi_sync是可能睡眠的。它要等 completion要持有可睡眠的鎖所以絕對不能在中斷上下文、軟中斷、或者持有自旋鎖的區(qū)域里調用。真在中斷里需要發(fā)數據只能用spi_async或者把工作推給 workqueue/線程化中斷。返回值語義也要注意spi_sync返回 0 只代表消息走完了流程沒有報錯不代表從機給出了有效應答。從機不回數據、總線被拉死、MISO 懸空spi_sync照樣返回 0只有超時或控制器報錯才會返回負值。所以判斷通信是否成功必須校驗接收緩沖區(qū)內容比如讀 ID 寄存器比對預期值不能只看返回值。message-actual_length是另一個有用的字段它記錄了實際傳輸的字節(jié)數。正常情況下等于frame_length但如果控制器中途出錯或被信號打斷actual_length會比預期小這時候即使status是 0也要當作部分失敗處理。3.2 spi_async 的回調上下文與資源釋放時機spi_async(spi, message)的返回值含義和spi_sync完全不同返回 0消息已成功入隊傳輸會在稍后發(fā)生返回負值入隊失敗消息根本沒發(fā)出去complete回調不會被調用。入隊成功后控制器完成傳輸時會調用message-complete(message-context)。這個回調可能在中斷上下文里執(zhí)行所以里面不能睡眠、不能調spi_sync、不能kfree帶鎖的資源用kfree本身可以但不能在里面等待?；卣{里通常只做三件事置完成標志、喚醒等待隊列、把數據掛到環(huán)形緩沖區(qū)。資源釋放的時機是另一個高頻錯誤點。很多人寫成ret spi_async(spi, msg); if (ret 0) kfree(msg.transfers); /* 錯傳輸還沒開始 */正確的做法是讓complete回調負責釋放或者用一個引用計數把驅動持有和控制器持有分開。更省事的做法是把 message 和 transfer 內嵌在設備私有結構體里用一把自旋鎖保護當前是否有傳輸在進行的狀態(tài)而不是每次動態(tài)分配。注意spi_async不保證消息按調用順序執(zhí)行雖然多數控制器內部是 FIFO 隊列但驅動層不該依賴這個假設。如果協議有嚴格順序要求比如先配置寄存器再讀數據要么用spi_sync串起來要么自己在驅動層維護隊列等上一個回調完成再發(fā)下一個。3.3 transfer_one_message 與 transfer_one控制器側的兩套接口寫設備驅動的人一般不用直接碰這兩個但理解它們有助于判斷問題出在驅動還是控制器。spi_controller里有兩個回調transfer_one_message(ctlr, msg)控制器負責整條 message 的處理自己遍歷 transfer 鏈表處理片選、延時、頻率切換全部完成后調spi_finalize_current_message(ctlr)。返回 0 表示已接管稍后完成。transfer_one(ctlr, msg, xfer)控制器只處理一段transfer返回 1 表示這段已完成且整條 message 也完成返回 0 表示這段已啟動但異步完成返回負值表示出錯。由 SPI 核心的spi_transfer_one_message()負責遍歷鏈表、調set_cs、調spi_transfer_delay_exec?，F代驅動大多實現transfer_one因為核心幫你處理了鏈表遍歷和延時控制器只需要關心怎么把一段 buffer 變成時序。但這也意味著延時和片選的語義由核心統一解釋你在設備驅動里寫的delay和cs_change最終是被spi_transfer_delay_exec()和spi_set_cs()消費的。4. 片選與延時被低估的時序細節(jié)全在 spi_controller 這一側數據收發(fā)出問題八九成的根因不在數據緩沖區(qū)而在片選和延時。這兩個東西在設備驅動代碼里通常只體現為一個cs_change標志和一個delay字段但它們在控制器側的執(zhí)行方式直接決定了波形長什么樣。4.1 set_cs 與 cs_gpiod片選到底是硬件還是 GPIOspi_controller有兩種片選實現方式硬件片選控制器外設自帶 CS 引腳驅動實現set_cs(ctlr, spi, enable)回調直接寫寄存器。這種方式時序最準片選動作和時鐘邊沿的間隔由硬件保證。GPIO 片選DTS 里寫cs-gpios核心把 GPIO 描述符填進spi-cs_gpiod由核心的spi_set_cs()統一操作 GPIO。這種方式靈活但時序精度差——GPIO 操作要經過幾層函數調用片選到第一個時鐘邊沿的建立時間可能達到微秒級。對于高速 SPI比如 20 MHz 以上GPIO 片選經常導致第一個字節(jié)采樣錯誤因為片選建立時間不夠。解決方式有兩種一是改用控制器硬件片選二是在 DTS 里配置cs-setup-us對應spi-cs_setup來插入建立延時代價是降低吞吐。還有一個容易忽略的字段cs_inactive。它定義片選無效時的電平默認是高電平對應低有效片選。如果從機是高有效片選除了SPI_CS_HIGH標志還要確認cs_inactive的值和硬件實際電平匹配否則會出現片選看起來在動但邏輯反了的情況。4.2 delay 的兩種單位與 spi_transfer_delay_exec 的執(zhí)行位置spi_transfer.delay是struct spi_delay類型里面有一個value和一個unit單位可以是SPI_DELAY_UNIT_USECS或SPI_DELAY_UNIT_NSECS。早期內核用的是delay_usecs純微秒新代碼建議用delay結構體因為納秒級延時在高速時序里是剛需。執(zhí)行位置在spi_transfer_one_message()的循環(huán)里一段 transfer 交給控制器完成或啟動后核心調用spi_transfer_delay_exec(xfer)執(zhí)行延時然后根據cs_change決定是否調spi_set_cs()。這里的執(zhí)行順序是先延時后處理片選。所以如果你寫延時 10 微秒后抬片選寫法是delay 10uscs_change 1而不是反過來。理解這一點很多片選提前松開的詭異現象就解釋得通了。納秒級延時的實現方式取決于平臺有的用ndelay()有的用控制器自帶的延時計數器更準有的干脆退化成udelay()不準。如果協議要求嚴格的納秒級間隔比如某些高速 ADC 的轉換觸發(fā)最好確認控制器是否支持硬件延時否則只能降頻換取時序余量。4.3 cs_change 的三層語義別只記一種cs_change的含義在不同位置完全不同這是 SPI 子系統里最容易誤用的字段場景cs_change 語義一段 transfer 之后后面還有別的 transfer抬片選、再拉低制造一個片選脈沖最后一段 transfer 之后傳輸結束后保持片選有效不抬只有一段 transfer 的 message同上傳輸結束后保持片選也就是說cs_change 1在中間位置是切換在末尾位置是保持。很多人以為它統一是切換片選結果在單段 message 上設了cs_change 1期望傳輸完抬片選實際卻是一直保持低電平從機永遠不釋放總線下一次通信直接沖突。這個設計的歷史原因是為了支持多次 message 共享一個片選周期的場景。要讓片選在末尾抬起正確做法是cs_change 0默認值。4.4 頻率切換的實際代價speed_hz是 per-transfer 的看起來可以隨意在 message 內部切頻率。但實際執(zhí)行時控制器每次切換頻率都要重算分頻寄存器某些控制器還會有切換后需要等待若干個時鐘周期穩(wěn)定的隱性要求。如果 message 里塞了七八段不同頻率的 transfer實際吞吐可能比單一頻率還低。我的經驗是除非協議強制要求比如配置階段用低頻、數據傳輸用高頻否則整條 message 用統一頻率靠spi_device.max_speed_hz一次性設定。真要分段改頻率把不同頻率的部分拆成獨立 message中間用spi_sync串起來代碼更清晰調試也更容易。5. 排查鏈路實錄從讀回全 FF到定位到具體字段理論講完說點實際的。下面這條排查鏈路是我在一個 SPI 傳感器項目里真實走過的順序基本可以復用到大多數通信不通的場景。5.1 第一步永遠是確認物理層而不是改代碼拿到讀回全 FF的現象先別急著懷疑驅動。全 FF 意味著 MISO 一直保持高電平可能的原因有從機沒上電、從機沒被片選選中、MISO 線沒接、從機處于復位狀態(tài)、從機根本沒收到有效命令。用邏輯分析儀抓四根線CS、SCLK、MOSI、MISO看三件事片選有沒有真的被拉低如果一直是高問題在片選配置SCLK 有沒有波形如果沒有檢查控制器是否真的啟動了傳輸或者時鐘引腳復用沒配對MOSI 上發(fā)的字節(jié)和代碼里寫的是否一致如果 MOSI 全 0說明發(fā)送緩沖區(qū)根本沒被控制器讀到。這一步能排掉一半的問題。我遇到過一次spi_sync返回 0、波形全無最后發(fā)現是控制器的時鐘門控沒開probe里漏了clk_prepare_enable()。代碼層面完全看不出來只有波形能告訴你真相。5.2 波形正常但數據錯按 mode、字長、字節(jié)序的順序排波形有了數據不對按這個順序排ModeCPOL/CPHA 四種組合抓波形對照從機手冊的時序圖。CPHA 錯位表現為數據整體偏移半個到一個時鐘讀出來的值看著像但不對。字長bits_per_word是 8 還是 16如果從機是 16 位寄存器、你按 8 位發(fā)地址會被拆成兩個字節(jié)從機收到的是錯誤地址。字節(jié)序SPI_LSB_FIRST標志。絕大多數 SPI 器件是 MSB first但有些傳感器是 LSB first配反了讀出來的值位序是鏡像的。位寬模式單線、雙線、四線。tx_nbits配成 2 但硬件只接了 MOSI 一根線數據會丟一半。這四項里Mode 和字長占問題總量的八成以上。我現在的習慣是新器件上手先用最低頻率1 MHz 以下、8 位字長、Mode 0 跑通讀 ID再逐步往上加頻率和改 Mode每改一項驗證一次出問題立刻知道是哪一項。5.3 短傳輸正常、長傳輸出錯看長度上限和 DMA 對齊這是另一類高頻問題。單字節(jié)讀 ID 正常連續(xù)讀 64 字節(jié)就后半段全是臟數據。原因通常有三個控制器單次傳輸長度上限。controller-max_transfer_size和max_message_size是控制器能力聲明如果超了有的控制器會截斷有的直接報錯。查/sys/class/spi_master/spiX/下有沒有相關屬性或者在驅動里讀ctlr-max_transfer_size判斷。DMA 緩沖區(qū)對齊。走 DMA 的控制器通常要求緩沖區(qū)按 cache line 對齊32 或 64 字節(jié)。用kmalloc分配的緩沖區(qū)不保證對齊棧上的緩沖區(qū)更是隨機。表現為前半段對、后半段錯因為跨 cache line 的部分被 DMA 跳過或重復搬運。解決辦法是用dma_alloc_coherent()或者在spi_message上依賴核心的spi_map_msg()做 bounce buffer。從機 FIFO 深度限制。有些從機的接收 FIFO 只有 8 字節(jié)你連續(xù)發(fā) 64 字節(jié)超出部分被丟棄。這種情況必須在 message 里拆段每段之間加延時等從機取走數據。5.4 用 spi_statistics 和動態(tài)調試定位瓶頸內核給每個spi_device和spi_controller都掛了統計計數器在/sys/class/spi_master/spiX/statistics/和/sys/class/spi_master/spiX/spiX.Y/statistics/下可以看到bytes_tx/bytes_rx累計收發(fā)字節(jié)數和你代碼里的預期對不上就說明有傳輸被丟棄messages/transfers消息數和段數用來驗證 message 拆分是否符合預期errors錯誤計數配合timedout判斷是不是超時spi_sync/spi_async兩種調用的次數。排查時先cat一遍這些計數器跑一輪測試再cat一遍差值能告訴你很多信息。比如messages增加了 1 但transfers增加了 5說明你的 message 被拆成了 5 段如果預期是 2 段那拆分邏輯就有問題。動態(tài)調試也很實用echo file spi.c p /sys/kernel/debug/dynamic_debug/control echo file spi-mem.c p /sys/kernel/debug/dynamic_debug/control dmesg -w打開后能看到每次spi_sync的 message 長度、每段 transfer 的參數、控制器的啟動和完成時間點。配合 ftrace 的irqsoff或preemptofftracer還能看出傳輸過程中是否被中斷打斷。6. 一份能直接改著用的驅動骨架最后給一份完整骨架覆蓋注冊、probe、讀寫封裝、卸載。省略了具體寄存器操作重點在結構體初始化和 message 組織方式上。6.1 私有結構體與驅動的注冊struct myspi_dev { struct spi_device *spi; struct mutex io_lock; /* 串行化并發(fā)訪問 */ u8 *tx_buf; u8 *rx_buf; struct spi_transfer xfer; struct spi_message msg; }; static const struct of_device_id myspi_of_match[] { { .compatible vendor,myspi-sensor }, { } }; MODULE_DEVICE_TABLE(of, myspi_of_match); static const struct spi_device_id myspi_id[] { { myspi-sensor, 0 }, { } }; MODULE_DEVICE_TABLE(spi, myspi_id); static struct spi_driver myspi_driver { .driver { .name myspi-sensor, .of_match_table myspi_of_match, .pm myspi_pm_ops, }, .id_table myspi_id, .probe myspi_probe, .remove myspi_remove, }; module_spi_driver(myspi_driver);module_spi_driver()展開后就是spi_register_driver()加模塊退出時的spi_unregister_driver()。id_table和of_match_table都寫覆蓋 DTS 枚舉和spi_board_info靜態(tài)注冊兩條路徑。6.2 probe 里必須做的事static int myspi_probe(struct spi_device *spi) { struct myspi_dev *dev; int ret; dev devm_kzalloc(spi-dev, sizeof(*dev), GFP_KERNEL); if (!dev) return -ENOMEM; dev-spi spi; mutex_init(dev-io_lock); spi_set_drvdata(spi, dev); /* 頻率不超過從機上限字長固定 8 位Mode 從 DTS 繼承 */ spi-max_speed_hz min(spi-max_speed_hz, 10000000u); spi-bits_per_word 8; spi-mode ~SPI_MODE_X_MASK; /* 如需強制 Mode 0可在此處改 */ ret spi_setup(spi); if (ret) { dev_err(spi-dev, spi_setup failed: %d\n, ret); return ret; } dev-tx_buf devm_kmalloc(spi-dev, MYSPI_MAX_XFER, GFP_KERNEL | __GFP_DMA); dev-rx_buf devm_kmalloc(spi-dev, MYSPI_MAX_XFER, GFP_KERNEL | __GFP_DMA); if (!dev-tx_buf || !dev-rx_buf) return -ENOMEM; spi_message_init(dev-msg); dev-xfer.tx_buf dev-tx_buf; dev-xfer.rx_buf dev-rx_buf; spi_message_add_tail(dev-xfer, dev-msg); return myspi_hw_init(dev); }幾個細節(jié)緩沖區(qū)用__GFP_DMA分配是為了提高 DMA 可用概率但真正的 cache line 對齊還要靠dma_alloc_coherentspi_setup()必須在改完mode/bits_per_word/max_speed_hz之后調用否則改動不生效spi_message_init和spi_message_add_tail放在 probe 里做一次后續(xù)每次傳輸只改xfer.len和緩沖區(qū)內容減少重復開銷。6.3 讀寫封裝一段式 message 的復用static int myspi_xfer(struct myspi_dev *dev, const u8 *tx, u8 *rx, size_t len) { int ret; if (len 0 || len MYSPI_MAX_XFER) return -EINVAL; mutex_lock(dev-io_lock); if (tx) memcpy(dev-tx_buf, tx, len); else memset(dev-tx_buf, 0, len); dev-xfer.len len; dev-xfer.speed_hz 0; /* 繼承 spi_device 設置 */ dev-xfer.bits_per_word 0; dev-xfer.delay.value 0; dev-xfer.cs_change 0; ret spi_sync(dev-spi, dev-msg); if (ret 0 rx) memcpy(rx, dev-rx_buf, len); mutex_unlock(dev-io_lock); return ret; }用mutex而不是自旋鎖因為spi_sync會睡眠。xfer和msg在結構體里復用避免每次動態(tài)分配。傳輸完成后memcpy出來是因為下一次傳輸會覆蓋rx_buf不拷走的話數據就丟了。單段 message 里cs_change保持 0傳輸結束后片選自動抬起這是絕大多數從機期望的行為。如果從機要求多段之間保持片選才需要構造多段 message 并單獨處理cs_change。6.4 remove 與異常路徑static void myspi_remove(struct spi_device *spi) { struct myspi_dev *dev spi_get_drvdata(spi); myspi_hw_suspend(dev); /* mutex 不需要顯式銷毀devm 分配的內存自動釋放 */ }因為全部用devm_*分配remove 里基本不用手動釋放。唯一要注意的是如果驅動里用了spi_asyncremove 之前必須確保沒有正在進行的傳輸否則回調觸發(fā)時私有結構體已經被釋放。做法是在 remove 里先置一個shutdown標志然后wait_for_completion_timeout()等當前傳輸結束。7. 幾個用血換來的經驗第一永遠先用spi_sync把功能跑通再考慮優(yōu)化成spi_async。異步帶來的復雜度和并發(fā)問題只有在確實需要中斷上下文、高吞吐隊列時才值得。很多驅動寫異步是因為看起來性能更好實際 SPI 總線速率受限于從機異步省下的那點調度開銷根本體現不出來。第二spi_setup()的返回值一定要檢查。它內部要和控制器協商頻率、字長、模式如果控制器不支持你要求的組合會返回-EINVAL。忽略這個返回值后面所有傳輸都會用上一次生效的配置跑現象莫名其妙。第三調試時把max_speed_hz降到 1 MHz 以下。絕大多數時序問題是頻率太高導致的建立/保持時間不夠降頻后問題消失就說明是時序余量問題而不是邏輯錯誤。這個技巧能幫你在一分鐘內把問題范圍縮小一半。第四給每個關鍵傳輸點加dev_dbg打印actual_length和status。status為 0 但actual_length小于預期的情況說明傳輸被部分完成這種隱性失敗最容易被漏掉。第五片選是 SPI 里最不像數據線的數據線。它不傳數據但決定了數據的邊界。所有數據看起來錯位讀出來多一個字節(jié)偶爾成功偶爾失敗的問題先懷疑片選時序比懷疑數據緩沖區(qū)有效得多。