>> Hello, >> >> I work for Texas Instruments on the group that develops our USB 3.0 >> products. Recently, we discovered a timing issue in our USB3.0 >> re-drivers that can delay the negotiation between a device and the >> host past the usual handshake timeout, and if that happens on the >> first insertion, the host controller port will enter in Compliance >> mode as per the xHCI spec. The host controller does not generate a >> Port Status Change (PSC) event as a result of a transition to >> compliance mode so the only way method to detect and resolve the issue >> is to periodically poll the port to check for compliance mode and >> issue a Warm Reset to recover the port. This polling is only required >> if the port had never previously entered U0. > >That sounds like a broken host controller, doesn't it? No, that is proper host controller behavior. The unwanted compliance mode is a side effect of an additional delay added by the redriver. It only happens very occasionally and was discovered during stress testing. This redriver has already shipped in many end-user systems and would affect ANY host controller. >> We implemented a small app to monitor the device's PORTSC registers >> and to issue a warm reset whenever we find the port is in compliance >> mode. Although this seems to work-around the issue, we believe this >> should be implemented on the driver source code for robustness. >> >> Due to your bandwidth limitations, I was told that we should be making >> our own patches and submitting them to you for integration into the >> mainline. > >Who is "your" here? We assumed patches should be started using the latest xHCI dev branch. We will watch your youtube video (http://www.youtube.com/watch?v=LLBrBBImJt4) and see if we still have questions. >And yes, you should be submitting patches yourself, why wouldn't you be? > >> Based on the information I provided about the issue, can you provide >> any advice on how/where the source code the patch should be >> implemented so that it will be acceptable for the mainline and whether >> it should be a menuconfig option. > >You should dynamically detect your controller and do the change for them, no menuconfig option, how would a distro know to set that or not? > >As for where, you are the best one who can determine that, the code is all available for you to modify, is it not? Absolutely, but we wanted to see if there is any input from the community before we start work. >greg k-h -- 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
