Power Domains with Multiple Consumers: Test One Device Sleeping While Its Peer Is Active

A device can be runtime-suspended while its shared power domain remains on. Test the device state and domain state separately, then identify the peer, subdomain, policy, or provider decision that keeps the domain active. Treating every successful device suspension as a domain power-off guarantee produces false failures and unsafe workarounds.

Applicability: this article pins Linux v6.12 generic power domains, specifically the genpd runtime path for I/O devices. The two-device domain is hypothetical. System-suspend bookkeeping, CPU domains, firmware-managed details, and hardware retention need separate platform review. No target workload or power-domain transition was executed.

1. Draw membership and hierarchy separately

Identify the actual genpd provider, its attached devices, and its parent/child domains. A device’s bus parent is not necessarily its power-domain parent, and two devices sharing a regulator do not necessarily belong to one genpd. Keep those relationships on separate layers of the topology diagram.

Record the provider driver, firmware description, runtime-PM configuration, domain flags, governor, and supported domain states. Account for virtual devices or attachment mechanisms used by multi-domain consumers. A logical device name alone may not identify every domain claim relevant to the hardware block.

Start with a platform-supported observable domain and harmless workloads. Do not infer undocumented physical island boundaries from a current trace or change the device tree solely to force two blocks into the same test topology.

2. Understand why a successful suspend can leave power on

The v6.12 genpd_runtime_suspend implementation first runs the device-level suspension and stop path. If those succeed, it attempts domain power-off under the domain lock. It does not propagate that power-off attempt’s result as the device runtime-suspend result.

This establishes a useful diagnostic distinction. A successful per-device transition can coexist with a domain power-off refusal. The device has stopped participating in normal I/O under its runtime contract even though a peer or policy still needs the shared domain.

Conversely, a failed device-level suspend or stop operation is different from a later domain veto. Preserve the stage and result. Do not replace all of these observations with one “power management failed” counter.

3. Interpret the one-device allowance correctly

genpd_power_off counts devices that are not runtime-suspended, with additional treatment for IRQ-safe-device/domain compatibility. Its one_dev_on argument accommodates the currently transitioning device, whose runtime state has not yet reached RPM_SUSPENDED while its callback executes.

In the hypothetical two-device case, A is finishing runtime suspend while B remains active. The in-flight A and active B exceed the permitted count, so domain power-off is refused. After A completes, A can correctly report suspended while B continues operating and the domain remains on.

When B later suspends, A is already suspended and B is the one in-flight device. The count can then permit a power-off attempt, subject to the remaining checks. This allowance is not permission to cut power underneath an arbitrary active peer. It exists to account for callback timing in the framework.

Keep this internal detail in source review and trace interpretation. Drivers must not modify the core’s runtime status fields or pass private genpd arguments to force the desired count.

4. Enumerate the other vetoes before calling it a leak

The exact implementation also checks always-on policies, active subdomain accounting, child-domain depth, governor permission, and the provider’s power-off result. A domain may remain on even when all visible device runtime-status files say suspended.

Distinguish the governor’s per-device suspend decision from its domain power-down decision. The former can reject device suspension earlier; the latter can prevent a domain transition after device suspension succeeded. These decisions should appear at different points in the diagnostic ledger.

Inspect whether a child domain has reached the state required for its parent to turn off. A shallow child state is not necessarily sufficient. Likewise, an IRQ-safe device in a domain whose callbacks may sleep has a specific compatibility restriction; do not “fix” it by changing flags without proving callback context safety.

A provider rejection deserves its own investigation. Save the requested state and provider error, then examine the platform-specific prerequisites. Neither forcing the rail off nor repeatedly requesting suspend establishes the missing contract.

5. Run a peer-activity matrix

Propose a controlled sequence with A and B initially doing valid I/O. Stop A through its normal owner while B continues a verified workload. Capture A’s completed runtime transition, B’s actual progress, and domain state. Repeat with their roles reversed.

Next stop both and allow the normal idle policy to run. Record whether the domain becomes eligible, whether a power-off callback runs, and its result. If the domain stays on, identify a specific remaining veto rather than declaring the final device failed to suspend.

Resume A while B stays suspended, and require A’s first useful transaction to succeed. Then resume B. Repeat with the opposite order and a peer becoming active near the other’s idle transition. Evaluate framework serialization and actual operations, not an assumed fixed timing gap.

The runtime-PM contract requires consumers to coordinate hardware access with runtime state. A suspended A must not issue unprotected accesses merely because B happens to keep the domain on. That bug often stays hidden until B finally becomes idle.

6. Observe three layers without conflating them

Keep separate columns for per-device runtime state, genpd software state/accounting, and hardware observations supported by the platform. Trace callbacks or use available diagnostic interfaces with the tested kernel configuration. Diagnostic file availability and format are not a universal application ABI.

Software domain OFF can describe a selected provider state rather than zero voltage everywhere. Some domains have multiple idle states, and hardware or firmware can impose further behavior. Confirm the meaning of the selected state before interpreting a rail probe or residency counter.

A whole-board current decrease cannot identify which domain changed on its own. Correlate the provider transition with a suitable counter or documented measurement point, and preserve unrelated activity. No current reduction is predicted by the two-device model.

7. Release an eligibility explanation

The final artifact should name domain membership, the peer workload, device callback outcomes, each relevant veto, provider results, and first-I/O recovery. Record the domain state that actually occurred instead of reducing every attempt to a binary sleep label.

Accept partial shutdown when the inactive device obeys its runtime contract and the active peer remains correct. Accept domain power-off only when the complete eligibility and provider path supports it. Those are complementary outcomes, and each deserves its own test evidence.