Platform總線是kernel中的一種虛擬總線，2.6版本很多驅動都用它來實現。
一．Platform初始化
系統啓動時初始化時創建了platform_bus設備和platform_bus_type總線：
內核初始化函數kernel_init()中調用了do_basic_setup() ，該函數中調用driver_init()，該函數中調用platform_bus_init()，我們看看platform_bus_init()函數：
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",
};
改函數把設備名爲platform 的設備platform_bus註冊到系統中，其他的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函數。
我們分析一下其中platform_match和platform_uevent函數。在分析設備驅動模型是已經知道總線類型match函數是在設備匹配驅動時調用，uevent函數在產生事件時調用。
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);
/* match against the id table first */
if (pdrv->id_table)
return platform_match_id(pdrv->id_table, pdev) != NULL;
/* fall-back to driver name match */
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數組中包含了pdev->name，或者drv->name和pdev->name名字相同，都會認爲是匹配成功。id_table數組是爲了應對那些對應設備和驅動的drv->name和pdev->name名字不同的情況。
再看看platform_uevent（）函數：
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環境變量，我們回顧一下：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)產生一個事件，這個函數中會調用相應的kset_uevent_ops的uevent函數，這裏即爲dev_uevent()，我們看一下這個函數的代碼片段：
static int dev_uevent(struct kset *kset, struct kobject *kobj,
struct kobj_uevent_env *env)
{
.
.
.
/* have the bus specific function add its stuff */
if (dev->bus && dev->bus->uevent) {
retval = dev->bus->uevent(dev, env);
if (retval)
pr_debug("device: '%s': %s: bus uevent() returned %d\n",
dev_name(dev), __func__, retval);
}
.
.
.
}
從這裏看到如果bus->uevent()函數存在則會調用它。
到這裏我們清楚了platform_uevent會在哪裏調用了。
二．Platform設備的註冊
我們在設備模型的分析中知道了把設備添加到系統要調用device_initialize()和platform_device_add(pdev)函數。
對於platform設備的初始化，內核源碼也提供了platform_device_alloc()函數。
對於platform設備的初註冊，內核源碼提供了platform_device_add()函數，它是進行一系列的操作後調用device_add()將設備註冊到相應的總線上，內核代碼中platform設備的其他註冊函數都是基於這個函數，如platform_device_register()、platform_device_register_simple()、platform_device_register_data()等。
我們對這些函數逐個分析，首先看看初始化函數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;
}
該函數首先爲platform設備分配內存空間，這裏的struct platform_object結構是struct platform _device結構的封裝，其定義如下：
struct platform_object {
struct platform_device pdev;
char name[1];
};
其中第二個字段name的地址用於存放第一個字段pdev的name指針上的內容，函數中的代碼說明了這點：
strcpy(pa->name, name);
pa->pdev.name = pa->name;
接着用輸入參數id初始化platform_device的id字段，這個id是在設置代表它的kobject時會用到的，我們將在後面分析到，如果不用它，則設爲-1。
接着調用device_initialize()初始化platform_device內嵌的device，並設置其release函數指針。
platform_device_alloc()函數分析完了。
接着我們看看platform_device_add()函數：
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;
設置父節點和總線，這裏的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()函數已經在分析設備驅動模型時分析過，這裏不再累贅。
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\n",
dev_name(&pdev->dev), i);
ret = -EBUSY;
goto failed;
}
}
初始化資源並將資源分配給它，每個資源的它的parent不存在則根據flags域設置parent，flags爲IORESOURCE_MEM，則所表示的資源爲I/O映射內存，flags爲IORESOURCE_IO，則所表示的資源爲I/O端口。
pr_debug("Registering platform device '%s'. Parent at %s\n",
dev_name(&pdev->dev), dev_name(pdev->dev.parent));
ret = device_add(&pdev->dev);
就在這裏把設備註冊到總線上，如果你對device_add()函數不熟悉，請參考本站的設別模型分析部分內容。
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()函數分析完了，我們看下platform_device_register()函數：
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()函數：
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);
}
該函數就是調用了platform_device_alloc()和platform_device_add()函數來創建的註冊platform device，函數也根據res參數分配資源，看看platform_device_add_resources()函數：
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;
}
很簡單，爲資源分配內存空間，並拷貝參數res中的內容，鏈接到device並設置其num_resources。
三．Platform設備的註冊
我們在設備驅動模型的分析中已經知道驅動在註冊要調用driver_register()，platform driver的註冊函數platform_driver_register()同樣也是進行其它的一些初始化後調用driver_register()將驅動註冊到platform_bus_type總線上，看一下這個函數：
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;
};
上面的函數指定了內嵌的driver的bus字段爲platform_bus_type，即爲它將要註冊到的總線。
然後設定了platform_driver內嵌的driver的probe、remove、shutdown函數。
看下相應的這三個函數：
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);
}
從這三個函數的代碼可以看到，又找到了相應的platform_driver和platform_device，然後調用platform_driver的probe、remove、shutdown函數。這是一種高明的做法：在不針對某個驅動具體的probe、remove、shutdown指向的函數，而通過上三個過度函數來找到platform_driver，然後調用probe、remove、shutdown接口。
如果設備和驅動都註冊了，就可以通過bus ->match、 bus->probe或driver->probe進行設備驅動匹配了，這部分內容將留到具體的設備中再做分析。
在2.6.32.3版本的代碼中，還針對某些不需要產生hotplug事件的設備提供設備驅動的匹配函數platform_driver_probe()，調用這個函數前首先要註冊設備，看一下這個函數：
int __init_or_module platform_driver_probe(struct platform_driver *drv,
int (*probe)(struct platform_device *))
{
int retval, code;
/* make sure driver won't have bind/unbind attributes */
drv->driver.suppress_bind_attrs = true;
/* temporary section violation during probe() */
drv-> probe = probe;
retval = code = platform_driver_register(drv);
/*
* Fixup that section violation, being paranoid about code scanning
* the list of drivers in order to probe new devices. Check to see
* if the probe was successful, and make sure any forced probes of
* new devices fail.
*/
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;
}
該函數先設置drv的probe爲輸入函數，然後將drv註冊到總線，這個過程回去匹配設備，這時會找到調用這個函數前註冊的設備，然後將其掛鉤，接着設置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;
}
正如我們分析的一樣。
到此，Platform總線分析完了，後面其他模塊的分析中將會有platform的例子，有了上面的基礎，到時我們就可以輕鬆的分析了^_^!
