Re: [PATCH] dt-bindings: power: supply: battery: allow longer ocv-capacity tables
From: Ryan Brue
Date: Sun Sep 20 2026 - 02:42:22 EST
On 9/18/26 3:29 AM, Henrik Grimler wrote:
Hi Ryan,Hi Henrik,
On Fri, Sep 18, 2026 at 12:36:31AM -0500, Ryan Brue wrote:
ocv-capacity-table-N has been capped at 100 points since battery.txt wasAllowing for points > 100 % could make sense, but why would you need
converted to YAML, where the limit arrived without a stated reason.
The MT6397 fuel gauge is characterised per temperature by a table the
Amazon Fire HD 10 (2017) vendor device tree carries with 126 points, of
which 122 are expressible here - the remainder are greater than 100%
discharged, so the binding excludes those points. Boards carrying this
PMIC fuel gauge would need more than 100 points to describe the pack with
the generic property. Raise the cap to 128.
Assisted-by: LLM
Signed-off-by: Ryan Brue <ryanbrue.dev@xxxxxxxxx>
---
No kernel change goes with this. power_supply_get_battery_info() sizes each
ocv-capacity-table-N from the property itself -- it reads the length with
fwnode_property_count_u32() and devm_kcalloc()s that many entries -- so
maxItems in the binding is the only cap on points per table.
POWER_SUPPLY_OCV_TEMP_MAX bounds the number of tables, not their length.
The consumer that wants this is an MT6397 PMIC fuel gauge not yet posted;
its pack is characterised at 126 points per temperature in the vendor's
kernel (Amazon Fire OS, based on Linux 3.18), with 122 of those points
being expressible with the generic property (the rest are greater than
100%).
122 points up to 100 %? If the vendor kernel has several values at for
example 20 %, then a better solution is probably to take the average
of them.
I think only reason to have multiple values for the same percentage
would be if hysterersis (see for example this open-access article [1]
for discussion about hysteresis) is taken into account, i.e. having
one table for charge direction, and one table for discharge direction,
but I don't think any driver uses multiple tables to handle something
like that.
[1] https://doi.org/10.1038/s41598-019-51474-5
Best regards,
Henrik Grimler
Yeah, you're right. To be honest, I didn't think about that, and should have.
On why there's so many points: the vendor's table isn't indexed by percentage at all. A row is a fixed 54 mAh step of charge - step_of_qmax, which the meter converts to mAh directly - and the percentage column is just that rounded, round(i * 54 * 100 / Qmax), which fits every row of all five tables exactly. At 0.85% per row about one in six repeats, so the duplicates carry nothing. I should also correct the figures I sent: 126/122 is a different cell in the same vendor file. This unit's tables are 120 points and none of the points are above 100% in this one.
I don't need to model the vendor one to one. I measured what dropping resolution costs, and decimating to 100 points changes the capacity I report by at most 1% - so it fits the binding as it stands, and the justification I sent doesn't hold.
The only thing I can see still being worth raising is 101 rather than 128. Capacity percent is capped at 100, and 0..100 inclusive is 101 values, so if I'm not mistaken no board can express 1% granularity today if they have points at both 0 and 100. I'm not sure that's worth a patch on its own, so I'm fine dropping this, or doing a v2 allowing 101 values.
Best regards,
Ryan Brue