try_then_request_governor(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

try_then_request_governor β€” bestie, this is the little helper that goes looking for a governor and, if it can’t find it, asks for the module and tries again. Periodt. πŸ’…

✨ SYNOPSIS ✨

struct devfreq_governor * try_then_request_governor (const char *name );

πŸŽ€ ARGUMENTS πŸŽ€

  • name β€” the name of the governor, like the little name tag at the function party 🏷️✨

πŸ¦‹ DESCRIPTION πŸ¦‹

Okay so picture this: try_then_request_governor searches the list of devfreq governors, and if the one you want isn’t there, it requests the module and tries again. Iconic persistence, honestly. 🫢

This whole situation can happen when both drivers β€” the governor driver and the driver that calls devfreq_add_device β€” are built as modules. Yes, both of them. Modules. It’s giving β€œwe’re all modular here.” 😭

⚠️ Heads up, bestie: devfreq_list_lock should be held by the caller. Like, actually held. Don’t come in without it. πŸ”’πŸ’€

It returns the matched governor’s pointer, or an error pointer. That’s the vibe check: pointer on success, error pointer when it’s not giving. 🌸

🌈 SEE ALSO 🌈

Kernel file ./drivers/devfreq/devfreq.c, plus the whole friend group:


And that’s the whole page, bestie. This little gem lives in ./drivers/devfreq, and it’s stamped October 2026 β€” so yeah, she’s current, she’s cute, she’s try_then_request_governor(9). πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from