/drivers/usb/gadget/arcotg_udc.c (refer to freescale iMX31 datasheet)
module_init, module_exit注册和注销模块就不多说了。
从platform driver说起：
static struct platform_driver udc_driver = {
.probe = arcotg_udc_probe,
.remove = __exit_p(arcotg_udc_remove),
.driver = {
.name = driver_name,
},
};
platform driver遵循linux系统的driver model,原理是很大的一块，可以参考相关资料。这里只说USB。这里只填了probe和remove两个函数，remove还不易定有（__exit_p就是不一定有的意思）。
static int __init arcotg_udc_probe(struct platform_device *pdev)
具体代码参考原文件。
先初始化平台相关设备
if (board_init(&pdev->dev) != 0)
return -EINVAL;
在board_init中得到配置指针，config = (struct arc_usb_config *)dev->platform_data;
if (config->platform_init() != 0)
return -EINVAL;
初始化平台。具体干的事情就是注释的那样：check the clock, grab/config pins, etc.
在具体呢，可以去arch\arm\mach*下去找相关的平台设备，根据开发板的不同，这个肯定是各有千秋了，但做的事情逃不过check the clock, grab/config pins, etc。
/* Initialize the udc structure including QH member and other member */
udc_controller = (struct arcotg_udc *)struct_udc_setup(pdev);
初始化一些控制用的资源，就是开辟写队列空间，DMA空间之类的。
udc_controller->transceiver = otg_get_transceiver();
我们假设用OTG那么上面这个函数得到了OTG传输相关的数据结构。
Probe中还要得到resource，做io地址映射，以便访问寄存器，得到中断号，申请中断。
tmp_status = request_irq(pdev->resource[1].start, arcotg_udc_irq,
SA_SHIRQ, driver_name, udc_controller);
这里申请的中断处理函数是arcotg_udc_irq，这是这个驱动的核心，该USB device驱动的正常工作都围绕它展开。
dr_controller_setup
这个函数得参考以下iMX31的文档了，都是与寄存器相关的设置。
ep0_dr_and_qh_setup
struct_ep_setup
初始化各个端点，准备传输用的空间，联表，同样需要参考芯片的datasheet。
所有的释放，注销相关的函数不做介绍了，这是常识吗，不用的东西当然要还给系统了。
继续往上看，如果调试相关的也略过。那么就该：
/*----------------------------------------------------------------*
* tell the controller driver about gadget layer driver
* The driver's bind function will be called to bind it to a gadget.
* @driver: for example fsg_driver from file_storage.c
*----------------------------------------------------------------*/
int usb_gadget_register_driver(struct usb_gadget_driver *driver)
注释的很清楚，usb设备最终会映射成一个具体的设备，那么互通有无的函数就是它了。这里以mass storage为例，那么该函数会被/drivers/usb/gadget/file_storage.c调用。
先看看这个模块的kconfig和makefile:
config USB_FILE_STORAGE
tristate "File-backed Storage Gadget"
help
The File-backed Storage Gadget acts as a USB Mass Storage
disk drive. As its storage repository it can use a regular
file or a block device (in much the same way as the "loop"
device driver), specified as a module parameter.
Say "y" to link the driver statically, or "m" to build a
dynamically linked module called "g_file_storage".
Makefile:
g_file_storage-objs := file_storage.o usbstring.o config.o \
epautoconf.o
obj-$(CONFIG_USB_FILE_STORAGE) += g_file_storage.o
这说明这个模块由file_storage.c，usbstring.c， config.c， epautoconf.c，编译连接而成，当然主要是file_storage.c，模块的初始化同样是分配了模块重要数据结构的空间，然后就调用了usb_gadget_register_driver。并传了一个初始化相关的数据结构。
现在看看这个函数：
先锁起来，防止别人改写udc_controller->driver。
spin_lock_irqsave(&udc_controller->lock, flags);
获得传入的数据结构后调用retval = driver->bind(&udc_controller->gadget);
调用的就是file_storage.c中的static int __init fsg_bind(struct usb_gadget *gadget)
说句题外话，这个驱动结构个人感觉不好，bind这个词就决定了它就绑这个设备上了。别的设备以后就别想了。其实完全可以做成开放的，iMX31的endpoint多的是，可以同时绑多个设备吗。
言归正传，bind传入的数据结构是物理层的操作函数以及各种信息状态。这样大家互相知己知彼了。下面看bind（）
略过系统相关的初始化直接到该逻辑设备相关的部分。从usb_ep_autoconfig_reset(gadget);开始，复位所有endpoint的配置。
usb_ep_autoconfig(gadget, &fs_bulk_in_desc);
usb_ep_autoconfig(gadget, &fs_bulk_out_desc);
usb_ep_autoconfig(gadget, &fs_intr_in_desc);
配置endpoint.一个BULK in, 一个BULK out ,和一个INT in(测试模式需要配置，一般不用) .
接着填充设备描述符，接口描述符，配置描述符等。
fsg->ep0req = req = usb_ep_alloc_request(fsg->ep0, GFP_KERNEL);
为控制端点分配request空间。这个函数又调回到物理层的arcotg_alloc_request；
接着usb_ep_alloc_buffer为request信息分配buf调用物理层的arcotg_alloc_buffer；
req->complete = ep0_complete;
这是把EP0传输结束需要调用的函数传给物理层，如果你进这个函数看看，发现它又调用物理层的endpoint结束处理函数，而这个物理层驱动还没有这个函数。真是气愤，绕这么大一个圈子，原来啥也没干啊。这就是linux让人气愤的一个地方，太喜欢绕圈子了，以显示写代码人的水平高，而前人设计了这么变态的架构，后人只好跟着绕了，越绕越糊涂。
在往下就是再分配两个大buf为IN endpoint。如果物理层有电源管理函数的话，接着就该打开电源了。
fsg->thread_task = kthread_create(fsg_main_thread, fsg,
"file-storage-gadget");
建一个线程，处理本模块的一切日常事务。fsg_main_thread就是这个模块的核心了。
wake_up_process(fsg->thread_task);叫醒来，开工了，绑定完毕。
回到那个注册函数，下面虽然还有3，4十行，但只干了一件事情，那就是打开设备。无非就是区分一下是否是OTG，如果不是直接打开，如果是先置成DEVICE模式，然后传个挂起，唤醒的函数给OTG。
Arcotg_udc.c再往上看就是物理层的核心了static irqreturn_t arcotg_udc_irq(int irq, void *_udc, struct pt_regs *r)；
一进来先关门上锁，读中断状态寄存器，清中断状态寄存器，看看哪出事了（一般出事了才会进来）。
下面就是一排IF语句，这里注意了，可能同时产生几个中断，所有不用switch，用if可以一次把这些中断都处理了。
物理层的驱动需要时时参考datasheet，又作这个的兄弟如果想详细讨论IMX31的usb可以再联系我专门讨论，这里略过。
if (irq_src & USB_STS_INT)，如果出现这个中断，说明有某一个endpoint收到了数据，或者发送数据完毕了。碰到这种情况，肯定是要区分对待，而且肯定是EP0最重要了。果然：
if (usb_slave_regs->endptsetupstat & cpu_to_le32(EP_SETUP_STATUS_EP0)) {
tripwire_handler(udc, 0,
(u8 *) (&udc->local_setup_buff));
setup_received_irq(udc, &udc->local_setup_buff);
status = IRQ_HANDLED;
}
如果是EP0收到setup包，先copy到local_setup_buff，然后进入setup_received_irq做处理，处理的原则是能本地处理本地处理，实在处理不了上报逻辑层。本地处理就不多说了，无非不过就是USB协议第九章的那些描述符发来发去的，本地处理的是部分的标准设备请求，上报用的函数是：（处理标准设备请求和设备类型请求）
if (udc->driver->setup(&udc->gadget, &udc->local_setup_buff)
这个函数最后调用的是file_storage.c中的static int fsg_setup(struct usb_gadget *gadget,
const struct usb_ctrlrequest *ctrl)；
这里无论哪层处理都把设备请求（request）分成两个类型，标准USB请求和类型请求，其实还有厂商请求，这里没做处理，如果你需要的话要在这里补充，freescale写的驱动不负责，这个地方提都没提。至少应该写行注释吗。
fsg_setup同样把请求分成两类分别交给class_setup_req(fsg, ctrl);和standard_setup_req(fsg, ctrl)处理。
先看设备类型处理函数：又根据设备是bulk only transport还是CBI transport设备分别处理，协议请参考：Universal Serial Bus Mass Storage Class Bulk-Only Transport和Universal Serial Bus Mass Storage Class CBI Transport。
根据协议，如果在bulk-only的情况下，有两个设备类型请求符：0xff，0xfe，分别是复位mass storage设备和相关接口，获得最大的逻辑块号；如果是CBI，则需要支持0x00这个设备请求描述符。
standard_setup_req：处理一些需要逻辑层处理的描述符，具体每个描述符的意思请参考USB协议的第九章。
都处理完了，需要返回的结果通过rc = ep0_queue(fsg)排在队列里，等待发给HOST。这个函数最终又调用了物理层的arcotg_ep_queue(struct usb_ep *_ep, struct usb_request *_req, gfp_t gfp_flags)。该函数的实现与芯片的usb实现是精密相关的，这里不作详细分析了，它作的事情就是如果有需要发送的包就排在该endpiont的队列里，接收的endpiont则准备一个接收队列，随时可以收到数据。
终于可以回到中断处理函数往下说了，该下面这个了：
/* completion of dtd */
if (usb_slave_regs->endptcomplete) {
dtd_complete_irq(udc);
status = IRQ_HANDLED;
}
从解释可以看出这个中断说明有事请做完了，进dtd_complete_irq看看，先通过分析寄存器得到是哪个EP做完了接收还是发送的任务，根据相应的原则处理一下（参考芯片datasheet），
其中EP0比较特殊，得特别对待一下，专门搞一个ep0_req_complete处理，里面就是碰到了地址改变就设置一下，状态改变记录一下。最后需要调用一个done函数。里面值得一提的是调用了 /* this complete() should a func implemented by gadget layer,
* eg fsg->bulk_in_complete() */
if (req->req.complete) {
VDBG("calling gadget's complete() req=0x%p", req);
req->req.complete(&ep->ep, &req->req);
VDBG("back from gadget's complete()");
}
这个req->req.complete(&ep->ep, &req->req)就又回到了逻辑层了，根据不同的EP对应的分别是ep0_complete（啥也没干）；bulk_in_complete； bulk_out_complete； intr_in_complete。
这几个函数都回县flush fifo，但物理层不需要，所以就跳过。接着smp_wmb()，这个函数设置一个写屏障，保证写操作的顺序，接着各个函数根据实际情况改变状态后唤醒逻辑层的核心线程。这个线程先不表，还回到物理层的中断处理函数，发现最重要的中断已经没了，剩下的中断有速度改变，复位，挂起，恢复都是纯粹的物理层的事，就不分析了，还有一个需要提醒的，要想通过USB标准测试，需要支持USB测试接口，这个驱动没有支持，大家自己写的时候应该支持上。
物理层的应该没了，现在看看逻辑层的那个线程吧。
/* Allow the thread to be killed by a signal, but set the signal mask
* to block everything but INT, TERM, KILL, and USR1. */
siginitsetinv(&fsg->thread_signal_mask, sigmask(SIGINT) |
sigmask(SIGTERM) | sigmask(SIGKILL) |
sigmask(SIGUSR1));
sigprocmask(SIG_SETMASK, &fsg->thread_signal_mask, NULL);
/* Arrange for userspace references to be interpreted as kernel
* pointers. That way we can pass a kernel pointer to a routine
* that expects a __user pointer and it will work okay. */
set_fs(get_ds());
这几句看了看注释，一两句解释不清楚，linux信号相关的东西，可以参考内核注解那篇文章。往下就是主循环了
/* The main loop */
while (fsg->state != FSG_STATE_TERMINATED) {……}
FSG_STATE_TERMINATED这个状态只有在bind函数失败时才有，所以说只要bind过了，这种可能性就没了，说白了就是出不去的循环了。
抛开点灯灭灯不说，先查一下是不是有异常或者有人发什么信号了，如果有处理之：
这个异常处理函数先处理系统发来的信号，具体会有什么东东就不太懂了。接着清理一些buf，如果有中断端点忙得话，其他端点都得放下手头的活候着。然后检查一下状态，并作相应的处理。回想一下先前看过的代码，在好多地方看到过raise_exception，尤其是setup时，进去看看发现就是设置了一个新状态，然后发了个信号给这个模块的主线程。所以才有处理异常的时候检查状态并作相应的处理。
接着 if (!fsg->running) {
sleep_thread(fsg);
continue;
}
如果设备都不run了，线程当然要睡了
get_next_command，获得命令，usb如果收到的命令，把它放到fsg->cmnd中，并且根据命令给fsg->data_dir赋值。
if (do_scsi_command(fsg) || finish_reply(fsg))
处理命令和请求。具体请参考协议。
最后发送设备的状态send_status。
代码分析就到这里了。可能表述的不是很清楚，再画个图吧。
图一
其实结构很简单，只有两层，物理层和逻辑层。两层都有接口开放给对方，一加载就开始互通有无，物理层以中断驱动动整个设备，直接和物理设备交互，如果接到自己可以处理的信息就直接处理，接到无法处理的通过逻辑层提供的接口通知逻辑层，逻辑层用一个线程监控整个运行过程，如果没事就先睡会，有事立马起来分析处理，处理后一般还需要把结果通过物理层发送出去，如果物理层完成了任务在通知逻辑层。结构比WINCE的复杂些，但功能好像比CE的弱些。没有CE的结构清晰。写USB mass storage 驱动个人觉得必须先看懂协议，至少了解基本的东西。
写的不对的地方还望来往过客指正。
