Platform Device and Drivers
从<linux/platform_device.h>我们可以了解Platform bus上面的驱动模型接口：platform_device，platform_driver。和PCI和USB这些大结构的总线不同，虚拟总线 Platform bus使用最小结构来集成SOC processer上的各种外设，或者各种“legacy”之间的互联。
Platform device
典型的Platform device是系统中的各种自主设备，包括各种桥接在外围总线上的port-based device和host，以及各种集成在SOC platform上的控制器。他们都有一个特点，那就是CPU BUS可以直接寻址，或者特殊的情况platform_device连接在其他总线上，但是它的寄存器是可以被直接寻址的。
Platform device有一个名字，用来进行driver的绑定；还有诸如中断，地址之类的一些资源列表
struct platform_device {
const char *name;
u32 id;
struct device dev;
u32 num_resources;
struct resource *resource;
};
Platform drivers
Platform driver满足标准driver model，对driver的discovery/enumeration是在driver外部进行的，driver提供了probe()和 remove()方法.Platfomr dirvers通过标准模型提供power management和shutdown通知。
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 (*suspend_late)(struct platform_device *, pm_message_t state);
int (*resume_early)(struct platform_device *);
int (*resume)(struct platform_device *);
struct device_driver driver;
};
Probe()函数必须验证指定设备的硬件是否真的存在，probe()可以使用设备的资源，包括时钟，platform_data等，Platform driver可以通过下面的函数完成对驱动的注册：
int platform_driver_register(struct platform_driver *drv);
一般来说设备是不能被热插拔的，所以可以将probe()函数放在init段里面来节省driver运行时候的内存开销：
int platform_driver_probe(struct platform_driver *drv,
int (*probe)(struct platform_device *))
Device Enumeration
作为一个规则，平台(一般来说是板级)启动代码会注册所有的Platform device：
int platform_device_register(struct platform_device *pdev);
int platform_add_devices(struct platform_device **pdevs, int ndev);
一般来说只会注册那些实际存在的设备，不过也存在特殊的情况，比如kernel可能需要与一个不在板子上的外部网络适配器工作，或者那些不挂在任何总线上的控制器。
一般情况下，固件启动的过程会输出一个描述板子上所有存在设备的表。如果没有这个表，系统启动代码建立正确的设备的唯一方法就是为一个特定的板子编译一个kernel。这种board-specific kernel广泛用在嵌入式和一般系统的开发上。
在大部分情况下，设备的memory和IRQ资源不足够让驱动正常工作。board setup code会用device的platform_data域来为设备提供一些额外的资源。
嵌入式系统上的设备会频繁地使用一个或者多个时钟，这些时钟因为节电的原因只有在真正使用的时候才会被打开，系统在启动过程中会为设备分配时钟，可以通过clk_get(&pdev->dev, clock_name)来获得需要的时钟。
Legacy Drivers ： Device Probing
一些driver并不会完全遵守标准driver model，这些driver会去注册自己的platform device，而不是让系统来完成注册。这是不值得推
荐的，主要用来兼容以前的一些旧设备。可以通过下面的API来支持这些legacy driver，一般这些API使用在不支持热插拔的driver上面：
struct platform_device *platform_device_alloc(
const char *name, int id);
可以使用platform_device_alloc动态地创建一个设备，一个更好的方法是，通过下面的函数动态创建一个设备，并把这个设备注册到系统中：
struct platform_device *platform_device_register_simple(
const char *name, int id,
struct resource *res, unsigned int nres);
Device Naming and Driver Binding
platform_device.dev.bus_id是一个设备在总线上的名字，它包含两部分：
＊ platform_device.name 设备名字，用来进行driver的匹配
＊ platform_device.id 设备实例的标号，如果是-1，表示同样名字的设备只有一个
举个简单的例子，name/id是“serial/1”则它的bus_id就是serial.1 如果name/id是“serial/0”则它的bus_id就是serial.0 ,如果它的name/id是“serial/-1”则它的bus_id就是serial。
driver的绑定是通过driver core自动完成的，完成driver和device的匹配后以后会自动执行probe()函数，如果函数执行成功，则driver和device就绑定在一起了，drvier和device匹配的方法有3种：
＊ 当一个设备注册的时候，他会在总线上寻找匹配的driver，platform device一般在系统启动很早的时候就注册了
＊ 当一个驱动注册[platform_driver_register()]的时候，他会遍历所有总线上的设备来寻找匹配，在启动的过程驱动的注册一般比较晚，或者在模块载入的时候
＊ 当一个驱动注册[platform_driver_probe()]的时候， 功能上和使用platform_driver_register()是一样的，唯一的区别是它不能被以后其他的device probe了，也就是说这个driver只能和一个device绑定。
Platform device 和 Platform driver实际上是cpu总线可以直接寻址的设备和驱动，他们挂载在一个虚拟的总线platform_bus_type上，是一种bus- specific设备和驱动。与其他bus-specific驱动比如pci是一样的。他们都是将device和device_driver加了一个 warpper产生，仔细看看platform_device就可以看到它必然包含一个device dev，而platform_driver也一样，它必然包含一个device_driver
driver。
所有的设备通过bus_id挂在总线上，多个device可以共用一个driver，但是一个device不可以对应多个driver。驱动去注册时候会根据设备名寻找设备，没有设备会注册失败，注册的过程会通过probe来进行相应资源的申请，以及硬件的初始化，如果probe执行成功，则device 和driver的绑定就成功了。设备注册的时候同样会在总线上寻找相应的驱动，如果找到他也会试图绑定，绑定的过程同样是执行probe。
platform_driver_probe — register driver for non-hotpluggable device
int __init_or_module platform_driver_probe (struct platform_driver * drv , int (* probe ( struct platform_device *) ) ;
Arguments：
drv
platform driver structure
probe
the driver probe routine, probably from an __init section
Description
Use this instead of platform_driver_register when you know the device is not hotpluggable and has already been registered, and you want to remove its run-once probe infrastructure from memory after the driver has bound to the device.
One typical use for this would be with drivers for controllers integrated into system-on-chip processors, where the controller devices have been configured as part of board setup.
Returns zero if the driver registered and bound to a device, else returns a negative error code and with the driver not registered.
------------------