Hi Sarah, Tony, On 2/27/2013 6:20 PM, Sarah Sharp wrote:> On Wed, Feb 27, 2013 at 04:41:45PM -0500, Alan Stern wrote: > Well, at this point, I have to say that Alex knows more about the quirk > than I do. However, my gut feeling is that bus_suspend/resume is not > the right place to stop the compliance timer. > > What I understood was that the Synopsis electrical part could cause USB > 3.0 ports to go into Inactive mode with no port status change event > generated, but only if all ports hadn't been into the U0 status once > since boot/system resume. You are right, a port is subject to suffer the Compliance mode condition only if it hasn't previously entered U0. That is way the timer stops only if all ports have seen U0, otherwise it has to remain running. > > I don't know if "all ports" means "all USB 3.0 ports" or "all ports on > the host". I don't know if the ports can go into the Inactive mode when > the port is suspended, like when all USB 3.0 ports are suspended in > xhci_bus_suspend. This issue only hits to USB 3.0 ports since that part only touches USB3 lines. > I would like be conservative here, and keep as much of the current code > we have (with the compliance timer being manipulated in xhci_suspend and > xhci_resume). That was the code that was submitted by TI, and we should > stick as close to it as possible, without further information from Alex. > Basically, I'd like Tony to make his first patch work, rather than > pursuing moving the timer manipulation to xhci_bus_suspend/resume. > > Sarah Sharp > -- 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
