linux-kernel - Re: [PATCH v2 5/6] arm64: dts: qcom: x1e80100-vivobook-s15: add charge limit nvmem

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4ec493de-10d9-4a0d-b00c-d6e0f3d92b34@oss.qualcomm.com>
Date: Mon, 24 Nov 2025 12:01:15 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Maud Spierings <maud_spierings@...mail.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Robert Foss <rfoss@...nel.org>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Jonas Karlman <jonas@...boo.se>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>
Cc: dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v2 5/6] arm64: dts: qcom: x1e80100-vivobook-s15: add
 charge limit nvmem

On 11/23/25 12:03 PM, Maud Spierings wrote:
> On 11/22/25 14:37, Konrad Dybcio wrote:
>> On 11/22/25 12:07 PM, Maud Spierings wrote:
>>> On 11/20/25 16:36, Konrad Dybcio wrote:
>>>> On 11/17/25 4:44 PM, Maud Spierings wrote:
>>>>> On 11/17/25 16:35, Konrad Dybcio wrote:
>>>>>> On 11/17/25 3:13 PM, Maud Spierings wrote:
>>>>>>> Hi Konrad,
>>>>>>>
>>>>>>> On 11/17/25 13:59, Konrad Dybcio wrote:
>>>>>>>> On 11/16/25 11:52 AM, Maud Spierings via B4 Relay wrote:
>>>>>>>>> From: Maud Spierings <maud_spierings@...mail.com>
>>>>>>>>>
>>>>>>>>> Add nvmem cells for getting charge control thresholds if they have
>>>>>>>>> been set previously.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Maud Spierings <maud_spierings@...mail.com>
>>>>>>>>> ---
>>>>>>>> Have you verified that e.g.
>>>>>>>>
>>>>>>>> connecting the charger
>>>>>>>> setting the charge threshold
>>>>>>>> rebooting to windows
>>>>>>>> rebooting to windows once more for good measure
>>>>>>>> rebooting to linux
>>>>>>>>
>>>>>>>> still has the settings persist?
>>>>>>> Hmm I have tried several things but I can't seem to get the values to stick. I the spmi-sdam driver is compiled in, I am not quite sure if I might be missing something.
>>>>>> Hm, I wonder if Windows/UEFI overwrites these values or whether they're
>>>>>> used by something else..
>>>>>>
>>>>>> Can you set a threshold in windows and see if Linux can read back that
>>>>>> data?
>>>>> the values in /sys/class/power_supply/jada-jada/ are zero when rebooting from Windows into Linux after enabling charge limitting in the Asus application.
>>>>>
>>>>> I remember my old vivobook (x86) also forgot its settings each boot, but given the nvmem cells that should not be happing here I guess. It is odd that there seems to be no collision between Windows and Linux. Maybe the Windows mechanism is doing the old trick of writing it in there every boot?
>>>> Odd indeed.. Does it work if you reboot from Linux to Linux?
>>> It seems not, I seem to remember testing it quite some time ago, but I cannot get it to remember any way, at least it is not popping up in sysfs, always back to 0
>> It seems like the driver currently only populates the sysfs start/stop
>> values if the "enable" bit is set
>>
>> Could you check this (hacky and wrong) diff and give it another try?
>>
>> diff --git a/drivers/power/supply/qcom_battmgr.c b/drivers/power/supply/qcom_battmgr.c
>> index c8028606bba0..9ebd8adfb8eb 100644
>> --- a/drivers/power/supply/qcom_battmgr.c
>> +++ b/drivers/power/supply/qcom_battmgr.c
>> @@ -733,7 +733,7 @@ static int qcom_battmgr_charge_control_thresholds_init(struct qcom_battmgr *batt
>>          u8 en, end_soc, start_soc, delta_soc;
>>            ret = nvmem_cell_read_u8(battmgr->dev->parent, "charge_limit_en", &en);
>> -       if (!ret && en != 0) {
>> +       if (!ret) {
>>                  ret = nvmem_cell_read_u8(battmgr->dev->parent, "charge_limit_end", &end_soc);
>>                  if (ret < 0)
>>                          return ret;
>>
>>
> Nope still nothing, there is one err about "failed to send synthetic uevent: -11" during startup, but I don't know how relevant that is.

Hm, I'm a little puzzled.. It may be that ASUS customized the charge control
functionality, but I doubt that

In any case, this patch should let you limit the charging bounds within a
single boot on Linux, so that's already useful..

Reviewed-by: Konrad Dybcio <konrad.dybcio@....qualcomm.com>

Konrad