Re: [PATCH v2] power: supply: cros_charge-control: restore EC state on resume

[Tzung-Bi Shih]

On Mon, Oct 05, 2026 at 03:34:18PM +1100, Andrew Pam wrote:
> The EC resets its charge control configuration when the AP powers off,
> so configured sustainer thresholds and charge behaviour are lost across
> hibernation.
> 
> Nothing notices the reset. Commit 4fc88ba435da ("power: supply:
> cros_charge-control: adopt EC charge state on probe"), in the
> power-supply tree, made the driver adopt the EC's charge state, but only
> at probe, and a resume is not a probe. Sysfs therefore keeps reporting
> the configured values while the EC charges the battery to full. On a
> Framework Laptop 16 (Ryzen AI 300, charge control command version 3)
> with charge_control_end_threshold set to 80, a hibernate and resume
> cycle leaves the attribute still reading 80 while the battery charges
> past it to 100%.
> 
> Add a system sleep resume hook that reprograms the EC from the cached
> state. The same EC behaviour and the same fix already exist for another
> driver, see commit 2643187ccb86 ("platform/x86: ayaneo-ec: Add suspend
> hook").
> 
> Reprogramming the EC is only strictly required after hibernation, but it
> is cheap and idempotent, so hook every resume path rather than rely on
> the EC preserving its state across each kind of sleep transition.
> 
> Note that re-reading the state from the EC on resume, by reusing
> cros_chctl_init_state() or otherwise, would be wrong even on the command
> versions that support GET: the EC has been reset to its defaults by the
> time the hook runs, so adopting that state would silently discard the
> configuration the user asked for. The driver's cached state is the only
> remaining record of it, which is why it is pushed to the EC rather than
> refreshed from it.
> 
> Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver")
> Cc: stable@xxxxxxxxxxxxxxx
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Andrew Pam <andrew@xxxxxxxxxxxxxxxx>

Reviewed-by: Tzung-Bi Shih <tzungbi@xxxxxxxxxx>

You should send new versions (e.g., v2) independently next time, instead of
replying to your previous versions (e.g., v1).