Battery-Gated Firmware Updates: Separate Download Eligibility from Commit Eligibility

Use separate power gates for acquiring an update and entering the stage that must finish without a safe pause. A device may have enough reserve to download a bounded chunk while lacking the qualified reserve for image programming, boot-state changes and recovery. Recheck immediately before that critical stage; an earlier battery reading is not a continuing permission.

This article defines an original update-admission policy, with Linux 6.12 power-supply properties as the concrete telemetry example. It provides no universal voltage, state-of-charge or energy threshold. Those values require the actual battery, regulator, storage and board limits plus measured workload evidence.

1. Locate the real power-sensitive boundary

Draw the deployed update path: receive metadata, download or stream, verify, prepare storage, program, select boot state, reboot and confirm. Mark where the implementation can safely defer, restart or recover. “Commit” here names a product-defined boundary; it does not assert that all subsequent storage operations are atomic.

RFC 9019 identifies radio communication and flash writing as energy-intensive update work. Therefore, download is not automatically harmless: it consumes energy and may also write persistent storage.

Streaming installers can combine network retrieval with destination programming. If those operations are interleaved, there may be no independent “download now, install later” phase. Apply the appropriate power gate before entering the combined operation rather than relying on a user-interface label.

2. Build a stage-specific admission matrix

Stage	Evidence needed before admission	If evidence is insufficient
Metadata retrieval.	Bounded communication budget and normal operating reserve.	Defer without changing installed firmware.
Resumable staged download.	Qualified receive/write budget and valid checkpoint behavior.	Pause only at a supported checkpoint.
Verification and preparation.	Budget for CPU/storage work and a recoverable failure state.	Keep the candidate staged if its retention policy permits.
Noninterruptible install or boot-state transition.	Fresh evidence supporting completion and required recovery reserve.	Do not start; retain a power-hold reason.
Already admitted critical operation.	Ongoing hardware protection and the qualified interruption policy.	Follow that policy; do not improvise an unsafe abort.

Separate the threshold for entering a stage from the response after entry. If the battery falls below the entry threshold during programming, that does not prove killing the installer is safer. The qualified architecture must define the outcome of supply loss and any supported cancellation point.

3. Give power readings exact meanings

The Linux 6.12 power-supply class distinguishes capacity percentage from charge in microamp-hours and energy in microwatt-hours. Voltage and current use microvolts and microamps. Attributes can be absent when the monitoring hardware does not provide them.

Build a normalized observation record containing the supply identity, property, units, read status, sample or acquisition time, freshness limit and relevant health/status information. A missing property must remain missing. Do not replace a failed read with zero or a previous successful value labeled as current.

Reading several sysfs attributes does not itself establish a coherent hardware snapshot. Review the provider’s refresh behavior and driver version. If values can originate from different update cycles, use the product’s supported acquisition contract or conservatively bound the resulting uncertainty.

A high capacity percentage is not proof that the supply can sustain programming current or a reboot transient. Similarly, a charger-present indicator does not establish adequate available power under the full system load. Those are board-level qualification questions.

4. Derive a reserve instead of copying a percentage

Measure the relevant stage and recovery path across the supported operating envelope. Include aging, temperature, allowed supply sources, storage variation, radio conditions and simultaneous product work. Use actual component documentation to establish permissible operating limits; a battery gauge reading cannot redefine a flash device’s supply specification.

Choose an uncertainty allowance and required post-update operating reserve. Keep energy sufficiency separate from minimum rail voltage and transient capability. A calculation showing enough total energy does not rule out a brief brownout.

When comparing quantities, keep the measurement boundary consistent. Energy reported for a battery pack and energy consumed on a regulated rail require a justified conversion and efficiency allowance. Do not compare microamp-hours directly with microwatt-hours or multiply by a nominal voltage without stating the approximation.

Publish the resulting threshold policy with the hardware and firmware revisions it covers. A larger image, changed storage mode or added boot migration can invalidate an old reserve even if the displayed battery percentage is unchanged.

5. Revalidate after waiting or downloading

A device can pass an early check, spend a long time downloading over a weak link and arrive at installation with less reserve. Attach the admission decision to the specific stage and evidence generation. Invalidate it after a supply change, gauge reset, excessive age or a materially changed workload.

Use one update owner to serialize the final check with stage admission as tightly as the implementation permits. State the remaining check-to-use gap and the hardware protections that cover it. A software check cannot guarantee that a user will not unplug a cable immediately afterward.

When power is insufficient, retain the verified candidate according to its storage policy and expose “waiting for qualified power.” Repeatedly deleting and downloading it can consume the very reserve needed to become eligible. Recheck at a bounded cadence or meaningful supply event, while preserving campaign expiry and supersession rules.

6. Test stale and misleading evidence

• Download starts with sufficient reserve but the final admission check fails.
• External power disappears between preparation and admission.
• A cached capacity value remains high while fresh voltage evidence is unavailable.
• The gauge resets, reports an unsupported property or returns an I/O error.
• A replacement battery has the same percentage but different qualified capability.
• The update falls back to a more expensive transfer or programming path.
• The campaign expires while waiting for power.

Begin with synthetic observation records and a non-writing state-machine fixture. Later power-interruption testing requires recoverable development hardware, preserved data, safe loads and an approved lab procedure. No such tests or measurements were performed for this article.

Hypothetical long download

A battery-powered gateway begins a resumable download under an approved acquisition budget. Poor connectivity extends the transfer, and the fresh pre-install check no longer supports the critical-stage reserve. The gateway retains the verified candidate and waits for qualified power instead of treating download completion as permission to program.

Release with the stage matrix, property semantics, measured reserve evidence and stale-reading tests. The result should explain why a device may receive an update but remain correctly ineligible to commit it.