最近调了一些USB驱动，也查看了一些驱动代码，发现不管是I2C,SPI,还是USB驱动，都做了软件分层的处理。 而且软件架构十分雷同，可能就是万变不离其中的一些东西吧。
驱动框架分析
在linux 驱动中，一般会将一个驱动子系统分成三部分，以USB 子系统为例子。
1.最上层的驱动：USB触摸屏驱动，USB键盘驱动，USB鼠标驱动，USB转串口驱动，4G的ttyACM驱动等
对上（应用层）实现文件接口read,write,iotcl的功能
对下（核心层）调用urb相关的函数完成usb传输工作。
2.USB核心层：USB通信的所有套路集中在此层
对上 提供urb相关的函数以供调用工作。
对下 提供一些回调函数接口的注册方法，在下层驱动注册后，以便可调用之。
3.最下层驱动：平台相关的控制器驱动，如IMX6，x86，am335平台的USB控制器驱动，完成与硬件寄存器的配置工作。
对上 （核心层） 提出底层usb通信相关的回调接口。
对下 （硬件） 完成相关寄存器的配置工作，以督促硬件正常工作。
为什么要分三层
有同学要问了，为啥要分三层呢，是为了装逼吗，哈哈，其实原因很简单。
场景1
假设我现在要为一款新的USB鼠标设备写驱动，那么我要完成以上三层所有的功能，而且它只能在一个平台上（如IMX6）用。
老板不同意了，说我的驱动只能在IMX6上用，那am335平台呢，那x86平台呢，求我再写几个驱动，满足所有平台上的都有驱动能用。
这个设备万一有十个平台要用，那我不是要写10个驱动来满足要求？这样我是不是会疯掉呢:-)
这时候，我就会想如果软件分层了，我就可以只写一个驱动满足所有的要求
这个USB鼠标的驱动其实只用完成最上层的驱动的工作，完了通知USB核心，我要与底层通信了，USB核心会自动去匹配我所用平台的最下层控制器驱动，我不用操心那些最下层的驱动去操作寄存器的细节了。
这样，我的驱动就可以做到平台无关，以不变应万变，而且工作量会大大减少，哈哈，这样是不是很爽？
而且usb核心层面已经集成USB通信的协议套路，已经有大牛写好了，我也不用关心USB通信协议的细节，这样开发难度是不是降低了少呢。
软件分层思想，大大提高了软件代码的复用性，是一举多得的美差呀。
以上仅为个人理解，如有不妥，欢迎拍砖，请多指教！