acpi_dev_pm_get_state(9)

💅 acpi_dev_pm_get_state(9) 💅

okay so we're in the Kernel API Manual bestie, and today's main character is acpi_dev_pm_get_state. the way this function just knows what power state your ACPI device wants to be in? obsessed. let's get into it 🫶

---

✨ NAME ✨

acpi_dev_pm_get_state — Get preferred power state of ACPI device. that's it, that's the whole vibe check 💖

---

🌸 SYNOPSIS 🌸

int acpi_dev_pm_get_state (struct device *dev , struct acpi_device *adev
, u32 target_state , int *d_min_p , int *d_max_p );

look at those parameters go. five of them. no notes 😭✨

---

🎀 ARGUMENTS 🎀

• dev — the device whose preferred target power state we're returning. it's giving "who am I really" energy. 💅
• adev — the ACPI device node that corresponds to dev. they're a matched set, iykyk. 🦋
• target_state — the system state we're matching the resultant device state against. like, what state is the system in, because that changes everything ngl. 🌈
• d_min_p — location to store the highest power state available to the device. yes, min pointer, highest state. it's confusing but that's the lore. 🤡
• d_max_p — location to store the lowest power state available to the device. same deal, flipped. don't fight it, just respect it. 🙈

---

💜 DESCRIPTION 💜

so the whole point: find the lowest power (highest number) and the highest power (lowest number) ACPI device power states that your device can be in while the system is sitting in the state represented by target_state. and then — slay — it stores the integer numbers representing those stats in the memory locations pointed to by d_max_p and d_min_p, respectively. note the swap, because of course 😭 the numbers are numbers, the pointers are pointers, it's fine, we're fine.

⚠️ bestie please listen to me on this one: callers must ensure that dev and adev are valid pointers, and that adev actually corresponds to dev before using this function. no cap. like, actually verify it. don't just assume. 💀

Returns 0 on success, or -ENODATA when one of the ACPI methods fails or returns a value that doesn't make sense. and here's the important bit: the memory locations pointed to by d_max_p and d_min_p are only modified on success — so if it flops, your pointers stay exactly as they were. cute, respectful, boundaries. 👑

---

👑 SEE ALSO 👑

Kernel file ./drivers/acpi/device_pm.c, plus the whole friend group right here — go say hi:

• acpi_power_state_string(9)
• acpi_device_get_power(9)
• acpi_device_set_power(9)
• acpi_device_fix_up_power(9)
• acpi_device_fix_up_power_extended(9)
• acpi_device_fix_up_power_children(9)
• acpi_dev_power_up_children_with_adr(9)
• acpi_dev_power_state_for_wake(9)
• acpi_add_pm_notifier(9)
• acpi_remove_pm_notifier(9)
• acpi_pm_device_sleep_state(9)
• acpi_pm_notify_work_func(9)
• acpi_device_wakeup_enable(9)
• acpi_device_wakeup_disable(9)
• acpi_pm_set_device_wakeup(9)
• acpi_dev_pm_low_power(9)
• acpi_dev_pm_full_power(9)
• acpi_dev_suspend(9)
• acpi_dev_resume(9)
• acpi_subsys_runtime_suspend(9)
• acpi_subsys_runtime_resume(9)
• acpi_subsys_prepare(9)
• acpi_subsys_complete(9)
• acpi_subsys_suspend(9)
• acpi_subsys_suspend_late(9)
• acpi_subsys_suspend_noirq(9)
• acpi_subsys_resume_noirq(9)
• acpi_subsys_resume_early(9)
• acpi_subsys_resume(9)
• acpi_subsys_freeze(9)
• acpi_subsys_restore_early(9)
• acpi_subsys_poweroff(9)
• acpi_subsys_poweroff_late(9)
• acpi_subsys_poweroff_noirq(9)
• acpi_dev_pm_detach(9)
• acpi_dev_pm_attach(9)
• acpi_storage_d3(9)
• acpi_dev_state_d0(9)

---

and that's the whole page, bestie — go forth and get those power states 💅✨

sign-off time 🎀 this one lives in ./drivers/acpi, dated October 2026, and it was a whole vibe. mwah 💖