STRUCT PLATFORM_SUSPEND_OPS(9)

💖 NAME 💖

okay so welcome to the Kernel API Manual, section 9, page struct platform_suspend_ops(9) — bestie, this is literally the callback struct for managing platform-dependent system sleep states. the whole sleep-state situation is in here ✨

struct platform_suspend_ops — Callbacks for managing platform dependent system sleep states. 💅

🦋 SYNOPSIS 🦋

struct platform_suspend_ops {
    int (*valid)(suspend_state_t state);
    int (*begin)(suspend_state_t state);
    int (*prepare)(void);
    int (*prepare_late)(void);
    int (*enter)(suspend_state_t state);
    void (*wake)(void);
    void (*finish)(void);
    bool (*suspend_again)(void);
    void (*end)(void);
    void (*recover)(void);
 };

👑 Members 👑

okay so each one of these is a little callback bestie, and they all have a job. let's get into it 🫶

• valid — this one figures out if a given system sleep state is supported by the platform. valid (ie. supported) states are advertised in /sys/power/state. but lowkey note: it still may be impossible to enter a given system sleep state if the conditions aren't right 👀. also, there's the suspend_valid_only_mem function available that can be assigned to this if the platform only supports mem sleep.
• begin — initialises a transition to the given system sleep state. begin is executed right prior to suspending devices. any information conveyed to the platform code by begin should be disregarded by it as soon as end is executed. if begin fails (ie. returns nonzero), prepare, enter, and finish will not be called by the PM core, periodt. this callback is optional. however, if it is implemented, the argument passed to enter is redundant and should be ignored. noted ✨
• prepare — prepares the platform for entering the system sleep state indicated by begin. prepare is called right after devices have been suspended (ie. the appropriate .suspend method has been executed for each device) and before device drivers' late suspend callbacks are executed. it returns 0 on success or a negative error code otherwise, in which case the system cannot enter the desired sleep state (prepare_late, enter, and wake will not be called in that case). 😭
• prepare_late — finishes preparing the platform for entering the system sleep state indicated by begin. prepare_late is called before disabling nonboot CPUs and after device drivers' late suspend callbacks have been executed. it returns 0 on success or a negative error code otherwise, in which case the system cannot enter the desired sleep state and enter will not be executed. no cap.
• enter — enters the system sleep state indicated by begin or represented by the argument if begin is not implemented. this callback is mandatory 👑. it returns 0 on success or a negative error code otherwise, in which case the system cannot enter the desired sleep state.
• wake — called when the system has just left a sleep state, right after the nonboot CPUs have been enabled and before device drivers' early resume callbacks are executed. this callback is optional, but should be implemented by the platforms that implement prepare_late. if implemented, it is always called after prepare_late and enter, even if one of them fails. the way that's so thorough ✨
• finish — finishes wake-up of the platform. finish is called right prior to calling device drivers' regular suspend callbacks. this callback is optional, but should be implemented by the platforms that implement prepare. if implemented, it is always called after enter and wake, even if any of them fails. it is executed after a failing prepare. okay werk 💅
• suspend_again — returns whether the system should suspend again (true) or not (false). if the platform wants to poll sensors or execute some code during suspended without invoking userspace and most of devices, the suspend_again callback is the place — assuming that periodic-wakeup or alarm-wakeup is already setup. this allows to execute some codes while being kept suspended in the view of userland and devices. iykyk 🫶
• end — called by the PM core right after resuming devices, to indicate to the platform that the system has returned to the working state or the transition to the sleep state has been aborted. this callback is optional, but should be implemented by the platforms that implement begin. accordingly, platforms implementing begin should also provide an end which cleans up transitions aborted before enter. don't skip this one bestie 💅
• recover — recovers the platform from a suspend failure. called by the PM core if the suspending of devices fails. this callback is optional and should only be implemented by platforms which require special recovery actions in that situation. special circumstances only, fr fr.

🌈 SEE ALSO 🌈

Kernel file ./include/linux/suspend.h — then the whole squad: suspend_set_ops(9), pm_suspend_via_firmware(9), pm_resume_via_firmware(9), pm_suspend_no_platform(9), arch_suspend_disable_irqs(9), arch_suspend_enable_irqs(9), struct platform_hibernation_ops(9), pm_pr_dbg(9). go read those too, bestie 🦋

this page comes from ./include/linux, dated October 2026, and it's all about struct platform_suspend_ops(9) — mwah 💋