plateform總線

系統(tǒng)啟動時初始化時創(chuàng)建了platform_bus設備和platform_bus_type總線：

內核初始化函數(shù)kernel_init()中調用了do_basic_setup()，該函數(shù)中調用driver_init()，該函數(shù)中調用platform_bus_init()，我們看看platform_bus_init()函數(shù)：

int __init platform_bus_init(void)

{

int error;

early_platform_cleanup();

error = device_register(&platform_bus);

if (error)

return error;

error =bus_register(&platform_bus_type);

if (error)

device_unregister(&platform_bus);

return error;

}

device_register(&platform_bus)中的platform_bus如下：

struct device platform_bus = {

.init_name= "platform",

};

改函數(shù)把設備名為platform的設備platform_bus注冊到系統(tǒng)中，其他的platform的設備都會以它為parent。它在sysfs中目錄下.即/sys/devices/platform。

接著bus_register(&platform_bus_type)注冊了platform_bus_type總線，看一下改總線的定義：

struct bus_type platform_bus_type = {

.name= "platform",

.dev_attrs= platform_dev_attrs,

.match= platform_match,

.uevent= platform_uevent,

.pm= &platform_dev_pm_ops,

};

默認platform_bus_type中沒有定義probe函數(shù)。

我們分析一下其中platform_match和platform_uevent函數(shù)。在分析設備驅動模型是已經知道總線類型match函數(shù)是在設備匹配驅動時調用，uevent函數(shù)在產生事件時調用。

platform_match（）代碼如下：

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);

if (pdrv->id_table)

return platform_match_id(pdrv->id_table, pdev) != NULL;

return (strcmp(pdev->name, drv->name) == 0);

}

static const struct platform_device_id *platform_match_id(

struct platform_device_id *id,

struct platform_device *pdev)

{

while (id->name[0]) {

if (strcmp(pdev->name, id->name) == 0) {

pdev->id_entry = id;

return id;

}

id++;

}

return NULL;

}

不難看出，如果pdrv的id_table數(shù)組中包含了pdev->name，或者drv->name和pdev->name名字相同，都會認為是匹配成功。id_table數(shù)組是為了應對那些對應設備和驅動的drv->name和pdev->name名字不同的情況。

再看看platform_uevent（）函數(shù)：

static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)

{

struct platform_device*pdev = to_platform_device(dev);

add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,

(pdev->id_entry) ? pdev->id_entry->name : pdev->name);

return 0;

}

添加了MODALIAS環(huán)境變量，我們回顧一下：platform_bus. parent->kobj->kset->uevent_ops為device_uevent_ops，bus_uevent_ops的定義如下：

static struct kset_uevent_ops device_uevent_ops = {

.filter =dev_uevent_filter,

.name =dev_uevent_name,

.uevent = dev_uevent,

};

當調用device_add()時會調用kobject_uevent(&dev->kobj, KOBJ_ADD)產生一個事件，這個函數(shù)中會調用相應的kset_uevent_ops的uevent函數(shù)，這里即為dev_uevent()，我們看一下這個函數(shù)的代碼片段：

static int dev_uevent(struct kset *kset, struct kobject *kobj,

struct kobj_uevent_env *env)

{

.

.

.

if (dev->bus && dev->bus->uevent) {

retval = dev->bus->uevent(dev, env);

if (retval)

pr_debug("device: %s: %s: bus uevent() returned %d",

dev_name(dev), __func__, retval);

}

.

.

.

}

從這里看到如果bus->uevent()函數(shù)存在則會調用它。

到這里我們清楚了platform_uevent會在哪里調用了。

二．Platform設備的注冊

我們在設備模型的分析中知道了把設備添加到系統(tǒng)要調用device_initialize()和platform_device_add(pdev)函數(shù)。

對于platform設備的初始化，內核源碼也提供了platform_device_alloc()函數(shù)。

對于platform設備的初注冊，內核源碼提供了platform_device_add()函數(shù)，它是進行一系列的操作后調用device_add()將設備注冊到相應的總線上，內核代碼中platform設備的其他注冊函數(shù)都是基于這個函數(shù)，如platform_device_register()、platform_device_register_simple()、platform_device_register_data()等。

我們對這些函數(shù)逐個分析，首先看看初始化函數(shù)platform_device_alloc()：

struct platform_device * platform_device_alloc(const char *name, int id)

{

struct platform_object *pa;

pa = kzalloc(sizeof(struct platform_object) + strlen(name), GFP_KERNEL);

if (pa) {

strcpy(pa->name, name);

pa->pdev.name = pa->name;

pa->pdev.id = id;

device_initialize(&pa->pdev.dev);

pa->pdev.dev.release = platform_device_release;

}

return pa ? &pa->pdev : NULL;

}

該函數(shù)首先為platform設備分配內存空間，這里的struct platform_object結構是struct platform _device結構的封裝，其定義如下：

struct platform_object {

struct platform_device pdev;

char name[1];

};

其中第二個字段name的地址用于存放第一個字段pdev的name指針上的內容，函數(shù)中的代碼說明了這點：

strcpy(pa->name, name);

pa->pdev.name = pa->name;

接著用輸入?yún)?shù)id初始化platform_device的id字段，這個id是在設置代表它的kobject時會用到的，我們將在后面分析到，如果不用它，則設為-1。

接著調用device_initialize()初始化platform_device內嵌的device，并設置其release函數(shù)指針。

platform_device_alloc()函數(shù)分析完了。

接著我們看看platform_device_add()函數(shù)：

int platform_device_add(struct platform_device *pdev)

{

int i, ret = 0;

if (!pdev)

return -EINVAL;

if (!pdev->dev.parent)

pdev->dev.parent = & platform_bus;

pdev->dev.bus = &platform_bus_type;

設置父節(jié)點和總線，這里的platform_bus和platform_bus_type在上面的初始化部分已經分析。

if (pdev->id != -1)

dev_set_name(&pdev->dev, "%s.%d", pdev->name,pdev->id);

else

dev_set_name(&pdev->dev, "%s", pdev->name);

設置pdev->dev內嵌的kobj的name字段，它是pdev->name指向的內容加上id，如果id為-1則忽略它，關于dev_set_name()函數(shù)已經在分析設備驅動模型時分析過，這里不再累贅。

for (i = 0; i < pdev->num_resources; i++) {

struct resource *p, *r = &pdev->resource[i];

if (r->name == NULL)

r->name = dev_name(&pdev->dev);

p = r->parent;

if (!p) {

if (resource_type(r) == IORESOURCE_MEM)

p = &iomem_resource;

else if (resource_type(r) == IORESOURCE_IO)

p = &ioport_resource;

}

if (p && insert_resource(p, r)) {

printk(KERN_ERR

"%s: failed to claim resource %d",

dev_name(&pdev->dev), i);

ret = -EBUSY;

goto failed;

}

}

初始化資源并將資源分配給它，每個資源的它的parent不存在則根據(jù)flags域設置parent，flags為IORESOURCE_MEM，則所表示的資源為I/O映射內存，flags為IORESOURCE_IO，則所表示的資源為I/O端口。

pr_debug("Registering platform device %s. Parent at %s",

dev_name(&pdev->dev), dev_name(pdev->dev.parent));

ret = device_add(&pdev->dev);

就在這里把設備注冊到總線上，如果你對device_add()函數(shù)不熟悉，請參考本站的設別模型分析部分內容。

if (ret == 0)

return ret;

failed:

while (--i >= 0) {

struct resource *r = &pdev->resource[i];

unsigned long type = resource_type(r);

if (type == IORESOURCE_MEM || type == IORESOURCE_IO)

release_resource(r);

}

除錯撤銷的內容。

return ret;

}

platform_device_add()函數(shù)分析完了，我們看下platform_device_register()函數(shù)：

int platform_device_register(struct platform_device *pdev)

{

device_initialize(&pdev->dev);

return platform_device_add(pdev);

}

沒錯它就是初始化pdev->dev后調用platform_device_add()把它注冊到platform_bus_type上。

在看看platform_device_register_simple()函數(shù)：

struct platform_device *platform_device_register_simple(const char *name,

int id,

struct resource *res,

unsigned int num)

{

struct platform_device *pdev;

int retval;

pdev = platform_device_alloc(name, id);

if (!pdev) {

retval = -ENOMEM;

goto error;

}

if (num) {

retval = platform_device_add_resources(pdev, res, num);

if (retval)

goto error;

}

retval = platform_device_add(pdev);

if (retval)

goto error;

return pdev;

error:

platform_device_put(pdev);

return ERR_PTR(retval);

}

該函數(shù)就是調用了platform_device_alloc()和platform_device_add()函數(shù)來創(chuàng)建的注冊platform device，函數(shù)也根據(jù)res參數(shù)分配資源，看看platform_device_add_resources()函數(shù)：

int platform_device_add_resources(struct platform_device *pdev,

struct resource *res, unsigned int num)

{

struct resource *r;

r = kmalloc(sizeof(struct resource) * num, GFP_KERNEL);

if (r) {

memcpy(r, res, sizeof(struct resource) * num);

pdev->resource = r;

pdev-> num_resources = num;

}

return r ? 0 : -ENOMEM;

}

很簡單，為資源分配內存空間，并拷貝參數(shù)res中的內容，鏈接到device并設置其num_resources。

三．Platform設備的注冊

我們在設備驅動模型的分析中已經知道驅動在注冊要調用driver_register()，platform driver的注冊函數(shù)platform_driver_register()同樣也是進行其它的一些初始化后調用driver_register()將驅動注冊到platform_bus_type總線上，看一下這個函數(shù)：

int platform_driver_register(struct platform_driver *drv)

{

drv->driver.bus = &platform_bus_type;

if (drv->probe)

drv-> driver.probe = platform_drv_probe;

if (drv->remove)

drv->driver.remove = platform_drv_remove;

if (drv->shutdown)

drv->driver.shutdown = platform_drv_shutdown;

return driver_register(&drv->driver);

}

這里我們要先看看struct platform_driver結構：

struct platform_driver {

int (*probe)(struct platform_device *);

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;

struct platform_device_id *id_table;

};

上面的函數(shù)指定了內嵌的driver的bus字段為platform_bus_type，即為它將要注冊到的總線。

然后設定了platform_driver內嵌的driver的probe、remove、shutdown函數(shù)。

看下相應的這三個函數(shù)：

static int platform_drv_probe(struct device *_dev)

{

struct platform_driver *drv = to_platform_driver(_dev->driver);

struct platform_device *dev = to_platform_device(_dev);

return drv->probe(dev);

}

static int platform_drv_remove(struct device *_dev)

{

struct platform_driver *drv = to_platform_driver(_dev->driver);

struct platform_device *dev = to_platform_device(_dev);

return drv->remove(dev);

}

static void platform_drv_shutdown(struct device *_dev)

{

struct platform_driver *drv = to_platform_driver(_dev->driver);

struct platform_device *dev = to_platform_device(_dev);

drv->shutdown(dev);

}

從這三個函數(shù)的代碼可以看到，又找到了相應的platform_driver和platform_device，然后調用platform_driver的probe、remove、shutdown函數(shù)。這是一種高明的做法：在不針對某個驅動具體的probe、remove、shutdown指向的函數(shù)，而通過上三個過度函數(shù)來找到platform_driver，然后調用probe、remove、shutdown接口。

如果設備和驅動都注冊了，就可以通過bus ->match、bus->probe或driver->probe進行設備驅動匹配了，這部分內容將留到具體的設備中再做分析。

在2.6.32.3版本的代碼中，還針對某些不需要產生hotplug事件的設備提供設備驅動的匹配函數(shù)platform_driver_probe()，調用這個函數(shù)前首先要注冊設備，看一下這個函數(shù)：

int __init_or_module platform_driver_probe(struct platform_driver *drv,

int (*probe)(struct platform_device *))

{

int retval, code;

drv->driver.suppress_bind_attrs = true;

drv-> probe = probe;

retval = code = platform_driver_register(drv);

spin_lock(&platform_bus_type.p->klist_drivers.k_lock);

drv->probe = NULL;

if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))

retval = -ENODEV;

drv->driver.probe = platform_drv_probe_fail;

spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);

if (code != retval)

platform_driver_unregister(drv);

return retval;

}

該函數(shù)先設置drv的probe為輸入函數(shù)，然后將drv注冊到總線，這個過程回去匹配設備，這時會找到調用這個函數(shù)前注冊的設備，然后將其掛鉤，接著設置drv->probe為NULL，設置drv->driver.probe為platform_drv_probe_fail，這樣后面如果產生匹配事件都會是匹配失敗，也即platform_drv_probe_fail（）匹配不成功，其代碼如下：

static int platform_drv_probe_fail(struct device *_dev)

{

return -ENXIO;

}

正如我們分析的一樣。