• Rafael J. Wysocki's avatar
    PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle · dbdd0f58
    Rafael J. Wysocki authored
    There is a problem with PCMCIA system resume callbacks with respect
    to suspend-to-idle in which the ->suspend_noirq() callback may be
    invoked after the ->resume_noirq() one without resuming the system
    entirely in some cases.  This doesn't work for PCMCIA because of
    the lack of symmetry between its system suspend and system resume
    "noirq" callbacks.
    
    The system resume handling in PCMCIA is split between
    socket_early_resume() and socket_late_resume() which are called in
    different phases of system resume and both need to run for
    socket_suspend() (invoked by the system suspend "noirq" callback)
    to work.  Specifically, socket_suspend() returns an error when
    called after socket_early_resume() without socket_late_resume(),
    so if the suspend-to-idle core detects a spurious wakeup event and
    attempts to put the system back to sleep, that is aborted by the
    error coming from socket_suspend().
    
    Avoid that by using a new socket state flag, SOCKET_IN_RESUME,
    to indicate that socket_early_resume() has already run for the
    socket in which case socket_suspend() will do minimum handling
    and return 0.
    
    This change has been tested on my venerable Toshiba Portege R500
    (which is where the problem has been discovered in the first place),
    but admittedly I have no PCMCIA cards to test along with the socket
    itself.
    
    Fixes: 33e4f80e (ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle)
    Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
    [linux@dominikbrodowski.net: follow same codepaths for both suspend variants; call ->suspend()]
    Signed-off-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
    dbdd0f58
cs_internal.h 5.39 KB