溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
如何解析Linux驅動中的platform總線，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
先講 Linux 驅動的分離，Linux 操作系統支持在各類 CPU 上運行，因為每一種 CPU 對設備的驅動不一樣，這樣就造成了 Linux 內核中積累了大量代碼，并且這些代碼關于同一設備的描述大致相同，這就使得內核代碼很冗余。以 CPU 通過 I2C 控制 MPU6050 為例：
從圖可以看出每一種平臺下都有一套主機驅動和一套設備驅動，因為每個平臺的 I2C 控制器不同，所以這個主機驅動得每個平臺配一個自己的，但大家所用的 MPU6050 是一樣的，所以完全可以就共用一套設備驅動代碼。完善后框架如下：
當然，這只是對于 I2C 下的 MPU6050 這個設備，實際情況下，I2C 下肯定會掛載很多設備，根據這個思路，我們可以得到框架為：
而在實際開發中，I2C 主機驅動半導體廠家會編寫好，設備驅動也由設備廠家編寫好，我們只需要提供設備信息即可，如設備接到那個 I2C 接口上，I2C 速度為多少。這樣就相當于把設備信息從設備驅動中剝離出來，而設備驅動也會用標準方法去獲取設備信息（如從設備樹中獲取設備信息）。這樣就相當于驅動只負責驅動，設備（信息）只負責設備，想辦法將兩者進行匹配即可，來做這個匹配工作的就是總線，這就構成了 Linux 中的 總線-驅動-設備 模型。結構圖如下：
上面我們講做設備驅動的分離，得到 總線-驅動-設備 模型，這個總線就是我平常所說的 I2C、SPI、USB 等總線。但問題是有些設備是不需要通過某一跟總線的，這是就引入了 platform 總線。
這里需要注意的是，platform 總線是區別于 USB、SPI、I2C 這些總線的虛擬總線。說它虛擬是因為 SoC 與一些外設如 LED、定時器、蜂鳴器是通過內存的尋址空間來進行尋址的，所以 CPU 與這些設備通信壓根就不需要總線，那么硬件上也就沒有這樣一個總線。但內核有對這些設備做統一管理的需求，所以就對這些直接通過內存尋址的設備虛擬了一條 platform 總線，所有直接通過內存尋址的設備都映射到這條虛擬總線上。
platform 總線的優點：
1、通過 platform 總線，可以遍歷所有掛載在 platform 總線上的設備；
2、實現設備和驅動的分離，通過 platform 總線，設備和驅動是分開注冊的，因為有 probe 函數，可以隨時檢測與設備匹配的驅動，匹配成功就會把這個驅動向內核注冊；
3、一個驅動可供同類的幾個設備使用，這個功能的實現是因為驅動注冊過程中有一個遍歷設備的操作。
Linux 內核用 bus_type 結構體來表示總線，我們所用的 I2C、SPI、USB 都是用這個結構體來定義的。該結構體如下：
/* include/linux/device.h */
struct bus_type {
const char *name; /* 總線名字 */
const char *dev_name;
struct device *dev_root;
struct device_attribute *dev_attrs;
const struct attribute_group **bus_groups; /* 總線屬性 */
const struct attribute_group **dev_groups; /* 設備屬性 */
const struct attribute_group **drv_groups; /* 驅動屬性 */
int (*match)(struct device *dev, struct device_driver *drv); /* 設備驅動匹配函數 */
int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
int (*probe)(struct device *dev);
int (*remove)(struct device *dev);
void (*shutdown)(struct device *dev);
int (*online)(struct device *dev);
int (*offline)(struct device *dev);
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);
const struct dev_pm_ops *pm;
const struct iommu_ops *iommu_ops;
struct subsys_private *p;
struct lock_class_key lock_key;
};platform 總線是 bus_type 類型的常量，之所以說它是常量是因為這個變量已經被 Linux 內核賦值好了，其結構體成員對應的函數也已經在內核里面寫好。
定義如下：
/* drivers/base/platform.c */
struct bus_type platform_bus_type = {
.name = "platform",
.dev_groups = platform_dev_groups,
.match = platform_match, /* 匹配函數 */
.uevent = platform_uevent,
.pm = &platform_dev_pm_ops,
};platform_bus_type 中的 platform_match 就是我們前面所說的做驅動和設備匹配的函數，該函數定義如下：
/* drivers/base/platform.c */
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);
/* 設備樹OF類型匹配
驅動基類的 of_match_table 里的 compatible 匹配表與設備樹
每一個設備節點的 compatible 屬性作比較，有相同就表示匹配成功 */
if (of_driver_match_device(dev, drv))
return 1;
/* ACPI 匹配 */
if (acpi_driver_match_device(dev, drv))
return 1;
/* id_table 匹配
platform 驅動里的 id_table 數組會保存很多 id 信息 */
if (pdrv->id_table)
return platform_match_id(pdrv->id_table, pdev) != NULL;
/* name 匹配
直接粗暴比較platform 的驅動和設備里面的 name 信息 */
return (strcmp(pdev->name, drv->name) == 0);
}這個匹配函數什么時候用，在哪里用，我們不妨先留一個懸念。
platform 驅動用結構體 platform_driver 來表示，該結構體內容為：
/* include/linux/platform_device.h */
struct platform_driver {
int (*probe)(struct platform_device *); /* platform驅動和platform設備匹配后會執行這個probe函數 */
int (*remove)(struct platform_device *);
void (*shutdown)(struct platform_device *);
int (*suspend)(struct platform_device *, pm_message_t state);
int (*resume)(struct platform_device *);
struct device_driver driver; /* 驅動基類 */
const struct platform_device_id *id_table; /* id_table表 */
bool prevent_deferred_probe;
};platform_driver 中 const struct platform_device_id *id_table 是 id_table 表，在 platform 總線匹配驅動和設備時 id_table 表匹配法時使用的，這個 id_table 表其實是一個數組，里面的每個元素類型都為 platform_device_id，platform_device_id 是一個結構體，內容如下：
struct platform_device_id {
char name[PLATFORM_NAME_SIZE];
kernel_ulong_t driver_data;
};platform_driver 中 driver 是一個驅動基類，相當于驅動具有的最基礎的屬性，在不同總線下具有的屬性則存放在 platform_driver 結構體下。
驅動基類結構體 device_driver 內容為：
/* include/linux/device.h */
struct device_driver {
const char *name; /* platform 總線來匹配設備與驅動的第四種方
法就是直接粗暴匹配兩者的 name 字段 */
struct bus_type *bus;
struct module *owner;
const char *mod_name;
bool suppress_bind_attrs;
const struct of_device_id *of_match_table; /* 采用設備樹時驅動使用的的匹配表 */
const struct acpi_device_id *acpi_match_table;
int (*probe) (struct device *dev);
int (*remove) (struct device *dev);
void (*shutdown) (struct device *dev);
int (*suspend) (struct device *dev, pm_message_t state);
int (*resume) (struct device *dev);
const struct attribute_group **groups;
const struct dev_pm_ops *pm;
struct driver_private *p;
};driver 中 of_match_table 也是一個匹配表，這個匹配表是 platform 總線給驅動和設備做匹配時使用設備樹匹配時用的，也是一個數組，數組元素都為 of_device_id 類型，該類型結構體如下：
/* include/linux/mod_devicetable.h */
struct of_device_id {
char name[32];
char type[32];
char compatible[128]; /* 使用設備樹匹配時就是把設備節點的 compatible 屬性值和 of_match_table 中
每個項目的這個 compatible 作比較，如果有相等的就表示設備和驅動匹配成功 */
const void *data;
};用 platform_driver 結構體定義好 platform 驅動后，用 platform_driver_register 函數向 Linux 內核注冊 platform 驅動，函數大致流程如下：
platform_driver_register (drv) -> __platform_driver_register -> drv->driver.probe = platform_drv_probe; /* 把 platform_drv_probe 這個函數賦給 platform 驅動里的驅動基類 drier 的 probe 函數 */ -> driver_registe (&drv->driver) /* 向 Linux 內核注冊驅動基類 driver */ -> ...... -> drv->driver->probe /* 最終執行驅動基類 driver 的 probe 函數， 其實就是上面給的 platform_drv_probe 函數 */ -> platform_drv_probe -> drv->probe /* platform_drv_probe 函數又會執行 platform 驅動 drv 的 probe 函數 */
上面的分析中從 driver_register (&drv->driver) 到 drv->driver->probe 這一步我們用省略號代替了，現在來做一下分析：
driver_register(&drv->driver) -> bus_add_driver /* 向總線添加驅動 */ -> driver_attach -> bus_for_each_dev /* 查找總線下每一個設備，即遍歷操作 */ -> __driver_attach /* 每個設備都調用此函數 */ -> driver_match_device /* 檢查是否匹配 */ -> 調用bus下的match匹配函數 -> driver_probe_device /* 匹配成功后執行此函數 */ -> really_probe -> drv->probe /* 執行drv下的probe函數 */
根據 driver_register 函數流程，我們就知道了總線的 match 匹配函數會在這里遍歷使用，這就回答了我們之前留下的一個問題：總線 match 函數在哪里用，一旦匹配成功就會進入到驅動的 probe 函數。
根據 platform_driver_register 函數流程，我們可以得出一個結論：向 Linux 內核注冊 platform driver 過程里面會有一個遍歷驅動和設備匹配的過程，匹配成功后最終會執行 platform driver 的 probe 函數，過程中 的驅動基類 driver 的 probe 函數和 platform_drv_probe 函數都是達到這個目的的中轉函數而已。
值得注意的是，最終會執行的 platform driver 的 probe 函數是由我們來寫的，所以主動權又回到我們手里。
如果我們用的 Linux 版本支持設備樹，那就在設備樹中去描述設備，如果不支持設備樹，就要定義好 platform 設備。這里我們需要考慮的一個點是，總線下的匹配函數 match 在做匹配時是先設備樹匹配，然后 id_table 表匹配，然后才是 name 字段匹配。支持設備樹時，直接在設備樹節點里面改設備信息，內核啟動時會自動遍歷設備樹節點，匹配成功就會自動生成一個 platform_device，給下一步來使用。不是設備樹的話，這個 platform_device 就是由開發者來寫。
這里我們先不用設備樹，自己來定義 platform 設備。platform 設備用 platform_device 結構體來表示，該結構體定義如下：
/* include/linux/platform_device.h */
struct platform_device {
const char *name; /* 設備名，得和對應的 platform 驅動的 name 一樣，
否則設備就無法匹配到對應驅動 */
int id;
bool id_auto;
struct device dev;
u32 num_resources;
struct resource *resource;
const struct platform_device_id *id_entry;
char *driver_override; /* Driver name to force a match */
/* MFD cell pointer */
struct mfd_cell *mfd_cell;
/* arch specific additions */
struct pdev_archdata archdata;
};platform 總線對驅動和設備的匹配過程其實上面零零碎碎也已經講的差不多了，現在我們匯總起來在過一遍。
前面也說過，總線下的驅動和設備的匹配是通過總線下的 match 函數來實現的，不同的總線對應的 match 函數肯定不一樣，這個我們不用管，內核都會寫好。我們所用的 platform 總線對應的 match 函數是 platform_match 函數，分析一下這個函數：
platform_match -> of_driver_match_device /* 設備樹匹配 */ -> acpi_driver_match_device /* ACPI 匹配 */ -> platform_match_id /* platform_driver->id_table 匹配 */ -> strcmp(pdev->name, drv->name) /* name 匹配 */
通過對上面匹配函數的一個簡單分析，我們知道匹配函數做匹配的順序是先匹配設備樹，然后匹配 id_table 表，然后才是暴力匹配 name 字段。對于支持設備樹的 Linux 版本，我們一上來做設備樹匹配就完事。不支持設備樹時，我們就得定義 platform 設備，再用 id_tabale 表或 name 匹配，一般情況下都是選用 name 匹配。
現在我們來具體看一下設備樹條件下的匹配過程：
of_driver_match_device /* of函數一般是用于設備樹，這也算給了我們提示 */ -> of_match_device (drv->of_match_table, dev) -> of_match_node -> __of_match_node -> __of_device_is_compatible -> __of_find_property(device, "compatible", NULL) /* 取出compatible屬性值 */
看上面的分析我們就知道了這個匹配過程最終是驅動基類的 of_match_table 里的 compatible 去設備樹節點里面的 compatible 屬性作比較。這個就是把設備樹與 platform 總線串起來的一個機理，從而實現了在設備樹對應節點里面寫設備信息，驅動另外單獨寫的目的，也就是我們前面講的驅動分離。
在具體的開發過程中我們并不需要真的去寫一個 platform 總線模型，內核中都已經給我們定義好了。我們對 platform 總線模型的分析主要是搞清楚如何將驅動和設備匹配的，即當我們插入設備是如何找到對應驅動或插入驅動如何找到對應設備的，并最終調用 probe 函數。其實不管是先有驅動后有設備、還是先有設備后有驅動，最終匹配成功后第一件事都是執行驅動的 probe 函數，所以我們盡可放心的忽略中間曲折的情感糾葛，直接把注意力放在最終的 probe 函數。
看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
