On Thu, 10 May 2012, Quach, Brian wrote: > >> 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. For those of us not intimately involved in hardware design, can you explain: What is a redriver? Alan Stern -- 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
