pm_suspend_via_firmware(9)

🌸 pm_suspend_via_firmware — a whole vibe check for your suspend path 🌸

okay so bestie, welcome to this page from the Kernel API Manual section 9, aka <pink>pm_suspend_via_firmware(9)</pink>. it's short, it's sweet, and it will absolutely save you from doing unnecessary device resets at 3am. let's go 💅

---

✨ NAME ✨

pm_suspend_via_firmware — literally check if the platform firmware is gonna suspend the system for you.

no cap, that's the whole job. 🫶

---

✨ SYNOPSIS ✨

bool pm_suspend_via_firmware (void );

it returns a bool, it takes nothing, and it's giving "i just need to know one thing" energy. 🎀

---

✨ ARGUMENTS ✨

• void — no arguments. zero. none. it's an icon who works alone. void is right there in the parens, that's the whole argument list, periodt.

---

✨ DESCRIPTION ✨

okay so here's the tea, bestie. 🍓

you call this during system-wide power management transitions to sleep states, or during the subsequent system-wide transitions back to the working state. that's the window, that's where you live. ⭐

it returns true if:

• the platform firmware is going to be invoked at the end of the system-wide power management transition (to a sleep state) currently in progress, so it can complete it, or
• the platform firmware has already been invoked in order to complete the last (or preceding) transition of the system to a sleep state.

so basically: "is firmware in the building, or about to be in the building?" that's the vibe check. 🔥

and why does this matter, you ask? so glad you asked. 😭 it matters if the caller needs or wants to carry out some special actions depending on whether or not control is going to be passed to the platform firmware afterwards. for example ✨ the device may need to be reset before letting the platform firmware manipulate it — which is not necessary when the platform firmware is not going to be invoked. see how that saves you a whole pointless reset? main character energy from a boolean, honestly. 👑

it also matters when such special actions may have been carried out during the preceding transition of the system to a sleep state, because they may need to be taken into account. iykyk. 🙈

ngl, this is one of those tiny functions that eats if you use it right — and bites you if you assume the answer. always ask, never assume. 💖

---

✨ SEE ALSO ✨

go read these too, bestie, they're all in their flop era until you do 🦋:

• Kernel file ./include/linux/suspend.h struct platform_suspend_ops(9)
• suspend_set_ops(9)
• pm_resume_via_firmware(9) — the mirror selfie version of this function 💅
• pm_suspend_no_platform(9)
• arch_suspend_disable_irqs(9)
• arch_suspend_enable_irqs(9)
• struct platform_hibernation_ops(9)
• pm_pr_dbg(9)

---

🎀 cute sign-off 🎀

and that's the page!! this whole thing lives under ./include/linux and it was dated October 2026 — yes, the future, we're ahead of schedule, slay. 🌈 this same page is <hotpink>pm_suspend_via_firmware(9)</hotpink> in the Kernel API Manual, so if you ever forget, you know exactly where to find me. go suspend something responsibly, bestie. 💜🧚

bye bye, love u, read your headers 💖✨