USB主机控制器驱动：一次由枚举超时引发的底层追踪

深夜的调试现场设备树里加了个USB摄像头插上后内核直接打印“usb 1-1: device not accepting address 19, error -62”。dmesg里那行“xhci-hcd 0000:01:00.0: WARN: Stalled endpoint”像根刺扎在眼里。问题来了这到底是硬件链路不稳还是控制器驱动有毛病这种时候抱怨硬件设计没意义得顺着USB协议栈往下摸直到主机控制器驱动这一层。控制器驱动在USB栈里的位置很多人以为USB驱动就是写个设备驱动匹配VID/PID就完事了。实际上Linux USB子系统是典型的三层架构最上层是设备驱动usb_driver中间是核心层usb_core最底层才是主机控制器驱动hcd。你的摄像头驱动调用的usb_submit_urb()最终会转化成控制器能识别的传输描述符TD。xhci、ehci、ohci这些驱动干的就是把USB协议里的传输请求翻译成具体控制器寄存器能懂的操作。关键数据结构urb与td写驱动时提交的urbUSB Request Block到了hcd层会被拆解成多个tdTransfer Descriptor。以xhci为例提交一个BULK OUT的urb大概经历这么几步/* 这是简化后的流程真实代码在drivers/usb/host/xhci.c里 */staticintxhci_urb_enqueue(structusb_hcd*hcd,structurb*urb){structxhci_hcd*xhcihcd_to_xhci(hcd);structxhci_ep_ctx*ep_ctx;/* 先根据urb里的端点地址找到对应的端点上下文 */ep_indexxhci_get_endpoint_index(urb-ep-desc);ep_ctxxhci_get_ep_ctx(xhci,virt_dev-in_ctx,ep_index);/* 这里有个坑urb-transfer_buffer_length可能不是max_packet_size的整数倍 */if(urb-transfer_buffer_length%ep_ctx-ep_info2MAX_PACKET_MASK){/* 需要额外处理短包 */xhci-quirks|XHCI_QUIRK_NEED_EXTRA_PACKET;}/* 把urb拆成若干个trbxhci里td的具体实现 */for(i0;inum_trbs;i){trbxhci-cmd_ring.dequeue;trb-buffercpu_to_le64(buffer_dma);trb-lengthcpu_to_le32(this_trb_len);/* 注意flag的设置最后一个trb要设TRB_IOC位 */if(inum_trbs-1){trb-control|cpu_to_le32(TRB_IOC|TRB_TYPE(TRB_NORMAL));}/* 推进环指针 */xhci_ring_cmd_ring(xhci);}/* 敲响门铃寄存器通知控制器 */xhci_writel(xhci,doorbell,xhci-dba-doorbell[0]);}那个error -62-ETIMEDOUT就出现在这里控制器在规定时间内没收到设备ACKtd状态寄存器里标记了babble error。但问题可能不在硬件——我遇到过因为urb提交太快前一个td还没complete就塞下一个把控制器状态机搞乱的情况。中断处理里的门道控制器产生中断后hcd的中断服务程序要处理各种事件。以xhci为例irqreturn_txhci_irq(structusb_hcd*hcd){statusxhci_readl(xhci,xhci-op_regs-status);/* 千万别直接清中断标志先处理事件 */if(statusSTS_EINT){/* 从事件环取事件 */eventxhci-event_ring.dequeue;switch(GET_COMP_CODE(le32_to_cpu(event-event_cmd))){caseCOMP_SUCCESS:/* 正常完成找到对应的urb调用它的complete回调 */urbxhci_find_urb_by_trb(xhci,event-trb_ptr);usb_hcd_giveback_urb(hcd,urb,0);break;caseCOMP_BABBLE_DETECTED_ERROR:/* 这就是我们遇到的错误 */xhci_warn(xhci,Babble detected, maybe device is sending too much data\n);/* 这里要重置端点不然这个端口就废了 */xhci_reset_endpoint(xhci,urb);break;}/* 事件处理完才移动dequeue指针 */xhci_inc_deq(xhci,xhci-event_ring);}/* 最后才写寄存器清中断 */xhci_writel(xhci,status,xhci-op_regs-status);}有一次调试我在处理事件前就清了中断标志结果漏掉了一个传输完成事件导致urb永远没被giveback用户层调用一直卡在ioctl里。电源管理这个暗坑设备树里配置了控制器为wakeup-source但实际唤醒不了。查了半天发现xhci驱动里有个细节staticintxhci_suspend(structusb_hcd*hcd,bool do_wakeup){/* 如果do_wakeup为true要保留端口唤醒使能 */if(do_wakeup){portscxhci_readl(xhci,port_array[port_index]);portsc|PORT_WKOC_E|PORT_WKDISC_E;xhci_writel(xhci,portsc,port_array[port_index]);}else{/* 否则要禁用所有唤醒源不然可能唤醒失败 */xhci_disable_wakeup_sources(xhci);}/* 这里踩过坑有些芯片需要额外设置PME_En位 */if(xhci-quirksXHCI_PME_EN_QUIRK){pci_set_pme_state(to_pci_dev(hcd-self.controller),true);}}给后来者的几点经验调试USB控制器问题先看/proc/interrupts里hcd的中断计数是否在增长。没中断的话大概率是控制器初始化或时钟有问题。遇到枚举失败别急着换设备。用示波器抓一下D/D-线上的信号质量有时候就是PCB走线太长导致的边缘抖动。自己写hcd驱动的情况不多但改dts配置是常事。注意那个“dr_mode”字段host/otg/peripheral模式对应的控制器初始化流程差别很大配错了连寄存器都访问不到。urb提交失败时试试在提交前加个msleep(20)。这不是正经解决方案但能帮你判断是不是控制器状态机还没就绪。保留一份芯片的TRM技术参考手册在硬盘里那些寄存器描述比任何博客都有用。我习惯把关键寄存器的位域定义打印出来贴在工位隔板上。USB主机控制器驱动就像个翻译官在协议层和硬件层之间传递消息。调试这种问题得学会同时看两边的“脸色”一边是协议栈的error code一边是寄存器的bit status。有时候问题不在翻译本身而在双方还没对上沟通的节奏。