On Wed, Mar 06, 2013 at 10:12:14AM -0500, Alan Stern wrote: > On Tue, 5 Mar 2013, Sarah Sharp wrote: > > > static void compliance_mode_recovery(unsigned long arg) > > { > > ... > > for (i = 0; i < xhci->num_usb3_ports; i++) { > > temp = xhci_readl(xhci, xhci->usb3_ports[i]); > > if ((temp & PORT_PLS_MASK) == USB_SS_PORT_LS_COMP_MOD) { > > /* > > * Compliance Mode Detected. Letting USB Core > > * handle the Warm Reset > > */ > > > > What happens when the xHCI host controller goes into D3cold due to > > runtime PM? The port status registers will read as all f's, so we will > > miss any transitions to the compliance mode that happened before or > > during the transition to D3cold. > > > > This code probably needs to wake up the host controller and keep it from > > suspending until all the ports can be read. > > > > Alan, would the right way to do that be a get/put call into the runtime > > PM core? > > If xhci_suspend deletes the Compliance Mode Recovery timer then the > timer will never fire while the controller is in D3cold. The problem > won't arise. Alex, Can the USB 3.0 port go into the Inactive sate while the host is in D3hot or D3cold? If so, will we see a PME that will cause the USB core resume the host? I'm concerned that if we don't get a port status change event when the port goes into the Inactive state, then we won't get an interrupt if the port transitions to the Inactive state while the host is in D3. If the ports can't go into the Inactive state while the host is in D3, then I agree with Alan that it's fine to delete the timer in xhci_suspend. However, if the ports can to into the Inactive state and we won't get a PME, then we have to keep the timer running while the xHCI host is runtime suspended. 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