文章目錄

• • 1 驅動編寫的3種方法
  • • 1.1 傳統寫法
    • 1.2 總線設備驅動模型
    • 1.3 設備樹
  • 2 在 Linux 中實現“分離”：Bus/Dev/Drv 模型
  • • 2.1 模型
    • 2.2 driver和device的匹配規則
    • 2.3 函數調用關系
    • 2.4 常用函數
    • 2.5 如何寫程序

1 驅動編寫的3種方法

以 LED 驅動為例：

1.1 傳統寫法

特點如下：

• 使用哪個引腳，怎么操作引腳，都寫死在代碼中。
• 最簡單，不考慮擴展性，可以快速實現功能。
• 修改引腳時，需要重新編譯。

1.2 總線設備驅動模型

先看一下相關結構體定義：

特點如下：

• 引入 platform_device/platform_driver，將“資源”與“驅動”分離開來。
• 代碼稍微復雜，但是易于擴展。
• 冗余代碼太多，修改引腳時設備端的代碼需要重新編譯。
• 更換引腳時，上圖中的 led_drv.c 基本不用改，但是需要修改 led_dev.c

1.3 設備樹

特點如下：

• 通過配置文件──設備樹來定義“資源”。
• 代碼稍微復雜，但是易于擴展。
• 無冗余代碼，修改引腳時只需要修改 dts 文件并編譯得到 dtb 文件，把它傳給內核。
• 無需重新編譯內核/驅動。

---

2 在 Linux 中實現“分離”：Bus/Dev/Drv 模型

2.1 模型

2.2 driver和device的匹配規則

最先比較： platform_device. driver_override 和 和 platform_driver.driver.name。可以設置 platform_device 的 driver_override，強制選擇某個 platform_driver。

然后比較： platform_device. name 和 和 platform_driver.id_table[i].name，
Platform_driver.id_table 是“platform_device_id”指針，表示該 drv 支持若干個 device，它里面列出了各個 device 的{.name, .driver_data}，其中的“name”表示該 drv 支持的設備的名字，driver_data是些提供給該 device 的私有數據。

最后比較： platform_device.name 和platform_driver.driver.name, platform_driver.id_table 可能為空，這時可以根據 platform_driver.driver.name 來尋找同名的 platform_device。

2.3 函數調用關系

2.4 常用函數

這些函數可查看內核源碼：drivers/base/platform.c，根據函數名即可知道其含義。下面摘取常用的幾個函數。

注冊和反注冊：
platform_device_register/ platform_device_unregister
platform_driver_register/ platform_driver_unregister
platform_add_devices // 注冊多個 device

獲得資源：

2.5 如何寫程序

分配/ 設置/ 注冊 platform_device 結構體：
在里面定義所用資源，指定設備名字。

分配/ 設置/ 注冊 platform_driver 結構體：
在其中的 probe 函數里，分配/設置/注冊 file_operations 結構體，并從 platform_device 中確實所用硬件資源。指定 platform_driver 的名字。

總結

以上是生活随笔為你收集整理的驱动进化之路：总线设备驱动模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。