On Mon, 26 Aug 2013, Sarah Sharp wrote: > > By the way, I just noticed your Google+ posting about this. I think > > you (and perhaps the engineers you spoke with) may have misunderstood > > what Table 7-14 means when it lists 10 ms as the _minimum_ value for > > TRSMRCY. > > > > This delay value is a requirement on the OS. The host system must not > > access the device until at least 10 ms after the resume is complete. > > The system can wait longer than that if it wants -- that's why 10 ms is > > a minimum. It just has to avoid accessing the device sooner. > > > > A _minimum_ value on the host side translates into a _maximum_ value on > > the device side. The device can safely assume that it can spend up to > > 10 ms getting back into shape after a resume, but no more. After 10 > > ms, the host may try to communicate with it. > > After re-reading the spec, I agree with your analysis. However, the > fact that chipset designers misinterpreted the spec means there may be > hardware out there that needs a longer timeout. The spec should have > been normative on both the software and the hardware, saying something > like: > > "The USB System Software must provide a 10 ms resume recovery time > (TRSMRCY) during which it will not attempt to access any device > connected to the affected (just-activated) bus segment. The host > controller and device must be ready for communication after the resume > recovery time (TRSMRCY) expires."
See, that's not quite right. The host controller has to be ready for communication long before TRSMRCY expires. In fact, the host controller has to start sending SOF packets within 3 ms of the end of the resume signalling (to prevent the device from going back into suspend). It _would_ be correct to add that the device must be ready for communication after TRSMRCY expires, but this should be understood implicitly. I think the spec is sufficiently clear in this regard. And it's not obvious (to me at least) that the chipset designers misinterpreted it -- but then, I haven't talked to them directly. > I have heard reports of USB devices disconnecting from the bus and > reconnecting after remote wakeup. I've personally experienced this with > one of my PL2303 USB serial adapters, although it has since died, so I > can't retest. Such behavior wouldn't be surprising in the least. It's the sort of thing that caused us to add the RESET_RESUME quirk. > Another company (whose email I ironically lost due to a failed transfer > to a USB 3.0 backup drive) had bus traces showing the root cause of a > disconnect on resume from remote wakeup. Occasionally, the host > controller was sending the SoFs too soon on resume, and the device would > interpret it as a low-speed chirp. ? There is no such thing as a low-speed chirp. Did you mean a high-speed chirp? > The device would disconnect, and > transform from a high speed device to a low speed device. I don't > think increasing the 10 ms time out will help at all in this case, but > you did ask what USB device disconnect scenarios I've seen. Yeah, that's a bad one. There's not much we can do about the HC sending SOF packets too soon. > If users do see device disconnects on remote wakeup resume, we should > see if increasing the timeout helps. Certainly. > Ah, so there is an analogous issue in EHCI. Basically, the EHCI driver > waiting for the PORT_RESUME bit to be clear is equivalent to the xHCI > driver waiting for the port to enter U0. I agree that this seems like > an xHCI driver issue, and I'll fix it in the driver. Okay. It may turn out that some devices still require TRSMRCY to be longer than 10 ms, even after your fix. Such behavior wouldn't be specific to xHCI, though; it would apply equally well to EHCI connections. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
