本还想详细分析代码，但发现，这张图已经足够说明i2c驱动的注册过程了，下面对我看代码时碰到的一些问题简要分析。
设备和驱动的关联
大家知道，对于一个驱动程序有两个元素不可或缺，即设备和驱动，一般驱动都是通过设备名和驱动名的匹配建立关系的，我从i2c/chips/里看到的示例代码了只能发现驱动的注册，却不见设备注册的踪影，令人疑惑，跟踪发现，在i2c adapter注册时会遍历i2c_board_info这样一个结构，而这个结构在29以前或更早的内核里是不存在的，该数据结构在board-msm7x27.c中初始化了i2c设备名及设备地址，这便解决了驱动与设备的匹配问题，同时器件地址的提供也有所改变，旧的内核是在驱动中使用一个normal_i2c数组保存地址的。
名字匹配
一个i2c驱动是可以有多个名字的，即一个驱动程序可以支持多个设备，该机制是通过 struct i2c_device_id实现的，驱动中建立这么一个结构体数组，i2c架构层便会扫描该数组，与设备名去匹配，匹配成功的都会进入相应probe函数。
进入probe
该过程困惑了我一段时间，其实要进入自己驱动的probe首先需要进入总线的probe，而进入总线probe的前提是与总线的match成功，具体实现大家可以根据上面的图看一下相应代码便知。
设备模型
I2C的架构充分利用的设备模型的原理及sysfs的实现，我认为理解i2C架构前先了解一下设备模型是很有必要的。这里将我的个人理解总结一下：
Kobject是设备模型的最小单位，kset是对kobject的集合，struct driver_private、struct device等结构都内嵌了kobject，kset也内嵌kobject用于表征自己。相同特性的kset的合集又构成了subsys，举个不太恰当的类比：
kobject之于设备或驱动；kset之于某一类设备，如i2c；subsys之于子系统，如输入子系统。其实在29内核中subsys就是一个kset结构，贴两张图理解一下：
