5.1 使用流程

在 USB 協議中，永遠是 Host 主動發起傳輸。作為一個 Gadget 驅動程序，它永遠都是這樣：

• 想接收數據：
  • 先構造好 usb_request：分配 buffer、設置回調函數
  • 把 usb_request 放入隊列
  • UDC 和 Host 完成 USB 傳輸，在 usb_request 中填充數據，并觸發中斷調用 usb_request 的回調函數
• 想發送數據：
  • 先構造好 usb_request：分配 buffer、在 buffer 里填充數據、設置回調函數
  • 把 usb_request 放入隊列
  • UDC 和 Host 完成 USB 傳輸，把 usb_request 的數據發給 Host，并觸發中斷調用 usb_request 的回調函數

5.2 endpoint 是核心

USB 傳輸的對象是 endpoint，使用流程如下：

• 功能驅動里，通過 endpoint 描述符表明需要怎樣的 endpoint，比如（注意：bEndpointAddress 是表明方向，里面還沒有地址，driversusbgadgetfunctionf_loopback.c）：

• 功能驅動里，它的 bind 函數根據 endpoint 描述符向底層申請分配 endpoint，比如：

• 功能驅動里，使能 endpoint，比如：

• 功能驅動里，給 endpoint 分配 buffer、設置 usb_request、提交 usb_request，比如：

5.3 回調函數

功能驅動里構造的 usb_request，可以是接收 Host 發來的數據，也可以是向 Host 發送數據。當傳輸完成，usb_request 的回調函數被調用。

在回調函數里，可以再次提交 usb_request。

怎么調用到回調函數？源頭是 UDC 的中斷函數。

5.3.1 IMX6ULL

調用關系如下：

// Linux-4.9.88driversusbchipideacore.c
ci_irq
 /* Handle device/host interrupt */
 if (ci- >role != CI_ROLE_END)
  ret = ci_role(ci)- >irq(ci);  // udc_irq
   udc_irq
                if (USBi_UI  & intr)
                    isr_tr_complete_handler(ci);
                     err = isr_tr_complete_low(hwep);
                        usb_gadget_giveback_request(&hweptemp- >ep, &hwreq- >req);
                         req- >complete(ep, req);

5.3.2 STM32MP157

調用關系如下：

// Linux-5.4driversusbdwc2gadget.c
dwc2_hsotg_irq
  // 處理endpoint中斷
  for (ep = 0; ep < hsotg- >num_of_eps && daint_out;
      ep++, daint_out > >= 1) {
   if (daint_out & 1)
    dwc2_hsotg_epint(hsotg, ep, 0);
     dwc2_hsotg_handle_outdone(hsotg, idx);
      dwc2_hsotg_complete_request(hsotg, hs_ep, hs_req, result);
       usb_gadget_giveback_request(&hs_ep- >ep, &hs_req- >req);
        req- >complete(ep, req);
  }

  for (ep = 0; ep < hsotg- >num_of_eps  && daint_in;
      ep++, daint_in > >= 1) {
   if (daint_in & 1)
    dwc2_hsotg_epint(hsotg, ep, 1);
     dwc2_hsotg_complete_in(hsotg, hs_ep);
      dwc2_hsotg_complete_request(hsotg, hs_ep, hs_req, 0);
       usb_gadget_giveback_request(&hs_ep- >ep, &hs_req- >req);
        req- >complete(ep, req);
  }

5.4 f_loopback分析

loopback 就是回環，Host 發數據給 Gadget，然后再讀 Gadget 就可以得到原樣的數據。

5.4.1 Gadget接收數據

Host 選擇某個配置時，默認會選擇這個配置下那些接口的第 0 個設置(altsetting)；

當 Host 發來 USB_REQ_SET_INTERFACE 請求時，可以選擇指定的設置。

所以，我們從 f_loopback.c 的函數loopback_set_alt開始分析。

調用關系為：

loopback_set_alt
 enable_loopback
  result = enable_endpoint(cdev, loop, loop- >in_ep);
  
  result = enable_endpoint(cdev, loop, loop- >out_ep);
  
  result = alloc_requests(cdev, loop);

如上圖所示，先提交的是 out_req，它在等待 Host 發來數據。

假設斷點 loop->out_ep 的 out_req 獲得了數據，它的回調函數loopback_complete被調用，如下：

5.4.2 Gadget 回環數據

5.5 f_sourcesink 分析

前面的 f_loopback 也實現了兩個方向的數據傳輸：Host 到 Gadget、Gadget 到 Host，但是它們之間是有依賴關系的，Host 必須先發送數據再讀數據。

f_sourcesink.c 也實現了兩個方向的數據傳輸：Host 到 Gadget、Gadget 到 Host，它們是獨立的。

• Host 讀 Gadget：驅動程序里構造好數據，Host 可以讀到，Gadget 作為源(source)
• Host 寫 Gadget：驅動程序里得到 Host 發來的數據，Gadget 作為目的(sink)

5.5.1 Host 寫 Gadget

Host 選擇某個配置時，默認會選擇這個配置下那些接口的第 0 個設置(altsetting)；

當 Host 發來 USB_REQ_SET_INTERFACE 請求時，可以選擇指定的設置。

所為，我們從 f_sourcesink.c 的函數sourcesink_set_alt開始分析。

sourcesink_set_alt
 enable_source_sink(cdev, ss, alt);

作為"source"，函數source_sink_start_ep會構造數據、提交 usb_request：

當 Host 讀取到數據后，usb_request 的回調函數被調用，它只是再次提交 USB 請求，給 Host 繼續提供跟上次一樣的數據：

5.5.2 Host 讀 Gadget

仍然從 f_sourcesink.c 的函數sourcesink_set_alt開始分析。

sourcesink_set_alt
 enable_source_sink(cdev, ss, alt);

作為"sink"，函數source_sink_start_ep會故意把數據設置為 0x55（這是為了調試，當讀到數據時可以看到 0x55 被覆蓋）、提交 usb_request：

當 Host 發來數據，usb_request 的回調函數被調用，它檢查收到的數據，再次提交 usb_request：