dev_pm_genpd_set_hwmode(9)

📦 version 7.3.1, in nixpkgs unstable

💅 dev_pm_genpd_set_hwmode(9) 💅

okay so bestie, welcome to the Kernel API Manual — yes, that manual, the one with all the genpd lore. this page is about dev_pm_genpd_set_hwmode, and it's honestly a little sleeper hit, so let's get into it 💖

✨ NAME ✨

dev_pm_genpd_set_hwmode — set the HW mode for the device and its PM domain. both of them. together. slay 🫶

🌸 SYNOPSIS 🌸

int dev_pm_genpd_set_hwmode (struct device *dev , bool enable );

🎀 ARGUMENTS 🎀

  • dev — the Device whose HW-mode is getting changed. it's the main character of this call, no cap 👑
  • enable — the value that sets or unsets the HW-mode. that's it. that's the whole vibe check 🦋

💜 DESCRIPTION 💜

so here's the tea: some PM domains can legitimately just rely on HW signals to control the power for a device. iconic behavior tbh ⚡

and because a consumer driver might want to switch the behaviour for its device at runtime — which, lowkey, can be a whole win from a latency or energy point of view — it can call this function. yes, this exact one. you found it 🎯

⚠️ okay important one, don't skip this: it is assumed that the users guarantee that the genpd wouldn't be detached while this routine is getting called. that's on you, bestie. keep that domain alive, fr fr 💀

🔥 RETURN 🔥

returns 0 on success, and negative error values on failures. that's the whole deal ✨

🦋 SEE ALSO 🦋

first up, the source of truth, the actual file:

  • Kernel file ./drivers/pmdomain/core.c 📁

and now the extended genpd family reunion — every single one of them, because we don't do half-finished lists here 🎀

like, the way that list just keeps going. main character energy from the entire power domain subsystem, honestly 👑

that's the page, bestie!! 🫶 sourced straight from ./drivers/pmdomain and dated October 2026, manual name and all — go forth and toggle that HW mode responsibly 💅✨

📦 where this page comes from