Re: [RFC] power: supply: qcom_battmgr: implement battery charge control on kodiak phones

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 10/18/26 11:46 AM, Federico Amedeo Izzo wrote:
> Hello,
> 
> I want to implement battery charge control support on two kodiak phones:
> motorola-dubai and fairphone-fp5. I kindly ask your feedback on my 
> implementation proposal below.
> 
> This feature also known as "charging limit" or "battery health" lets the user
> limit the battery charging range to 0-80% tipically, in order to extend the
> lifetime of the battery. It can also be used with a lower range 0-50% to
> prevent battery degradation on devices always connected to a charger.
> 
> Newer SoCs like SM8550 and X1E80100 implement charge control in the battmgr
> firmware, but kodiak (SM8350 in qcom-battmgr.c) does not support that (I tried
> using the same property ID as newer SoCs with no luck.
> 
> Looking at downstream implementations, both dubai and fp5 implement the ability
> to stop and start the charge with custom extensions to the battmgr firmware,
> while the actual charge control logic is implemented in a kernel driver (dubai)
> or in a userspace java service (fp5).
> 
> My plan is to expose the start/stop firmware capability of the two phones using
> the charge_behaviour sysfs property, then implement the charge control logic
> (start/stop charge depending on current level vs thresholds) in the qcom-battmgr
> driver itself and expose the sysfs properties charge_control_start/end_threshold
> to let userspace change the thresholds. The scope of this "software"
> implementation would be limited to SM8350 in qcom-battmgr as later SoCs can
> already do this in firmware.

I suppose this is something that could be introduced at the framework
level (+sre) - using a "stop charging" command to implement a charging
level cap.

For battmgr, I see there's a BATTMGR_SET_CHARGE_RATE (0x6) command
with the following arguments:

struct {
	struct pmic_glink_hdr hdr;
	__le32 battery_id;
	__le32 charge_rate;
	__le32 charging_path;
}

charge_rate being the % of full charge current that is allowed.
Maybe that could work. Or maybe there's an existing mechanism that
I failed to notice.

Konrad