Shared Regulators: Verify That Disabling One Consumer Does Not Remove Another’s Supply
Disabling a shared regulator should release one consumer’s requirement, not force the physical rail off. Keep each consumer’s successful enable calls balanced with its own disables, then verify that another active consumer remains functional. A rail that stays on after one release may be exactly correct.
Applicability: the API contract is Linux v6.12 with the regulator framework and real supply mappings configured. The two-consumer example is hypothetical. Actual voltage, sequencing, discharge, power-off tolerance, and shared-board topology require the selected regulator and load documentation.
1. Map the supply from consumers to hardware
Start from each consumer’s supply name and resolve the board description to the regulator provider. Identify all loads on the physical rail, including firmware-controlled or always-powered functions. Two differently named supplies can lead to one output; two similarly named rails can be electrically separate.
The v6.12 regulator API distinguishes acquiring a regulator handle from enabling its output. regulator_get establishes access to a mapped supply; regulator_enable expresses the consumer’s requirement. A handle alone is not an enabled-use claim.
Record the driver, consumer handle, physical output, upstream supply, and relevant board constraints. Treat unresolved consumers as a topology gap. The framework can arbitrate the relationships described to it, but it cannot protect a hidden load that software never accounts for.
2. Maintain a per-consumer enable ledger
The regulator API specifies reference-counted enable/disable calls that must balance. Successful disable only removes the output when other consumers no longer require it, the provider supports disabling, and machine constraints permit that operation. A consumer must therefore tolerate its supply remaining enabled.
For a hypothetical rail shared by sensor A and interface B, suppose both have one successful enable claim. A finishes and disables once. B’s claim remains, so the normal shared-ownership path keeps the supply available to B. A must now stop using the peripheral even though voltage remains present.
When B later quiesces and releases its claim, the output becomes eligible for disable under the provider and board constraints. Do not label this transition “guaranteed zero volts.” An always-on requirement, fixed supply, discharge behavior, or another physical path can affect the observed rail.
Include repeated enables on one handle in the ledger. If a driver acquires two claims, one disable is not complete cleanup. Conversely, calling disable because a rail looks on, without owning the corresponding enable, is not a valid way to borrow another driver’s accounting.
3. Do not infer ownership from enabled readback
The v6.12 regulator_is_enabled implementation and contract explicitly allow a positive result when another consumer enabled the same provider. It can also return an error. This observation does not tell the caller whether it owns a balanced enable claim.
A problematic pattern is “if already enabled, skip my enable; later disable during cleanup.” That can leave the consumer without its own claim and make cleanup unbalanced. Acquire the requirement through the normal API when the device needs the rail, regardless of another consumer’s current state.
Keep three separate columns: this consumer’s claims, provider-reported enabled state, and measured voltage at the load. The first establishes ownership, the second reports software/provider state, and the third tests an electrical observation. None should be silently substituted for another.
4. Keep force-disable out of routine recovery
The regulator core documents regulator_force_disable as affecting the output even when other consumers hold enables. It is intended for exceptional situations such as preventing likely device damage, rather than ordinary shutdown of one peripheral.
If sensor A becomes unresponsive, forcing off a shared rail can reset interface B during an unrelated transfer. The correct response requires a coordinated product-level decision: isolate or reset A through an independent supported mechanism, defer recovery, or quiesce every affected consumer before a permitted rail cycle.
Document any emergency power-removal policy separately from normal reference balancing. After an emergency cutoff, ordinary accounting alone does not prove that the peers’ retained configuration or in-flight operations are still valid. They need explicit fault recovery.
5. Audit error exits and managed lifetime
List probe failure, runtime-suspend failure, stream stop, device removal, and recovery paths. For each path, record which enables actually succeeded and which resources are still in use. Release only the claims owned by that path after its final hardware access.
Check regulator API return values. On an error, retain the operation and state evidence instead of blindly retrying enables or disables until the voltage appears right. Consult the exact provider and core path before deciding whether a retry is an accounting action, a hardware retry, or both.
Managed handle acquisition is not, by itself, a statement that arbitrary enable calls will be balanced at teardown. Review the actual managed helper used and any explicit cleanup action. Distinguish handle lifetime from enabled-use lifetime in code comments and review diagrams.
Quiesce DMA, interrupts, and queued work before releasing the final claim that protects their device. A shared rail remaining on can hide this bug during development; the same cleanup may fail when the peer is absent and the rail finally turns off.
6. Test partial shutdown in both directions
| Proposed state change | Required evidence |
|---|---|
| A and B active; A releases | B continues valid I/O and retains its claim. |
| A and B active; B releases | A continues valid I/O and retains its claim. |
| Only A active; A releases | Output behavior matches provider capability and board constraints. |
| A setup fails after enabling | A’s cleanup balances its claim without affecting B. |
| A recovers while B is busy | No uncoordinated shared-rail power cycle occurs. |
On a controlled development board, capture enable/disable results, consumer activity, provider state, and rail behavior at the relevant load. Use approved probes and operating conditions. Do not force a shared supply off merely to demonstrate that another device fails.
Repeat with supported consumer combinations and boot configurations. A test where B is always active cannot establish what happens when A becomes the last owner. A test where both stop simultaneously cannot prove that partial shutdown preserves the healthy peer.
No regulator operation or rail measurement was performed for this article. The deliverable is a supply-topology map, per-consumer ledger, and partial-shutdown matrix. Acceptance requires balanced ownership and continued peer functionality, with actual power removal treated as a separate, constraint-dependent result.
