drivers/acpi/device_pm.c
Source file repositories/reference/linux-study-clean/drivers/acpi/device_pm.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/acpi/device_pm.c- Extension
.c- Size
- 43940 bytes
- Lines
- 1536
- Domain
- Driver Families
- Bucket
- drivers/acpi
- Inferred role
- Driver Families: exported/initcall integration point
- Status
- integration implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/acpi.hlinux/export.hlinux/mutex.hlinux/pm_qos.hlinux/pm_domain.hlinux/pm_runtime.hlinux/suspend.hfan.hinternal.h
Detected Declarations
function Copyrightfunction acpi_dev_pm_explicit_getfunction acpi_device_set_powerfunction acpi_dev_pm_explicit_setfunction acpi_device_set_powerfunction acpi_bus_set_powerfunction acpi_bus_init_powerfunction acpi_device_fix_up_powerfunction fix_up_power_if_applicablefunction acpi_device_fix_up_powerfunction acpi_device_fix_up_powerfunction acpi_device_update_powerfunction acpi_bus_update_powerfunction acpi_bus_power_manageablefunction acpi_power_up_if_adr_presentfunction busfunction errorsfunction acpi_pm_wakeup_eventfunction acpi_pm_notify_handlerfunction acpi_add_pm_notifierfunction acpi_remove_pm_notifierfunction acpi_bus_can_wakeupfunction acpi_pm_device_can_wakeupfunction powerfunction acpi_pm_device_sleep_statefunction acpi_pm_notify_work_funcfunction __acpi_device_wakeup_enablefunction externalfunction acpi_device_wakeup_disablefunction acpi_pm_set_device_wakeupfunction acpi_dev_pm_low_powerfunction acpi_dev_pm_full_powerfunction intofunction acpi_dev_resumefunction acpi_subsys_runtime_suspendfunction acpi_subsys_runtime_resumefunction acpi_dev_needs_resumefunction acpi_subsys_preparefunction acpi_subsys_completefunction acpi_subsys_suspendfunction acpi_subsys_suspend_latefunction acpi_subsys_suspend_noirqfunction acpi_subsys_resume_noirqfunction acpi_subsys_resume_earlyfunction acpi_subsys_resumefunction acpi_subsys_freezefunction acpi_subsys_restore_earlyfunction acpi_subsys_poweroff
Annotated Snippet
if (parent && state < parent->power.state) {
acpi_handle_debug(device->handle,
"Cannot transition to %s for parent in %s\n",
acpi_power_state_string(state),
acpi_power_state_string(parent->power.state));
return -ENODEV;
}
}
/*
* Transition Power
* ----------------
* In accordance with ACPI 6, _PSx is executed before manipulating power
* resources, unless the target state is D0, in which case _PS0 is
* supposed to be executed after turning the power resources on.
*/
if (state > ACPI_STATE_D0) {
/*
* According to ACPI 6, devices cannot go from lower-power
* (deeper) states to higher-power (shallower) states.
*/
if (state < device->power.state) {
acpi_handle_debug(device->handle,
"Cannot transition from %s to %s\n",
acpi_power_state_string(device->power.state),
acpi_power_state_string(state));
return -ENODEV;
}
/*
* If the device goes from D3hot to D3cold, _PS3 has been
* evaluated for it already, so skip it in that case.
*/
if (device->power.state < ACPI_STATE_D3_HOT) {
result = acpi_dev_pm_explicit_set(device, state);
if (result)
goto end;
}
if (device->power.flags.power_resources)
result = acpi_power_transition(device, target_state);
} else {
int cur_state = device->power.state;
if (device->power.flags.power_resources) {
result = acpi_power_transition(device, ACPI_STATE_D0);
if (result)
goto end;
}
if (cur_state == ACPI_STATE_D0) {
int psc;
/* Nothing to do here if _PSC is not present. */
if (!device->power.flags.explicit_get)
goto no_change;
/*
* The power state of the device was set to D0 last
* time, but that might have happened before a
* system-wide transition involving the platform
* firmware, so it may be necessary to evaluate _PS0
* for the device here. However, use extra care here
* and evaluate _PSC to check the device's current power
* state, and only invoke _PS0 if the evaluation of _PSC
* is successful and it returns a power state different
* from D0.
*/
result = acpi_dev_pm_explicit_get(device, &psc);
if (result || psc == ACPI_STATE_D0)
goto no_change;
}
result = acpi_dev_pm_explicit_set(device, ACPI_STATE_D0);
}
end:
if (result) {
acpi_handle_debug(device->handle,
"Failed to change power state to %s\n",
acpi_power_state_string(target_state));
} else {
device->power.state = target_state;
acpi_handle_debug(device->handle, "Power state changed to %s\n",
acpi_power_state_string(target_state));
}
return result;
no_change:
Annotation
- Immediate include surface: `linux/acpi.h`, `linux/export.h`, `linux/mutex.h`, `linux/pm_qos.h`, `linux/pm_domain.h`, `linux/pm_runtime.h`, `linux/suspend.h`, `fan.h`.
- Detected declarations: `function Copyright`, `function acpi_dev_pm_explicit_get`, `function acpi_device_set_power`, `function acpi_dev_pm_explicit_set`, `function acpi_device_set_power`, `function acpi_bus_set_power`, `function acpi_bus_init_power`, `function acpi_device_fix_up_power`, `function fix_up_power_if_applicable`, `function acpi_device_fix_up_power`.
- Atlas domain: Driver Families / drivers/acpi.
- Implementation status: integration implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.