linux-kernel - Re: [PATCH 0/2] power: supply: qcom_battmgr: improve charge control threshold handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d0bd3084-a1e7-4fe6-b540-0919d1674ab4@oss.qualcomm.com>
Date: Tue, 18 Nov 2025 11:13:01 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Fenglin Wu <fenglin.wu@....qualcomm.com>, Val Packett <val@...kett.cool>,
        Sebastian Reichel <sre@...nel.org>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] power: supply: qcom_battmgr: improve charge control
 threshold handling

On 11/18/25 3:29 AM, Fenglin Wu wrote:
> 
> On 11/17/2025 8:45 PM, Konrad Dybcio wrote:
>> On 11/17/25 6:12 AM, Fenglin Wu wrote:
>>> On 10/13/2025 7:32 AM, Val Packett wrote:
>>>> Currently, upowerd is unable to turn off the battery preservation mode[1]
>>>> on Qualcomm laptops, because it does that by setting the start threshold to
>>>> zero and the driver returns an error:
>>>>
>>>> pmic_glink.power-supply.0: charge control start threshold exceed range: [50 - 95]
>>>>
>>>> Kernel documentation says the end threshold must be clamped[2] but does
>>>> not say anything about the start threshold.
>>>>
>>>> In this proposal I've special-cased start==0 to actually disable the
>>>> functionality via the enable bit, and otherwise made both start and
>>>> end thresholds be clamped to the acceptable range. Hopefully that's
>>>> fine?
>>> It is fine to clamping the threshold to the acceptable range. Thank you for making the changes.
>>>> Or should the [1 - 49] range for start actually be rejected?
>>> The minimum charging start threshold was set to 50 to improve user experience. If the threshold is too low and the system keeps drawing power from the battery frequently due to a large system load and a weak charger, the laptop will only begin charging when the battery level falls below that threshold. If the user disconnects the charger at that time, then the device would be only having a battery below 50%. Setting the threshold at 50 ensures the battery always stays above 50%.
>> So can we set it lower?
>>
>> Such decisions are best deferred to userspace and/or the user, which can
>> limit what the kernel exposes as necessary/deemed useful
>>
>> Konrad
> 
> Yes, it can be set to a lower value.
> 
> However, I am still having concerns that the inappropriate start and end threshold settings would cause a very bad user experience if they are misused, since these thresholds are stored in nvmem and they won't be reset until battery is unplugged or completely drained. For example, if someone intentionally sets the start threshold to 1 and end threshold to 6, and if the laptop was shutdown with a battery SoC less than the end threshold, I am not sure if <6% percent battery level would be good enough to boot up the laptop successfully, if it is not, then the laptop may not have chance to charge up until you hot plug the battery.
> 
> Also, from battery management firmware point of view, the charge control feature was mainly designed for battery health management, to slow the aging of Li-ion battery by preventing it from being frequently charged to full state. Having a too low minimum start threshold setting won't help anything on that.

Perhaps 50 makes sense then. Maybe we can encode this reasoning somewhere
in the power supply API docs so it's harder to make the "can't boot anymore"
mistake you mentioned

Konrad