> What's the actual issue here ? Can you explain to me Sarah ? > This may be a known issue regarding this particular host > controller and if it is, there might already be workarounds available. > I copy the previous content and try to make it more clear. When calling usb_reset_and_verify_device, hcd issue a reset command. The reset device command make the endpoint state disabled without releaseing the bandwidth. After reset is done, the HCD try to reconfigure the device to previous active config by usb_hcd_alloc_bandwidth. The HCD does such thing by modifying drop and add flag in input context, and issue configure endpoint command to comoplete the operation. When executing drop_endpoint, the endpoint is already in the disabled state. This behavior is correct according to the spec. And the HC will not evaluate drop flag of disable endpoint,too. As a result, the HC can not drop the endpoint to release the bandwidth. Then add_endpoint to enable these endpoints. After all drop add flag are set, HCD sends a configure endpoint command to complete the change. Before the priodic bandiwdth is used up, the configure endpoint command can success. However, after reset several times, the configure endpoint command fail with command status "not enough bandwidth". And the HC can not correctly configure any more periodic device. > If the problem is related only to device reset, then it would > have failed USB30CV Device Reset test which drives 500 Device > Resets and checks that device reenumerates. I doubt that's > the case though, since TI's TUSB7340 is built with a USB3 > Certified IP. > We have try two devices, both are USB-IF certified, on this host and they fail with same scenario. And these two devices can successfully reset several times on some other host.-- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
