[PATCH v4 00/11] power: supply: initialize MAX17055 from battery info

From: Vincent Cloutier <[email protected]>

Hi,

This is the remaining unmerged tail of the MAX17042/MAX17055 v1 series.
Six v1 patches are upstream, and the v1 cleanup patch is covered by
699f0f71ac98. This revision retains the requested registration callback
architecture and splits the MAX17055 driver work into smaller steps.

The power-supply callback runs after the core parses monitored-battery but
before device_add(). This lets the driver validate and prepare DesignCap,
IChgTerm, dQAcc, and VChg without another firmware parser or a
power_supply_config handoff. The callback remains synchronous and cannot
start activity that accesses the power supply before registration
completes. dPAcc is derived later from register read-back.

The MAX17055 path waits for FSTAT.DNR, saves HibCfg, exits hibernate,
writes each stable battery register once, and verifies it after 1 ms.
SoftWakeup is written directly, and Refresh is requested once before
polling. The driver derives dPAcc from read-back DesignCap, dQAcc, and
ModelCfg values, restores HibCfg, and clears POR only after the complete
sequence succeeds.

Driver-backed properties remain unavailable while initialization is
incomplete. An interrupted transaction restores hibernate and retries
every 10 seconds without depending on POR still being set, so a transient
startup error does not become permanent. The delayed work continues to use
system_wq, matching the original work item.

Positive DesignCap and IChgTerm battery values are applied, while zero is
treated like an absent value. Supplied positive values that cannot be
represented by the hardware are rejected.

VChg remains a masked ModelCfg update. A voltage-only override reads
effective DesignCap and dQAcc and refreshes dPAcc for the selected voltage
range. Zero is rejected. Exactly 4.275 V selects the low range; only values
above 4.275 V set VChg. An absent property preserves firmware's setting.

---

Changes since v3:

- split the previous MAX17055 driver patch into initialization extraction,
  init_complete type/access, delayed-work conversion, STATUS error handling,
  retry, EZ Config programming, POR transaction, and battery-info steps
  (Sebastian)
- retain system_wq when converting initialization to delayed work
- explain why initialization completion sends a power-supply notification
- treat zero DesignCap and IChgTerm values like absent properties (Sebastian)
- make the registration init callback's synchronous lifetime contract explicit
- remove the redundant power-supplies binding declaration (Krzysztof)

Changes since v2:

- use unevaluatedProperties in the MAX17042 binding instead of declaring
  monitored-battery explicitly (Krzysztof)

Changes since v1:

- send only the unmerged battery-info and VChg work
- split the power-supply core and MAX17055 driver changes
- use the requested registration init callback
- wait for FSTAT.DNR before programming POR values
- save, exit, and restore hibernate around MAX17055 EZ Config
- write stable registers once, wait 1 ms, and verify their read-back
- issue each command once and poll ModelCfg.Refresh
- derive dPAcc from register read-back values
- retry interrupted initialization periodically without a POR recheck
- keep properties unavailable until initialization completes
- recalculate dPAcc for a VChg-only override and reject zero voltage
- allow generic power-supply properties in the MAX17042 family binding
- drop the Librem 5 battery description from this series; defer
  board-specific battery profile selection to separate work

The series was folded into a Librem 5r4 kernel. A temporary test DTB with
zero DesignCap and IChgTerm values booted with the MAX17055 registered and
no initialization errors, confirming that zero is treated as absent.

After restoring the positive battery profile and performing a full
battery-removal gauge POR, Status.POR and FSTAT.DNR cleared, HibCfg was
restored, and ModelCfg.Refresh cleared. The driver programmed dQAcc=0x002b
and dPAcc=0x054b; the live dQAcc had moved to 0x002a after initialization.
The other raw values and sysfs properties matched the expected 4.2 V EZ
Config result, with no MAX17055 initialization errors.

v3: https://lore.kernel.org/all/[email protected]/
v2: https://lore.kernel.org/all/[email protected]/
v1: https://lore.kernel.org/all/[email protected]/

Vincent Cloutier (11):
  power: supply: Add registration init callback
  power: supply: max17042_battery: Separate MAX17055 initialization
  power: supply: max17042_battery: Use bool for init_complete
  power: supply: max17042_battery: Convert initialization to delayed
    work
  power: supply: max17042_battery: Propagate status register errors
  power: supply: max17042_battery: Retry failed MAX17055 initialization
  power: supply: max17042_battery: Program MAX17055 EZ Config values
  power: supply: max17042_battery: Follow MAX17055 POR sequence
  power: supply: max17042_battery: Initialize MAX17055 from battery info
  power: supply: max17042_battery: Honor MAX17055 charge voltage
  dt-bindings: power: supply: max17042: Allow generic power-supply
    properties

 .../bindings/power/supply/maxim,max17042.yaml |   4 +-
 drivers/power/supply/max17042_battery.c       | 365 ++++++++++++++++--
 drivers/power/supply/power_supply_core.c      |   8 +
 include/linux/power/max17042_battery.h        |   2 +
 include/linux/power_supply.h                  |   9 +
 5 files changed, 353 insertions(+), 35 deletions(-)


base-commit: f2ec6312bf711369561bdcb22f8a63c0b118c479
-- 
2.55.0