At Wed, 11 Sep 2013 11:45:08 -0400 (EDT), Alan Stern wrote: > > On Wed, 11 Sep 2013, Takashi Iwai wrote: > > > At Wed, 11 Sep 2013 10:54:40 -0400 (EDT), > > Alan Stern wrote: > > > > > > On Wed, 11 Sep 2013, Takashi Iwai wrote: > > > > > > > Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show > > > > mysterious wakeups after shutdown occasionally. After discussing with > > > > BIOS engineers, they explained that the new BIOS expects that the > > > > wakeup sources are cleared and set to D3 for all wakeup devices when > > > > the system is going to sleep or power off, but the current xhci driver > > > > doesn't do this properly (partly intentionally). > > > > > > > > This patch introduces a new quirk, XHCI_HSW_SPURIOUS_WAKEUP, for > > > > fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci > > > > shutdown ops as done in xhci_stop(), and setting the device to PCI D3 > > > > at shutdown and remove ops. > > > > > > What happens if xhci-hcd is unloaded and then loaded again? The probe > > > function expects the device to be in D0, not in D3hot. Therefore the > > > second time around, probe will fail. > > > > Reloading the module works on the test machines fine. > > Was the kernel on the test machines built with CONFIG_PM_RUNTIME > disabled? Good point. I'll check whether it works without CONFIG_PM_RUNTIME. > > > What happens if xhci-hcd was never loaded in the first place? How will > > > the controller get put into D3 then? > > > > If no xhci driver is loaded at all, the problem doesn't happen. > > The problem is introduced solely by loading the xhci driver. > > > > > Can somebody ask the BIOS engineers to fix their BIOS? There's no > > > reason wakeup devices should have to be reset and put in D3; it should > > > be sufficient that they are disabled for wakeup. > > > > It seems that this will be fixed in the BIOS side, too. But, the > > problematic BIOS is still on the shipped machines that will appear in > > the market sooner, unfortunately. > > People can update the BIOS, if a fix is available. It'd be wonderful if we could rely on BIOS upgrade path... but you know well the reality, no? ;) thanks, Takashi -- 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
