与前文提到的usb、IIC、PCI总线不同，platform总线是一种虚拟抽象的总线，不存在物理层面上的一个名为platform的总线。
cup与外部设备通信有两种方法，地址总线或接口（32位范围是0~2^32-1）；专用接口连接（如usb、Nand一类专用的总线）。
地址总线不对应某一特定设备与连接方法，都挂载在地址总线是，所以这一类设备连接方法可归并为平台总线platform。
为什么要设计平台总线？因为挂载在cpu的地址上的设备没有特定的总线，但是为了好区分，所以把这一类直接焊接在地址线上的设备归为platform。
platform与其他真实的bus管理方法如出一辙。
platform_device//设备结构体
platform_driver//驱动结构体
platform_device_register//设备注册
platform_driver_register//驱动注册
struct platform_device {
const char * name;//名字
int id;//ID
struct device dev;//驱动框架 驱动抽象
u32 num_resources;//设备用到的资源数
struct resource * resource;//设备用到的资源数组首地址
const struct platform_device_id *id_entry;//设备id表
/* arch specific additions */
struct pdev_archdata archdata;//架构自留地，专用数据相关设备，用于扩展
};
struct platform_driver {
int (*probe)(struct platform_device *);//驱动探测函数（一种初始化方法）init
int (*remove)(struct platform_device *);//删除设备的方法remove
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表（支持什么设备）
};
platform的工作流程：①系统启动时在bus系统中注册platform /sys/bus platform_bus_init；②内核移植人负责提供platform_device；③写驱动的人负责提供platform_driver；④pathform的match函数发现driver和device匹配后，调用driver的probe函数（探测）完成init后开始工作。
每种总线都有一个match方法，用于匹配device和driver，每种总线的匹配方法不同，但一般以名字进行匹配。
PS：可用container_of()宏进行结构体反推结构体头指针。
match函数中对id_table与name相对比（方法①对比其中所有的name），进行驱动与设备的对比（方法②对比驱动名与设备名）。id_table可能存在统一给驱动支持多个设备的情况，这是正常的，因为就是这么使用的。
void *platform_data是一个支持自行添加的一个属性，一般会去写一个结构体，做特有数据。
platdata是提供设备注册时用到的一些资源申请（如gpio、中断、名称等），这些数据在match匹配后，由设备方转驱动方，得知设备具体信息，从而操作设备，让驱动有移植性，驱动只能携带操作方法，操作的数据由设备方提供。算法与数据分离，单独驱动不再能工作，保证驱动独立性与适应性，在probe中交接。
device platform_data（内核中 sys/platform/device/）=>driver platform_data（这部分也可放到内核中，也可编为模块）。
gpio_request(pdata->gpio,pdata->name);进行gpio申请，达到同一驱动不同数据，反复使用。
驱动中使用struct 时怕v10_led_platdata *pdata=dev->dev.platform_data;传输不同数据。
LED驱动框架+platform框架可实现高度的复用性。