简单对 usb 架构的部分内容进行记录。内容杂乱，有待整理。

以一个内核版本的内容来简要说明下 usb 结构中相关的内容：

#ls linux-2.6.32/drivers/usb
atm     class  early   host   Kconfig   misc  musb  README  storage         wusbcore
c67x00  core   gadget  image  Makefile  mon   otg   serial  usb-skeleton.c
这里，有几个关键的目录：
core
host
gadget
class
...

core

这个目录存放一些核心的代码，比如初始化整个 usb 系统，初始化root hub，初始化host controller的代码等等，随着时间的发
展，这个目录以及 usb 父目录的其他内容，会被存放到不同的更为合适的地方。

host

这个目录存放主机 host controller 驱动相关内容。所谓 =host controller 就是控制 usb 设备的硬件，而主机的各个 usb 设备，又有它们
自己的驱动。 host 目录下的内容，例如： ehci-pci.c 用于该 host controller 是在基于 ehci 的 pci 上面的 usb hostcontroller ，其它的类似，还有基于某个 cpu 的 usb host controller 。反正，就是看成把硬件 host controller 挂接到它所基于的那个上面，然后又通过这个 host controller 来控制其上的 usb 设备。

class

这个目录存放关于某个类的 usb 设备信息，例如通信类，等等。

gadget

这个目录信息比较多。

假设我们将一个本身运行linux系统的嵌入式板子插入到 pc 上面，通过 pc 访问插入到这个板子上面的某>个 usb 设备（例如 sd 卡）。那么，

首先 pc 的 host controller 将这个板子识别成为某种类型的设备，所以相关驱动代码大致在 pc 端的内核的与 host 目录同级的其它驱动目录上（例如 storage 对应的是海量存储类）。

其次，插入到板子上面的 usb 设备（例如 sd 卡）被这个板子的host controller识别成 usb 设备(对应的驱动大致在板子端的内核的与 host 目录同级的其它驱动目录上（例如 storage 对应的是海量存储类)。

然后，板子上又告诉它自己它被当做 pc 的 usb 设备来使用(对应的驱动大致在板子端的内核的 gadget 中的** udc 驱动或者类似文件中的代码部分，)。

然后板子又根据插入到板子上面的 usb 设备，让 pc 能够将这个板子识别成可以访问板子上面 usb 设备的设备（对应的驱动大致在板子端的内核的 gadget 中的其它 gadget 的文件中的代码部分）。

描述的并不是特别精确，但是这是大致的框架结构。

总之上面的那种情况，需要的驱动代码分别在 pc 和板子，对于 pc 上面，我们一般不会关心，主要是板子上面，三个地方比较关键：

1. 将板子可以做为 usb 设备的部分( gadget 目录中的 udc 驱动部分)
2. 将板子识别成什么设备类型的部分（例如板子插入 sd 卡那么 pc 将板子识别成 sd 卡，插入到板子上的 usb 设备驱动和 pc 联接得通过它）
3. 插入板子上的 usb 设备的驱动部分（以便板子识别它自己身>上的 usb 设备，就像 pc 识别板子一样为 usb 设备一样）。

注意，这里板子和 pc 运行的两套系统。

其他

其他目录就存放 host controller 所控制的各种 usb 设备驱动类。例如 storage 存放的就是海量存储类（ u 盘）设备的驱动等等。

另外，并不是所有的 usb 设备驱动都在这个 drivers/usb 目录下面，其它地方也有，例如 linux-2.6.32/sound/usb 。