TinyUSB主机模式下HUB端点状态传输双重调用问题分析

在TinyUSB开源USB协议栈的主机模式实现中，发现了一个与USB集线器(HUB)端点状态传输相关的潜在问题。该问题会导致在特定情况下对同一端点进行重复传输操作，从而触发断言错误。

问题背景

当设备通过USB集线器连接到主机时，TinyUSB的主机控制器需要通过中断端点定期轮询集线器的状态变化。在当前的实现中，存在一个竞态条件可能导致对同一端点发起两次传输请求。

问题现象

在连接设备到下游集线器时，系统会触发断言失败：

usbh_edpt_xfer_with_callback 843: ASSERT FAILED

错误信息表明尝试在一个繁忙的端点上进行传输操作，这通常意味着存在竞态条件。

根本原因分析

经过深入代码分析，发现问题出在hub.c文件中的两个相关函数：

1. hub_port_get_status_complete函数在完成端口状态获取后会无条件调用hub_edpt_status_xfer来准备下一次状态传输
2. 同时，hub_clear_feature_complete_stub函数也会调用相同的hub_edpt_status_xfer函数

这种设计导致了在某些情况下(特别是当集线器触发port_enable状态变化时)，两个代码路径会先后对同一端点发起传输请求，造成端点忙状态冲突。

解决方案

通过修改hub_port_get_status_complete函数的逻辑，使其仅在特定条件下(非状态变化情况下)才发起下一次状态传输请求。这样可以避免与hub_clear_feature_complete_stub函数产生冲突。

修改后的代码增加了else条件判断，确保不会在状态变化处理路径中重复发起传输请求。

影响范围

该问题主要影响使用TinyUSB主机模式并连接USB集线器的场景。特别是当集线器设备报告port_enable状态变化时更容易触发此问题。虽然测试中使用了OHCI主机控制器，但理论上该问题会影响所有主机控制器实现。

技术启示

这个案例展示了USB主机控制器开发中几个重要考量点：

1. 状态机设计需要严格考虑各种可能的执行路径
2. 端点传输管理需要确保同一时间只有一个传输请求
3. 集线器状态变化处理需要特别小心，因为可能触发多个处理流程

通过这个修复，TinyUSB能够更稳定地支持复杂的USB设备树结构，包括多级集线器连接多个设备的场景。