dev_pm_genpd..._next_wakeup(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… dev_pm_genpd_set_next_wakeup(9) πŸ’…

okay so this is from the Kernel API Manual and it's literally the whole vibe of "hey bestie, heads up, a wakeup is coming" ✨


✨ NAME ✨

dev_pm_genpd_set_next_wakeup β€” the little function that tells the PM framework an impending wakeup is on its way 🫢


🌸 SYNOPSIS 🌸

void dev_pm_genpd_set_next_wakeup (struct device *dev , ktime_t next );

πŸŽ€ ARGUMENTS πŸŽ€

  • dev β€” the device you're handling, bestie. this is the main character of the call πŸ’…
  • next β€” the impending interrupt/wakeup for the device. like, when it's gonna pop off next ⏰

πŸ¦‹ DESCRIPTION πŸ¦‹

So this bad boy lets devices inform of the next wakeup. That's it, that's the job. πŸ’–

Now, the fine print, and no cap you gotta read this:

  • It's assumed that the users guarantee that the genpd wouldn't be detached while this routine is getting called. Like, you promise. Pinky swear. 🀝
  • Additionally, it's also assumed that dev isn't runtime suspended (RPM_SUSPENDED). Not that. Never that. πŸ™ˆ
Although devices are expected to update the next_wakeup after the end of their usecase as well, it is possible the devices themselves may not know about that, so stale next will be ignored when powering off the domain. 🧚

Translation: if the device leaves stale info lying around because it literally didn't know any better, the power-off path is just gonna side-eye it and ignore it. Not the device's fault, we still love it. πŸ’œ


🌈 SEE ALSO 🌈

the kernel file:

./drivers/pmdomain/core.c

and the whole friend group, fr fr πŸ‘‘:


and that's the whole page, bestie ✨ you ate that πŸ’…

sign-off time πŸŽ€ β€” this one comes from ./drivers/pmdomain, dated October 2026, and the page is filed under dev_pm_genpd..._next_wakeup(9). iykyk πŸ’–πŸ¦‹πŸŒΈ

πŸ“¦ where this page comes from