Comment 136 for bug 1419355

The XHCI_SPURIOUS_WAKEUP flag was originally set for both Lynxpoint and Lynxpoint LP back in 2013.
It has since then been set on and off for some time now for due to different regressions. I'll re-check with the hw team about the and add it again if necessary.

The history of this flag is best described in the latest patch that touched it:

commit fd7cd061adcf5f7503515ba52b6a724642a839c8
Author: Laura Abbott <email address hidden>
Date: Mon Oct 12 11:30:13 2015 +0300

    xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

    We received several reports of systems rebooting and powering on
    after an attempted shutdown. Testing showed that setting
    XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT
    quirk allowed the system to shutdown as expected for LynxPoint-LP
    xHCI controllers. Set the quirk back.

    Note that the quirk was originally introduced for LynxPoint and
    LynxPoint-LP just for this same reason. See:

    commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell")

    It was later limited to only concern HP machines as it caused
    regression on some machines, see both bug and commit:

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
    commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines")

    Later it was discovered that the powering on after shutdown
    was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP
    machine suffered from spontaneous resume from S3 (which should
    not be related to the SPURIOUS_WAKEUP quirk at all). An attempt
    to fix this then removed the SPURIOUS_WAKEUP flag usage completely.

    commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell")

    Current understanding is that LynxPoint-LP (Haswell ULT) machines
    need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and
    plain Lynxpoint (Haswell) machines may _not_ have the quirk
    set otherwise they again will restart.