On Thu, Apr 18, 2013 at 8:18 AM, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > 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? Yes. You can set pci_dev->no_d3cold = true in runtime_suspend callback of device driver. Then the device will never be put into D3COLD state. Best Regards, Huang Ying -- 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
