All right, I've finally come back to this long thread. To sum up: xHCI hosts that have the effected TI redriver may lose device connect events when in D3hot or D3cold, if the port goes into Compliance Mode. Effected xHCI hosts may lose device connect events (or wake events, if those happen after the failed connect event) while the system is suspended or hibernated, and there's nothing software can do about it. The current timer code to poll port status registers for compliance mode fails in two ways: 1. When hibernate occurs, the frozen image stored in memory still has the compliance mode polling timer running. On resume from hibernate, re-starting that timer in xhci_resume causes list corruption, leading to an NMI and system lock up. 2. If effected xHCI hosts are allowed to go into D3cold, power is removed, and we cannot read the port status registers to see if a port is in compliance mode, since they will be all F's. To solve #1, I prefer Tony's patch that stops and restarts the compliance timer on resume from hibernate: http://marc.info/?l=linux-usb&m=136148109502971&w=2 However, looking at it again, there's an issue if the xHCI restore registers operation fails on resume from suspend, when (temp & STS_SRE) is true. xhci_init will get called, which will re-init the compliance timer. We'll move to the done label, and hibernate will be false, and we'll attempt to re-init the compliance timer again, which will again cause list corruption, NMIs, and a lockup. I'll send a refresh patch that fixes this shortly. To solve #2, there are two possible solutions. The first option is to disable runtime PM for effected xHCI hosts entirely, with a call to pm_runtime_get_noresume in the xHCI PCI probe function, and a call to pm_runtime_put_noidle in the release function. However, that seems a bit harsh to completely disable xHCI PCI host suspend, and cause user systems to have increased power consumption. The second option is to disable D3cold only. I think this is the better option, but it's not clear how best to do this. It seems like the xHCI PCI probe function needs to set d3cold_allowed to false in the parent PCI structure. However, I think that userspace can overwrite that value and re-enable D3cold through the d3cold_allowed sysfs file. We don't want that to happen in this case. Ying, is there a way to permanently disable D3cold, so that userspace can't re-enable it? 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
