关于“Process xxx called USBDEVFS_CLEAR_HALT for active endpoint xx”

这本来是linux下的问题，由于在用户级的app里调用了驱动函数对usb设备进行了clear halt的操作，linux的开发者于是在log里打印出这个警告，用以提示程序员们：这样做可能有问题！具体请膜拜这个帖子：[PATCH] USB: complain if userspace resets an active endpoint — Linux USB

于是，真的有问题了。我的设备实现了一个usb键盘接口，接在一个android板上，没招谁没惹谁的跑着，偶尔发点数据给上位机而已。突然之间，收到了上位机给的这个clear_halt的请求，于是听话地来了个clear，然后本来好好的通信变得紊乱，链路上的数据直接被当做键盘值丢给主机，从抓取数据上看，完全是不合理的按键的组合，导致android系统瞎响应，随机打开某些app。。。

我真难，真的----linux我还没真正上过项目呢。。后来主板驱动开发人员说，这个命令不是发给你的设备的。。。但为什么我受到了，搞不懂哎。。既然主机那边不归我管，那就练练内功吧，看自己设备mcu的usb库代码。当然少不了mcu的支持朋友啦，人家给了个usb协议分析仪，神器！！确定了，设备真的收到了clear_feature请求，随后就抓到一段乱七八糟的键盘码数据。结合支持方 建议，对usb协议库中对应的代码做了处理：

如果接到clear_feature请求，让usb端点从stall变成active，则先判断，当前端点是否处于stall状态，是则响应，不是则不鸟之。。测试n久，抓数据确定设备在接收到乱命后不再抓狂，搞定！！

思考一下，mcu的usb库看起来不够完善，其本身应该是考虑到上位机不会在设备处于active状态下还会让设备去reset端点，即，usb库的代码对于异常情况考虑不周，不健壮。ps，这里用的是某国产mcu，对比过stm32的库，多数型号的mcu片子的库也没有这个处理哦^_^。

从出问题到解决问题花了小两周时间，各种障碍，没法子。感叹一下，linux的系统一致性问题可能比windows高。