On Wed, Feb 27, 2013 at 04:41:45PM -0500, Alan Stern wrote:
> On Wed, 27 Feb 2013, Tony Camuso wrote:
> > I was able to make the scheme work by adding the following
> > immediately upon entering compliance_recovery_node_timer_init()
> >
> > if (timer_pending(&xhci->comp_mode_recovery_timer)) {
> > xhci_dbg(xhci, "Compliance Mode Recovery Timer already active.\n");
> > return;
> > }
>
> > On 02/26/2013 11:11 AM, Alan Stern wrote:
> > > On Tue, 26 Feb 2013, Tony Camuso wrote:
> This is normal. xhci_bus_suspend is called once for the legacy USB-2
> root hub (usb3) and then again for the USB-3 root hub (usb4). I'd
> guess that the compliance-mode recovery timer needs to be associated
> with the USB-3 root hub only, but I don't know.
>
> At this point I'd say to ask Sarah. She knows a lot more about the
> big picture than I do.
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.
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.
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
