Documentation/devicetree/bindings/power/supply/battery.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/power/supply/battery.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/power/supply/battery.yaml- Extension
.yaml- Size
- 8014 bytes
- Lines
- 216
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: configuration, schema, or hardware description
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/supply/battery.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Battery Characteristics
maintainers:
- Sebastian Reichel <sre@kernel.org>
description: |
The devicetree battery node provides static battery characteristics.
In smart batteries, these are typically stored in non-volatile memory
on a fuel gauge chip. The battery node should be used where there is
no appropriate non-volatile memory, or it is unprogrammed/incorrect.
Upstream dts files should not include battery nodes, unless the battery
represented cannot easily be replaced in the system by one of a
different type. This prevents unpredictable, potentially harmful,
behavior should a replacement that changes the battery type occur
without a corresponding update to the dtb.
Battery properties are named, where possible, for the corresponding elements
in enum power_supply_property, defined in include/linux/power_supply.h
Batteries must be referenced by chargers and/or fuel-gauges using a phandle.
The phandle's property should be named "monitored-battery".
properties:
compatible:
const: simple-battery
device-chemistry:
description: This describes the chemical technology of the battery.
oneOf:
- const: nickel-cadmium
- const: nickel-metal-hydride
- const: lithium-ion
description: This is a blanket type for all lithium-ion batteries,
including those below. If possible, a precise compatible string
from below should be used, but sometimes it is unknown which specific
lithium ion battery is employed and this wide compatible can be used.
- const: lithium-ion-polymer
- const: lithium-ion-iron-phosphate
- const: lithium-ion-manganese-oxide
over-voltage-threshold-microvolt:
description: battery over-voltage limit
re-charge-voltage-microvolt:
description: limit to automatically start charging again
voltage-min-design-microvolt:
description: drained battery voltage
voltage-max-design-microvolt:
description: fully charged battery voltage
energy-full-design-microwatt-hours:
description: battery design energy
charge-full-design-microamp-hours:
description: battery design capacity
trickle-charge-current-microamp:
description: current for trickle-charge phase.
Please note that the trickle-charging here, refers "wake-up" or
"pre-pre" -charging, for very empty batteries. Similar term is also
used for "maintenance" or "top-off" -charging of batteries (like
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
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.