plateform總線
系統(tǒng)啟動(dòng)時(shí)初始化時(shí)創(chuàng)建了platform_bus設(shè)備和platform_bus_type總線:
本文引用地址:http://cafeforensic.com/article/201612/330494.htm內(nèi)核初始化函數(shù)kernel_init()中調(diào)用了do_basic_setup(),該函數(shù)中調(diào)用driver_init(),該函數(shù)中調(diào)用platform_bus_init(),我們看看platform_bus_init()函數(shù):
int __init platform_bus_init(void)
{
}
device_register(&platform_bus)中的platform_bus如下:
struct device platform_bus = {
};
改函數(shù)把設(shè)備名為platform的設(shè)備platform_bus注冊(cè)到系統(tǒng)中,其他的platform的設(shè)備都會(huì)以它為parent。它在sysfs中目錄下.即/sys/devices/platform。
接著bus_register(&platform_bus_type)注冊(cè)了platform_bus_type總線,看一下改總線的定義:
struct bus_type platform_bus_type = {
};
默認(rèn)platform_bus_type中沒(méi)有定義probe函數(shù)。
我們分析一下其中platform_match和platform_uevent函數(shù)。在分析設(shè)備驅(qū)動(dòng)模型是已經(jīng)知道總線類型match函數(shù)是在設(shè)備匹配驅(qū)動(dòng)時(shí)調(diào)用,uevent函數(shù)在產(chǎn)生事件時(shí)調(diào)用。
platform_match()代碼如下:
static int platform_match(struct device *dev, struct device_driver *drv)
{
}
static const struct platform_device_id *platform_match_id(
{
}
不難看出,如果pdrv的id_table數(shù)組中包含了pdev->name,或者drv->name和pdev->name名字相同,都會(huì)認(rèn)為是匹配成功。id_table數(shù)組是為了應(yīng)對(duì)那些對(duì)應(yīng)設(shè)備和驅(qū)動(dòng)的drv->name和pdev->name名字不同的情況。
再看看platform_uevent()函數(shù):
static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
{
}
添加了MODALIAS環(huán)境變量,我們回顧一下:platform_bus. parent->kobj->kset->uevent_ops為device_uevent_ops,bus_uevent_ops的定義如下:
static struct kset_uevent_ops device_uevent_ops = {
};
當(dāng)調(diào)用device_add()時(shí)會(huì)調(diào)用kobject_uevent(&dev->kobj, KOBJ_ADD)產(chǎn)生一個(gè)事件,這個(gè)函數(shù)中會(huì)調(diào)用相應(yīng)的kset_uevent_ops的uevent函數(shù),這里即為dev_uevent(),我們看一下這個(gè)函數(shù)的代碼片段:
static int dev_uevent(struct kset *kset, struct kobject *kobj,
{
}
從這里看到如果bus->uevent()函數(shù)存在則會(huì)調(diào)用它。
到這里我們清楚了platform_uevent會(huì)在哪里調(diào)用了。
二.Platform設(shè)備的注冊(cè)
我們?cè)谠O(shè)備模型的分析中知道了把設(shè)備添加到系統(tǒng)要調(diào)用device_initialize()和platform_device_add(pdev)函數(shù)。
對(duì)于platform設(shè)備的初始化,內(nèi)核源碼也提供了platform_device_alloc()函數(shù)。
對(duì)于platform設(shè)備的初注冊(cè),內(nèi)核源碼提供了platform_device_add()函數(shù),它是進(jìn)行一系列的操作后調(diào)用device_add()將設(shè)備注冊(cè)到相應(yīng)的總線上,內(nèi)核代碼中platform設(shè)備的其他注冊(cè)函數(shù)都是基于這個(gè)函數(shù),如platform_device_register()、platform_device_register_simple()、platform_device_register_data()等。
我們對(duì)這些函數(shù)逐個(gè)分析,首先看看初始化函數(shù)platform_device_alloc():
struct platform_device * platform_device_alloc(const char *name, int id)
{
}
該函數(shù)首先為platform設(shè)備分配內(nèi)存空間,這里的struct platform_object結(jié)構(gòu)是struct platform _device結(jié)構(gòu)的封裝,其定義如下:
struct platform_object {
};
其中第二個(gè)字段name的地址用于存放第一個(gè)字段pdev的name指針上的內(nèi)容,函數(shù)中的代碼說(shuō)明了這點(diǎn):
接著用輸入?yún)?shù)id初始化platform_device的id字段,這個(gè)id是在設(shè)置代表它的kobject時(shí)會(huì)用到的,我們將在后面分析到,如果不用它,則設(shè)為-1。
接著調(diào)用device_initialize()初始化platform_device內(nèi)嵌的device,并設(shè)置其release函數(shù)指針。
platform_device_alloc()函數(shù)分析完了。
接著我們看看platform_device_add()函數(shù):
int platform_device_add(struct platform_device *pdev)
{
設(shè)置父節(jié)點(diǎn)和總線,這里的platform_bus和platform_bus_type在上面的初始化部分已經(jīng)分析。
設(shè)置pdev->dev內(nèi)嵌的kobj的name字段,它是pdev->name指向的內(nèi)容加上id,如果id為-1則忽略它,關(guān)于dev_set_name()函數(shù)已經(jīng)在分析設(shè)備驅(qū)動(dòng)模型時(shí)分析過(guò),這里不再累贅。
初始化資源并將資源分配給它,每個(gè)資源的它的parent不存在則根據(jù)flags域設(shè)置parent,flags為IORESOURCE_MEM,則所表示的資源為I/O映射內(nèi)存,flags為IORESOURCE_IO,則所表示的資源為I/O端口。
就在這里把設(shè)備注冊(cè)到總線上,如果你對(duì)device_add()函數(shù)不熟悉,請(qǐng)參考本站的設(shè)別模型分析部分內(nèi)容。
除錯(cuò)撤銷的內(nèi)容。
}
platform_device_add()函數(shù)分析完了,我們看下platform_device_register()函數(shù):
int platform_device_register(struct platform_device *pdev)
{
}
沒(méi)錯(cuò)它就是初始化pdev->dev后調(diào)用platform_device_add()把它注冊(cè)到platform_bus_type上。
在看看platform_device_register_simple()函數(shù):
struct platform_device *platform_device_register_simple(const char *name,
{
error:
}
該函數(shù)就是調(diào)用了platform_device_alloc()和platform_device_add()函數(shù)來(lái)創(chuàng)建的注冊(cè)platform device,函數(shù)也根據(jù)res參數(shù)分配資源,看看platform_device_add_resources()函數(shù):
int platform_device_add_resources(struct platform_device *pdev,
{
}
很簡(jiǎn)單,為資源分配內(nèi)存空間,并拷貝參數(shù)res中的內(nèi)容,鏈接到device并設(shè)置其num_resources。
三.Platform設(shè)備的注冊(cè)
我們?cè)谠O(shè)備驅(qū)動(dòng)模型的分析中已經(jīng)知道驅(qū)動(dòng)在注冊(cè)要調(diào)用driver_register(),platform driver的注冊(cè)函數(shù)platform_driver_register()同樣也是進(jìn)行其它的一些初始化后調(diào)用driver_register()將驅(qū)動(dòng)注冊(cè)到platform_bus_type總線上,看一下這個(gè)函數(shù):
int platform_driver_register(struct platform_driver *drv)
{
}
這里我們要先看看struct platform_driver結(jié)構(gòu):
struct platform_driver {
};
上面的函數(shù)指定了內(nèi)嵌的driver的bus字段為platform_bus_type,即為它將要注冊(cè)到的總線。
然后設(shè)定了platform_driver內(nèi)嵌的driver的probe、remove、shutdown函數(shù)。
看下相應(yīng)的這三個(gè)函數(shù):
static int platform_drv_probe(struct device *_dev)
{
}
static int platform_drv_remove(struct device *_dev)
{
}
static void platform_drv_shutdown(struct device *_dev)
{
}
從這三個(gè)函數(shù)的代碼可以看到,又找到了相應(yīng)的platform_driver和platform_device,然后調(diào)用platform_driver的probe、remove、shutdown函數(shù)。這是一種高明的做法:在不針對(duì)某個(gè)驅(qū)動(dòng)具體的probe、remove、shutdown指向的函數(shù),而通過(guò)上三個(gè)過(guò)度函數(shù)來(lái)找到platform_driver,然后調(diào)用probe、remove、shutdown接口。
如果設(shè)備和驅(qū)動(dòng)都注冊(cè)了,就可以通過(guò)bus ->match、bus->probe或driver->probe進(jìn)行設(shè)備驅(qū)動(dòng)匹配了,這部分內(nèi)容將留到具體的設(shè)備中再做分析。
在2.6.32.3版本的代碼中,還針對(duì)某些不需要產(chǎn)生hotplug事件的設(shè)備提供設(shè)備驅(qū)動(dòng)的匹配函數(shù)platform_driver_probe(),調(diào)用這個(gè)函數(shù)前首先要注冊(cè)設(shè)備,看一下這個(gè)函數(shù):
int __init_or_module platform_driver_probe(struct platform_driver *drv,
{
}
該函數(shù)先設(shè)置drv的probe為輸入函數(shù),然后將drv注冊(cè)到總線,這個(gè)過(guò)程回去匹配設(shè)備,這時(shí)會(huì)找到調(diào)用這個(gè)函數(shù)前注冊(cè)的設(shè)備,然后將其掛鉤,接著設(shè)置drv->probe為NULL,設(shè)置drv->driver.probe為platform_drv_probe_fail,這樣后面如果產(chǎn)生匹配事件都會(huì)是匹配失敗,也即platform_drv_probe_fail()匹配不成功,其代碼如下:
static int platform_drv_probe_fail(struct device *_dev)
{
}
正如我們分析的一樣。
評(píng)論