mini2440 usb device controller 驱动的分析--gadget设备(一)--device controller
2013-10-14 16:55
603 查看
已经看了很长时间USB的驱动了。USB是目前看到最复杂的驱动,内容很多,但网上分析USB驱动的资料很少,因此我在学习的过程中走了很多弯路。在这里记录自己的学习过程,希望可以帮到其他研究USB驱动的同事。先推荐一本书:Bootstrap Yourself With Linux-USB Stack
首先,USB的驱动分成两部分:host和gadget。usb是一个host driven的协议,即host是完全主动,每次通信过程都是由host发起的,包括读和写。而device只负责回应,不能主动去读写。另外,虽然usb有四种传输(在很多书中都有介绍),但是usb的传输和其他的通信方式都一样,都是基于硬件中断的。无论在host方还是device方,都是产生中断之后,进行相应的处理。因此,中断函数是很多处理过程的入口点。这里的硬件中断和四种传输方式中的中断传输是完全不同的概念。
在LDD中,说不介绍gadget部分的驱动,但是它提到了configuration\interface\endpoint等概念。其实这些设置在host和gadget上面都有,在gadget的驱动里负责实现 configuration\interface,在host的驱动中,主要是得到gadget的configuration和interface,进而对gadget进行控制。
本文以s3c2440上的gadget驱动为例,分析gadget的驱动。 在以后的文章中在分析host的驱动。因为gadget的驱动相对简单。
首先,usb的驱动都是分层的。gadget部分的驱动分层如下:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202009/28/96d292387b166cc4dca37e41a938f27b)
其中,1.usb device controller就是具体的硬件,对应到2440的usb device controller。在数据手册上面可以看到相应的说明。2440还有一个usb host controller。这是两个不同的硬件,分别用于实现2440的usb device 和 usb host功能,在使用时,各用各的,没有相互的影响。
2. device firmware driver。这是最低层的驱动实现,其实这部分的驱动就是负责直接控制 device controller硬件的。对应的文件是usb/gadget/s3c2410_udc.c。在这部分文件中,可以配置相应的寄存器,获取硬件资源等。device controller也是实现成了一个platform device的。
3. chapter 9-- Driver/usb device framework。按照我的理解,这部分的驱动主要是一个中间层,在这部分实现了 usb 枚举的过程(在device部分是被动的,主要是如何回应host 发过来的请求。),实现从 frimware driver 和 class driver 的通信。我们可以对应到 composite.c 这个文件。
4. usb class driver。这部分驱动是要实现具体的功能的。比如最常用的u盘的功能、usb 鼠标的功能。我们以zero.c驱动为例进行分析,这个驱动可以实现的功能是可以将host发送过来的消息 回送 给主机。相当于是一个echo的作用。
从上面的分析,可以看出,firmware driver负责控制硬件,class driver 负责处理具体的业务,完成具体的功能。device frimwork负责处理其他的事情。上面就是usb device部分的分层模型。
通常,在一般介绍usb驱动的资料中,上来就介绍几个usb相关的结构体,每个结构体都很大,让人看了根本摸不到头脑。我觉得这里的分层模型是更重要的。
前面转载了两篇介绍usb 枚举过程的博客,都是写的很好的。网上的资料中,最丰富的算是 linux那些事之USB。不得不佩服写相关博客的那位博主,真是相当有才。深入分析usb的同时穿插着各种各种段子,我强忍着剧烈痛苦看了一个星期,收获不大,不得不说那个博文太过庞杂。
下面,具体分析各层。首先,是s3c2410_udc.c文件。这个文件中先是按照platform device,实现了基本的probe函数等。
这里的实现和一般的platfrom device 是一样的。需要说明的
1. 就是probe函数中的vbus_pin。这个管脚是与vbus相连的,练到了一个mcu的外部中断。这样,当vbus有电平变化的时候,mcu就可以知道。因为,device设备正常来讲不知道自己被插入(或拔出)到了主设备的root hub中,vbus用于给usb设备供电,当device被插入时,vbus会使高电平,拔出时会是低电平。所以,通过vbus的中断,device设备就可以感应到自己被插拔的事件。通常,在插入时,enable_udc。被拔出后,disable_udc。当然,如果在硬件上面,没有这部分电路,那么就需要一直enable_udc。
2. memory。在probe函数中有一个memory。在这个struct s3c2410_udc memory 中记录了device controller的5个end point的相关信息。其中ep0是用作control功能的,其余的用于传输数据。在udc的driver中,并不指定ep的方向,但在class driver 中会指定。
到这里probe函数执行完后,usb device controller的初始化就完成了。
接下来,程序的入口就是usb的中断函数s3c2410_udc_irq了。
我们先看s3c2410_udc_handle_ep0
首先是从ep0的request queue上得到一个req。struct s3c2410_request *req。request是usb device用于描述IO请求的。结构体对应如下:
按照代码的意思,这个req(queue上面的第一个req)就和上面产生的中断相对应。也就是说中断与req完全是按照时间先后顺序对应的。我觉得这里是否会有问题?
上面比较主要的状态是idle、in_data_phase、out_data_phase。其中idle应该是ep0的初始状态,in_data_phase\out_data_phase 应该是对应接收数据和发送数据的状态。分别看三个函数。
首先,USB的驱动分成两部分:host和gadget。usb是一个host driven的协议,即host是完全主动,每次通信过程都是由host发起的,包括读和写。而device只负责回应,不能主动去读写。另外,虽然usb有四种传输(在很多书中都有介绍),但是usb的传输和其他的通信方式都一样,都是基于硬件中断的。无论在host方还是device方,都是产生中断之后,进行相应的处理。因此,中断函数是很多处理过程的入口点。这里的硬件中断和四种传输方式中的中断传输是完全不同的概念。
在LDD中,说不介绍gadget部分的驱动,但是它提到了configuration\interface\endpoint等概念。其实这些设置在host和gadget上面都有,在gadget的驱动里负责实现 configuration\interface,在host的驱动中,主要是得到gadget的configuration和interface,进而对gadget进行控制。
本文以s3c2440上的gadget驱动为例,分析gadget的驱动。 在以后的文章中在分析host的驱动。因为gadget的驱动相对简单。
首先,usb的驱动都是分层的。gadget部分的驱动分层如下:
其中,1.usb device controller就是具体的硬件,对应到2440的usb device controller。在数据手册上面可以看到相应的说明。2440还有一个usb host controller。这是两个不同的硬件,分别用于实现2440的usb device 和 usb host功能,在使用时,各用各的,没有相互的影响。
2. device firmware driver。这是最低层的驱动实现,其实这部分的驱动就是负责直接控制 device controller硬件的。对应的文件是usb/gadget/s3c2410_udc.c。在这部分文件中,可以配置相应的寄存器,获取硬件资源等。device controller也是实现成了一个platform device的。
3. chapter 9-- Driver/usb device framework。按照我的理解,这部分的驱动主要是一个中间层,在这部分实现了 usb 枚举的过程(在device部分是被动的,主要是如何回应host 发过来的请求。),实现从 frimware driver 和 class driver 的通信。我们可以对应到 composite.c 这个文件。
4. usb class driver。这部分驱动是要实现具体的功能的。比如最常用的u盘的功能、usb 鼠标的功能。我们以zero.c驱动为例进行分析,这个驱动可以实现的功能是可以将host发送过来的消息 回送 给主机。相当于是一个echo的作用。
从上面的分析,可以看出,firmware driver负责控制硬件,class driver 负责处理具体的业务,完成具体的功能。device frimwork负责处理其他的事情。上面就是usb device部分的分层模型。
通常,在一般介绍usb驱动的资料中,上来就介绍几个usb相关的结构体,每个结构体都很大,让人看了根本摸不到头脑。我觉得这里的分层模型是更重要的。
前面转载了两篇介绍usb 枚举过程的博客,都是写的很好的。网上的资料中,最丰富的算是 linux那些事之USB。不得不佩服写相关博客的那位博主,真是相当有才。深入分析usb的同时穿插着各种各种段子,我强忍着剧烈痛苦看了一个星期,收获不大,不得不说那个博文太过庞杂。
下面,具体分析各层。首先,是s3c2410_udc.c文件。这个文件中先是按照platform device,实现了基本的probe函数等。
/* * probe - binds to the platform device */ static int s3c2410_udc_probe(struct platform_device *pdev) { struct s3c2410_udc *udc = &memory; struct device *dev = &pdev->dev; int retval; int irq; dev_dbg(dev, "%s()\n", __func__); usb_bus_clock = clk_get(NULL, "usb-bus-gadget"); if (IS_ERR(usb_bus_clock)) { dev_err(dev, "failed to get usb bus clock source\n"); return PTR_ERR(usb_bus_clock); } clk_enable(usb_bus_clock); udc_clock = clk_get(NULL, "usb-device"); if (IS_ERR(udc_clock)) { dev_err(dev, "failed to get udc clock source\n"); return PTR_ERR(udc_clock); } clk_enable(udc_clock); mdelay(10); dev_dbg(dev, "got and enabled clocks\n"); if (strncmp(pdev->name, "s3c2440", 7) == 0) { dev_info(dev, "S3C2440: increasing FIFO to 128 bytes\n"); memory.ep[1].fifo_size = S3C2440_EP_FIFO_SIZE; memory.ep[2].fifo_size = S3C2440_EP_FIFO_SIZE; memory.ep[3].fifo_size = S3C2440_EP_FIFO_SIZE; memory.ep[4].fifo_size = S3C2440_EP_FIFO_SIZE; } spin_lock_init (&udc->lock); udc_info = pdev->dev.platform_data; rsrc_start = S3C2410_PA_USBDEV; rsrc_len = S3C24XX_SZ_USBDEV; if (!request_mem_region(rsrc_start, rsrc_len, gadget_name)) return -EBUSY; base_addr = ioremap(rsrc_start, rsrc_len); if (!base_addr) { retval = -ENOMEM; goto err_mem; } device_initialize(&udc->gadget.dev); udc->gadget.dev.parent = &pdev->dev; udc->gadget.dev.dma_mask = pdev->dev.dma_mask; the_controller = udc; platform_set_drvdata(pdev, udc); s3c2410_udc_disable(udc); s3c2410_udc_reinit(udc); /* irq setup after old hardware state is cleaned up */ retval = request_irq(IRQ_USBD, s3c2410_udc_irq, IRQF_DISABLED, gadget_name, udc); if (retval != 0) { dev_err(dev, "cannot get irq %i, err %d\n", IRQ_USBD, retval); retval = -EBUSY; goto err_map; } dev_dbg(dev, "got irq %i\n", IRQ_USBD); if (udc_info && udc_info->vbus_pin > 0) { retval = gpio_request(udc_info->vbus_pin, "udc vbus"); if (retval < 0) { dev_err(dev, "cannot claim vbus pin\n"); goto err_int; } irq = gpio_to_irq(udc_info->vbus_pin); if (irq < 0) { dev_err(dev, "no irq for gpio vbus pin\n"); goto err_gpio_claim; } retval = request_irq(irq, s3c2410_udc_vbus_irq, IRQF_DISABLED | IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_SHARED, gadget_name, udc); if (retval != 0) { dev_err(dev, "can't get vbus irq %d, err %d\n", irq, retval); retval = -EBUSY; goto err_gpio_claim; } dev_dbg(dev, "got irq %i\n", irq); } else { udc->vbus = 1; } dev_dbg(dev, "probe ok\n"); return 0; } /* * s3c2410_udc_remove */ static int s3c2410_udc_remove(struct platform_device *pdev) { dev_dbg(&pdev->dev, "%s: remove ok\n", __func__);
... return 0; } static struct platform_driver udc_driver_2440 = { .driver = { .name = "s3c2440-usbgadget", .owner = THIS_MODULE, }, .probe = s3c2410_udc_probe, .remove = s3c2410_udc_remove, .suspend = s3c2410_udc_suspend, .resume = s3c2410_udc_resume, };
这里的实现和一般的platfrom device 是一样的。需要说明的
1. 就是probe函数中的vbus_pin。这个管脚是与vbus相连的,练到了一个mcu的外部中断。这样,当vbus有电平变化的时候,mcu就可以知道。因为,device设备正常来讲不知道自己被插入(或拔出)到了主设备的root hub中,vbus用于给usb设备供电,当device被插入时,vbus会使高电平,拔出时会是低电平。所以,通过vbus的中断,device设备就可以感应到自己被插拔的事件。通常,在插入时,enable_udc。被拔出后,disable_udc。当然,如果在硬件上面,没有这部分电路,那么就需要一直enable_udc。
2. memory。在probe函数中有一个memory。在这个struct s3c2410_udc memory 中记录了device controller的5个end point的相关信息。其中ep0是用作control功能的,其余的用于传输数据。在udc的driver中,并不指定ep的方向,但在class driver 中会指定。
到这里probe函数执行完后,usb device controller的初始化就完成了。
接下来,程序的入口就是usb的中断函数s3c2410_udc_irq了。
static irqreturn_t s3c2410_udc_irq(int dummy, void *_dev) { struct s3c2410_udc *dev = _dev; int usb_status; int usbd_status; int pwr_reg; int ep0csr; int i; u32 idx; unsigned long flags; spin_lock_irqsave(&dev->lock, flags); /* Save index */ idx = udc_read(S3C2410_UDC_INDEX_REG); 读取index register /* Read status registers */ usb_status = udc_read(S3C2410_UDC_USB_INT_REG); usbd_status = udc_read(S3C2410_UDC_EP_INT_REG); pwr_reg = udc_read(S3C2410_UDC_PWR_REG); udc_writeb(base_addr, S3C2410_UDC_INDEX_EP0, S3C2410_UDC_INDEX_REG); ep0csr = udc_read(S3C2410_UDC_IN_CSR1_REG); dprintk(DEBUG_NORMAL, "usbs=%02x, usbds=%02x, pwr=%02x ep0csr=%02x\n", usb_status, usbd_status, pwr_reg, ep0csr); /* * Now, handle interrupts. There's two types : * - Reset, Resume, Suspend coming -> usb_int_reg * - EP -> ep_int_reg */ /* RESET */ if (usb_status & S3C2410_UDC_USBINT_RESET) { /* two kind of reset : * - reset start -> pwr reg = 8 * - reset end -> pwr reg = 0 **/ dprintk(DEBUG_NORMAL, "USB reset csr %x pwr %x\n", ep0csr, pwr_reg); dev->gadget.speed = USB_SPEED_UNKNOWN; udc_write(0x00, S3C2410_UDC_INDEX_REG); udc_write((dev->ep[0].ep.maxpacket & 0x7ff) >> 3, S3C2410_UDC_MAXP_REG); dev->address = 0; dev->ep0state = EP0_IDLE; dev->gadget.speed = USB_SPEED_FULL; /* clear interrupt */ udc_write(S3C2410_UDC_USBINT_RESET, S3C2410_UDC_USB_INT_REG); udc_write(idx, S3C2410_UDC_INDEX_REG); spin_unlock_irqrestore(&dev->lock, flags); return IRQ_HANDLED; } /* RESUME */ if (usb_status & S3C2410_UDC_USBINT_RESUME) { dprintk(DEBUG_NORMAL, "USB resume\n"); /* clear interrupt */ udc_write(S3C2410_UDC_USBINT_RESUME, S3C2410_UDC_USB_INT_REG); if (dev->gadget.speed != USB_SPEED_UNKNOWN && dev->driver && dev->driver->resume) dev->driver->resume(&dev->gadget); } /* SUSPEND */ if (usb_status & S3C2410_UDC_USBINT_SUSPEND) { dprintk(DEBUG_NORMAL, "USB suspend\n"); /* clear interrupt */ udc_write(S3C2410_UDC_USBINT_SUSPEND, S3C2410_UDC_USB_INT_REG); if (dev->gadget.speed != USB_SPEED_UNKNOWN && dev->driver && dev->driver->suspend) dev->driver->suspend(&dev->gadget); dev->ep0state = EP0_IDLE; } /* EP */ /* control traffic */ /* check on ep0csr != 0 is not a good idea as clearing in_pkt_ready * generate an interrupt */ if (usbd_status & S3C2410_UDC_INT_EP0) { dprintk(DEBUG_VERBOSE, "USB ep0 irq\n"); /* Clear the interrupt bit by setting it to 1 */ udc_write(S3C2410_UDC_INT_EP0, S3C2410_UDC_EP_INT_REG); s3c2410_udc_handle_ep0(dev); } /* endpoint data transfers */ for (i = 1; i < S3C2410_ENDPOINTS; i++) { u32 tmp = 1 << i; if (usbd_status & tmp) { dprintk(DEBUG_VERBOSE, "USB ep%d irq\n", i); /* Clear the interrupt bit by setting it to 1 */ udc_write(tmp, S3C2410_UDC_EP_INT_REG); s3c2410_udc_handle_ep(&dev->ep[i]); } } dprintk(DEBUG_VERBOSE, "irq: %d s3c2410_udc_done.\n", IRQ_USBD); /* Restore old index */ udc_write(idx, S3C2410_UDC_INDEX_REG); spin_unlock_irqrestore(&dev->lock, flags); return IRQ_HANDLED;
}可以看出,上面的函数主要是处理了两种类型的中断,usb interrupt和end point interrupt。其中usb interrupt主要是指usb device的suspend、resume、reset中断,目前我还不知道这些中断是如何产生的?endpoint interrupt就是指ep0~5 收到/发完数据之后产生的中断。因为ep0是特殊的用于控制的endpoint,因此,对ep0进行了特殊的处理。
我们先看s3c2410_udc_handle_ep0
static void s3c2410_udc_handle_ep0(struct s3c2410_udc *dev) { u32 ep0csr; struct s3c2410_ep *ep = &dev->ep[0]; struct s3c2410_request *req; struct usb_ctrlrequest crq; if (list_empty(&ep->queue)) req = NULL; else req = list_entry(ep->queue.next, struct s3c2410_request, queue); /* We make the assumption that S3C2410_UDC_IN_CSR1_REG equal to * S3C2410_UDC_EP0_CSR_REG when index is zero */ udc_write(0, S3C2410_UDC_INDEX_REG); ep0csr = udc_read(S3C2410_UDC_IN_CSR1_REG); /* clear stall status */ if (ep0csr & S3C2410_UDC_EP0_CSR_SENTSTL) { s3c2410_udc_nuke(dev, ep, -EPIPE); dprintk(DEBUG_NORMAL, "... clear SENT_STALL ...\n"); s3c2410_udc_clear_ep0_sst(base_addr); dev->ep0state = EP0_IDLE; return; } /* clear setup end */ if (ep0csr & S3C2410_UDC_EP0_CSR_SE) { dprintk(DEBUG_NORMAL, "... serviced SETUP_END ...\n"); s3c2410_udc_nuke(dev, ep, 0); s3c2410_udc_clear_ep0_se(base_addr); dev->ep0state = EP0_IDLE; } switch (dev->ep0state) { case EP0_IDLE: s3c2410_udc_handle_ep0_idle(dev, ep, &crq, ep0csr); break; case EP0_IN_DATA_PHASE: /* GET_DESCRIPTOR etc */ dprintk(DEBUG_NORMAL, "EP0_IN_DATA_PHASE ... what now?\n"); if (!(ep0csr & S3C2410_UDC_EP0_CSR_IPKRDY) && req) { s3c2410_udc_write_fifo(ep, req); } break; case EP0_OUT_DATA_PHASE: /* SET_DESCRIPTOR etc */ dprintk(DEBUG_NORMAL, "EP0_OUT_DATA_PHASE ... what now?\n"); if ((ep0csr & S3C2410_UDC_EP0_CSR_OPKRDY) && req ) { s3c2410_udc_read_fifo(ep,req); } break; case EP0_END_XFER: dprintk(DEBUG_NORMAL, "EP0_END_XFER ... what now?\n"); dev->ep0state = EP0_IDLE; break; case EP0_STALL: dprintk(DEBUG_NORMAL, "EP0_STALL ... what now?\n"); dev->ep0state = EP0_IDLE; break; } }
首先是从ep0的request queue上得到一个req。struct s3c2410_request *req。request是usb device用于描述IO请求的。结构体对应如下:
struct usb_request { void *buf; unsigned length; dma_addr_t dma; unsigned no_interrupt:1; unsigned zero:1; unsigned short_not_ok:1; void (*complete)(struct usb_ep *ep, struct usb_request *req); 这个是io request完成时的回调函数。 void *context; struct list_head list; int status; unsigned actual; };每个ep都有一个queue,上面有由这个ep产生的所有read、write request。
按照代码的意思,这个req(queue上面的第一个req)就和上面产生的中断相对应。也就是说中断与req完全是按照时间先后顺序对应的。我觉得这里是否会有问题?
上面比较主要的状态是idle、in_data_phase、out_data_phase。其中idle应该是ep0的初始状态,in_data_phase\out_data_phase 应该是对应接收数据和发送数据的状态。分别看三个函数。
static void s3c2410_udc_handle_ep0_idle(struct s3c2410_udc *dev, struct s3c2410_ep *ep, struct usb_ctrlrequest *crq, u32 ep0csr) { int len, ret, tmp; s3c2410_udc_nuke(dev, ep, -EPROTO); // 这个函数的作用? len = s3c2410_udc_read_fifo_crq(crq); //从fifo中读取control request dprintk(DEBUG_NORMAL, "bRequest = %d bRequestType %d wLength = %d\n", crq->bRequest, crq->bRequestType, crq->wLength); /* cope with automagic for some standard requests. */ dev->req_std = (crq->bRequestType & USB_TYPE_MASK) == USB_TYPE_STANDARD; dev->req_config = 0; dev->req_pending = 1;
// 这里是根据control request的,采取不同的措施。 switch (crq->bRequest) { case USB_REQ_SET_CONFIGURATION: dprintk(DEBUG_NORMAL, "USB_REQ_SET_CONFIGURATION ... \n"); if (crq->bRequestType == USB_RECIP_DEVICE) { dev->req_config = 1; s3c2410_udc_set_ep0_de_out(base_addr); } break; case USB_REQ_SET_INTERFACE: dprintk(DEBUG_NORMAL, "USB_REQ_SET_INTERFACE ... \n"); if (crq->bRequestType == USB_RECIP_INTERFACE) { dev->req_config = 1; s3c2410_udc_set_ep0_de_out(base_addr); } break; case USB_REQ_SET_ADDRESS: dprintk(DEBUG_NORMAL, "USB_REQ_SET_ADDRESS ... \n"); if (crq->bRequestType == USB_RECIP_DEVICE) { tmp = crq->wValue & 0x7F; dev->address = tmp; udc_write((tmp | S3C2410_UDC_FUNCADDR_UPDATE), S3C2410_UDC_FUNC_ADDR_REG); s3c2410_udc_set_ep0_de_out(base_addr); return; } break; case USB_REQ_GET_STATUS: dprintk(DEBUG_NORMAL, "USB_REQ_GET_STATUS ... \n"); s3c2410_udc_clear_ep0_opr(base_addr); if (dev->req_std) { if (!s3c2410_udc_get_status(dev, crq)) { return; } } break; case USB_REQ_CLEAR_FEATURE: s3c2410_udc_clear_ep0_opr(base_addr); if (crq->bRequestType != USB_RECIP_ENDPOINT) break; if (crq->wValue != USB_ENDPOINT_HALT || crq->wLength != 0) break; s3c2410_udc_set_halt(&dev->ep[crq->wIndex & 0x7f].ep, 0); s3c2410_udc_set_ep0_de_out(base_addr); return; case USB_REQ_SET_FEATURE: s3c2410_udc_clear_ep0_opr(base_addr); if (crq->bRequestType != USB_RECIP_ENDPOINT) break; if (crq->wValue != USB_ENDPOINT_HALT || crq->wLength != 0) break; s3c2410_udc_set_halt(&dev->ep[crq->wIndex & 0x7f].ep, 1); s3c2410_udc_set_ep0_de_out(base_addr); return; default: s3c2410_udc_clear_ep0_opr(base_addr); break; } if (crq->bRequestType & USB_DIR_IN) dev->ep0state = EP0_IN_DATA_PHASE; else dev->ep0state = EP0_OUT_DATA_PHASE;
设备枚举的具体过程。 ret = dev->driver->setup(&dev->gadget, crq); }由dev->driver->setup(&dev->gadget,crq)执行具体的设备枚举的过程。
相关文章推荐
- mini2440 usb device controller 驱动的分析--gadget设备
- mini2440 usb device controller 驱动的分析--gadget设备(三)--- usb device framework
- mini2440 usb device controller 驱动的分析--gadget设备(五)--zero和usb-skeleton测试例
- mini2440 usb device controller 驱动的分析--gadget设备(二)---枚举
- mini2440 usb device controller 驱动的分析--gadget设备(四)---class driver
- USB gadget设备驱动解析(3)——驱动结构分析
- USB Gadget设备驱动开发(四) BusHound 抓包分析
- linux usb Gadget (usb设备侧驱动分析)
- 从USB设备插上到驱动probe调用流程分析
- Linux内核部件分析--设备驱动模型之device
- Linux内核部件分析 设备驱动模型之device-driver
- linux内核部件分析之----设备驱动模型之device
- Linux内核部件分析-设备驱动模型之device
- USB 设备驱动开发之几个重要结构体分析
- linux设备驱动之USB主机控制器驱动分析
- linux设备驱动之USB数据传输分析(之四)
- linux设备驱动之USB数据传输分析
- mini2440插入usb设备出现: unable to enumerate USB device on port问题的解决,以及使用super vivi对nand flash进行分区
- 基于s3c6410 otg controller的gadget driver及usb枚举分析
- USB Gadget设备驱动开发(一) USB Gadget软件结构