1 I2C、 SPI、 USB驱动架构
根据图12.4， Linux倾向于将主机端的驱动与外设端的驱动分离，而通过一个核心层将某种总线的协议进行抽象，外设端的驱动调用核心层API间接过渡到对主机驱动传输函数的调用。对于I2C、 SPI这类不具备热插拔能力的总线而言，一般在arch/arm/mach-xxx或者arch/arm/boot/dts中会有相应的板级描述信息，描述外设与主机的连接情况。Linux的各个子系统都呈现为相同的特点，表17.1类比了
I2C、 SPI、 USB驱动架构，其他的PCI等都是类似的。
表17.1 I2C、 SPI、 USB驱动架构的类比
对于USB、 PCI等总线而言，由于它们具备热插拔能力，所以实际上不存在类似I2C、 SPI这样的板级描述信息。换句话说，即便是有这类信息，其实也没有什么用，因为如果写了板子上有个U盘，但实际上没有，其实反而是制造了麻烦；相反，如果没有写， U盘一旦插入， Linux USB子系统会自动探测到一个U盘。
同时我们注意到， I2C、 SPI、 USB控制器虽然给别人提供了总线，但是其实自己也是由它自身依附的总线枚举出来的。比如，对于SoC而言，这些控制器一般是直接集成在芯片内部，通过内存访问指令来访问的，因此它们自身是通过platform_driver、 platform_device这种模型枚举进来的
2 I2C主机和外设眼里的Linux世界
I2C控制器所在驱动的platform_driver与arch/arm/mach-xxx中的platform_device（或者设备树中的节点）通过platform总线的match（）函数匹配导致platform_driver.probe（）执行，从而完成I2C控制器的注册；而I2C上面挂的触摸屏依附的i2c_driver与arch/arm/mach-xxx中的i2c_board_info指向的设备（或者设备树中的节点）通过I2C总线的match（）函数匹配导致i2c_driver.probe（）执行，从而使触摸屏展开。
图17.1虚线上方部分是i2c_adapater眼里的Linux世界；下方部分是i2c_client眼里的Linux世界。其实， Linux中的每一个设备通过它依附的总线被枚举出来，尽管它自身可能给别人提供总线。
