dev_pm_opp_set_config(9)

📦 version 7.3.1, in nixpkgs unstable

✨ dev_pm_opp_set_config(9) ✨

okay so real talk bestie, this is a page from the Kernel API Manual and it's literally the glow-up cheat sheet for telling the kernel how a device's OPPs work 💅 (OPP = operating performance points, iykyk). One call, all the config, no scrambling around. Obsessed.

🎀 SYNOPSIS 🎀

int dev_pm_opp_set_config (struct device *dev , struct dev_pm_opp_config
*config );

🌸 ARGUMENTS 🌸

  • dev — the struct device you're setting the config up for. Your main character device, basically 🫶
  • config — the OPP configuration itself. This is the whole vibe package 🎁

🦋 DESCRIPTION 🦋

So here's the tea: this function lets all of the device OPP configurations get done at once. One call, everything handled, no twenty separate setup steps. We love efficiency 💖

Timing matters, ngl: you must call this before any OPPs are initialized for the device. Not after, not "eh, close enough". Before. 🙈

Also very valid: you can call this multiple times for the same OPP table — like, once for each CPU that shares the same table. Very "share the aux" energy 🎧

But heads up, every single one of those calls has to be balanced by the same number of calls to dev_pm_opp_clear_config so the OPP table can be freed properly. Cleanup is not optional, bestie 😭

When it's done, it hands a token back to the caller. You keep that token and pass it to dev_pm_opp_clear_config later to free the resources. The value of the returned token will be >= 1 for success and negative for errors. And why 1 as the minimum? Because it makes it easy for callers to manage the resource — thoughtful king behavior 👑✨

🔥 SEE ALSO 🔥

Everything else in the OPP cinematic universe:

and that's the whole page, bestie 💜 straight from ./drivers/opp, dated October 2026, and we're back on dev_pm_opp_set_config(9) — go forth and configure responsibly 🧚‍♀️✨

📦 where this page comes from