pm_runtime_autosuspend(9)

📦 version 7.3.1, in nixpkgs unstable

✨ NAME ✨

pm_runtime_autosuspend — update the last access time and set up autosuspend of a device. Yep, bestie, this is the pm_runtime_autosuspend(9) page from the Kernel API Manual, and we're about to make runtime power management make sense 💅.

🌈 SYNOPSIS 🌈

int pm_runtime_autosuspend (struct device *dev );

🎀 ARGUMENTS 🎀

  • dev — the target device. That's the device getting the whole last-access-time-plus-autosuspend treatment, and honestly it's the only argument invited to this function party 🫶.

🦋 DESCRIPTION 🦋

Okay so here's the tea: first it updates the last access time, then it sets up autosuspend of dev or suspends it — depending on whether or not autosuspend is enabled for it — without engaging its "idle check" callback. No idle check callback, no drama, periodt ✨.

💖 RETURN 💖

Vibe check on return values, bestie — memorize these fr fr:

  • 1 — success; device was already suspended. Iconic.
  • 0 — success. Slay.
  • -EINVAL — Runtime PM error. Not the vibe.
  • -EACCES — Runtime PM disabled. Blocked bestie 😭.
  • -EAGAIN — Runtime PM usage counter non-zero or Runtime PM status change ongoing. Try-again energy.
  • -EBUSY — Runtime PM child_count non-zero. Busy busy.
  • -EPERM — Device PM QoS resume latency 0. The kernel said nope.
  • -ENOSYS — CONFIG_PM not enabled. Config said no.
Other values and conditions for the above values are possible as returned by Runtime PM suspend callbacks. So don't come for me if a callback adds its own plot twist 🔥.

👑 SEE ALSO 👑

Kernel file ./include/linux/pm_runtime.h — and now the whole runtime PM friend group, no cap:

Sign-off time: written in ./include/linux, October 2026 edition of pm_runtime_autosuspend(9) — mwah, love u, bye 💋🫶

📦 where this page comes from