Runtime Suspend Is Not System Suspend: Test Both Paths Without Mixing Their Guarantees
A device passing autosuspend tests has not yet passed system-suspend tests. Runtime PM manages an individual device while the system continues running. System sleep coordinates a wider transition, with different callback phases, resource availability, and wake policy. Test both paths from both active and already runtime-suspended starting states.
Applicability: this procedure uses Linux v6.12 device PM. The example bus peripheral and failures are hypothetical. Hardware retention and supported system-sleep states remain platform-specific. Hibernation has additional freeze, thaw, poweroff, and restore behavior and is not covered by this suspend/resume matrix.
1. Record the path before describing the failure
Identify the requested system state, selected platform sleep mode, device runtime status immediately beforehand, and driver/subsystem callback implementation. A report saying “resume failed” is incomplete if nobody knows whether it followed runtime idle, suspend-to-idle, or a deeper platform transition.
The v6.12 runtime-PM documentation describes runtime_suspend, runtime_resume, and runtime_idle callbacks. The selected subsystem may handle the operation itself or invoke the driver’s callback. Instrument the effective path rather than assuming every driver callback is always reached.
Keep software state separate from hardware observations. Runtime-suspended means the framework’s contract for the device has been established; it is not a universal statement that every supply is off. A device may retain more state during runtime idle than during system sleep.
2. Build a phase and resource matrix
Use rows for runtime_suspend/runtime_resume and the system prepare, suspend, suspend_late, suspend_noirq, resume_noirq, resume_early, resume, and complete phases. Mark callbacks that are absent or intentionally skipped rather than filling those rows with imagined calls.
For each implemented row, list the resources it uses: bus transactions, interrupt completion, workqueues, clocks, regulators, retained register state, and child-device access. Add the required precondition and the state left for the next phase. This turns a callback list into an executable review question: can each resource actually support that operation at that point?
The v6.12 suspend-and-interrupts guide explains that ordinary device IRQ handling is disabled before the noirq phase and restored afterward in resume. A transfer helper that waits for a normal interrupt completion cannot be assumed usable there simply because it worked from runtime_resume. Special interrupt flags have narrower contracts and are not a generic workaround.
For a hypothetical I2C-attached peripheral, compare a runtime-resume register read completed by a normally operating controller with the same read moved into resume_noirq. If the controller’s completion path is unavailable then, changing the timeout only delays the failure. Place work in a supported phase or use a specifically supported transport path.
3. Treat already-suspended devices as a separate input
System suspend can begin while the device is already runtime-suspended. The runtime-PM guide notes that system-sleep wake settings or power levels may differ, requiring a temporary resume and another suspension. Leaving the device untouched is an integration decision, not an automatic consequence of its idle status.
The v6.12 device-PM guide documents conditional direct completion: an eligible runtime-suspended device and its descendants can skip the usual system suspend/resume phases when preparation and policy permit it. The complete callback then follows prepare and must leave a consistent state. Driver flags can prevent or further qualify this optimization.
Do not diagnose missing callbacks as lost execution until checking this path. Conversely, do not request direct completion just to eliminate failing callbacks. First establish that the retained hardware state, wake configuration, and child requirements really permit it.
Record the actual direct-complete outcome in the test trace. A source-level expectation that the optimization should apply is weaker than evidence of which phases executed in the tested topology.
4. Separate runtime permission from system policy
The device-PM guide specifies that power/control set to on prevents runtime power management, but does not prevent the device from participating in system-wide sleep. Using that setting to keep a device active during a controlled test does not exempt it from the later system transition.
Similarly, wake permission and device restoration need separate entries in the matrix. A device allowed to signal runtime wake may have different system-sleep permissions. Do not copy a runtime test’s wake result into the system-sleep acceptance column.
After system resume, require the framework’s runtime state and the actual device state to agree. If the subsystem intentionally leaves the device runtime-suspended, the next legitimate I/O request must resume it correctly. If it brings the device active, hardware access must be operational before the driver advertises readiness.
5. Exercise four independent starting conditions
| Proposed case | Evidence to capture |
|---|---|
| Runtime idle then runtime I/O | Runtime callback pair and first completed transaction. |
| System sleep from runtime-active | System phases, resources used, and first post-resume I/O. |
| System sleep from runtime-suspended | Any temporary resume, skipped phases, direct completion, and final runtime state. |
| System wake followed by another autosuspend | Correct state accounting and later runtime suspend/resume behavior. |
Repeat the supported system modes separately. Do not assume a passing suspend-to-idle case establishes retention or firmware behavior for a deeper mode. Preserve the exact kernel build, driver revision, device tree or firmware description, and relevant power policy with each run.
For every successful transition, execute a representative real transaction afterward. A callback returning success does not prove the peripheral produced valid data, completed a write, or restored its interrupt path. Keep first-operation correctness distinct from eventual recovery after repeated retries.
6. Use differences to localize the defect
If runtime resume passes but system resume from active fails, inspect system-only phases and resources first. If only the already-runtime-suspended case fails, inspect retained-state assumptions, wake-policy changes, and skip decisions. If the first system resume works but later autosuspend fails, inspect state reconciliation and reference accounting.
A shared implementation function can reduce duplicated code, but it does not make its callers’ preconditions identical. Document which resources and states make reuse valid. Avoid invoking a runtime callback directly merely to bypass the framework’s sequencing.
No suspend or resume test was performed for this article. The deliverable is a callback/resource matrix and a four-condition test record. Acceptance requires a coherent state before and after each supported transition, plus correct subsequent I/O, rather than treating all operations named resume as one interchangeable path.
