Re: [PATCH v9 14/16] platform/x86: lenovo-wmi-other: Add WMI battery charge limiting

["Derek J. Clark" <derekjohn.clark@gmail.com>]

On May 11, 2026 11:48:44 AM PDT, Hans de Goede <hansg@kernel.org> wrote:
>Hi Nicolas,
>
>On 24-Apr-26 14:50, Nícolas F. R. A. Prado wrote:
>> On Sat, 2026-04-11 at 16:23 +0000, Derek J. Clark wrote:
>>> Add charge-type power supply extension for devices that support WMI
>>> based
>>> charge enable/disable.
>>>
>>> Lenovo Legion devices that implement WMI function and capdata ID
>>> 0x03010001 in their BIOS are able to enable or disable charging at
>>> 80%
>>> through the lenovo-wmi-other interface. Add a charge_type power
>>> supply
>>> extension to expose this capability to the sysfs.
>> 
>> Hi,
>> 
>> this is not the right uAPI to expose this capability.
>> 
>> If you check the ABI description for
>> /sys/class/power_supply/<supply_name>/charge_type [1], it mentions
>> "rate" and if you check the corresponding enum definition [2] it
>> mentions "speed", so the charge_type uAPI is very clearly meant to
>> expose the the charge rate/speed/current currently configured, with
>> Long Life specifically meaning a reduced charge rate, rather than
>> reduced charge capacity.
>
>As discussed here:
>
>https://lore.kernel.org/linux-pm/49993a42-aa91-46bf-acef-4a089db4c2db@redhat.com/
>https://lore.kernel.org/platform-driver-x86/20241209204051.8786-1-hdegoede@redhat.com/
>
>and also here:
>
>https://vdwaa.nl/charge-types-api-upower.html
>
>The use of charge_type[s] for this is intentional and is exactly
>the right uAPI to use in this case (especially see the first link).
>
>> The uAPI you're looking for here is
>> /sys/class/power_supply/<supply_name>/charge_control_end_threshold [3],
>> which very explicitly exposes the charge threshold in percentage. You
>> can then accept only 100 or 80 as valid values and configure your
>> hardware accordingly. Unfortunately there's currently no way for
>> userspace to know that these are the only valid values (which is
>> something that I want to look into implementing soon), it can only read
>> back to see if what it wrote was accepted, but it's still the best uAPI
>> for this.
>
>charge_control_end_threshold only makes sense when the firmware API
>actually allows controlling the % of charge at which point the charger
>will stop charging the battery.
>
>In many cases there only is an option to prolong battery longevity
>aka "long life" by not charging to 100% but the exact % of charge
>at which to stop charging is not configurable. This is exactly
>the case for which we've decided to use a charge_type of "long life"
>and upower has also implemented support for this.
>

Hi Hans,

This is good information. Since there was understandable confusion from the way the documentation reads, I think taking another look at it to clarify this would help avoid churn back and forth in the future. Specifically, for charge_types:

>Long Life: The charger reduces its charging rate in order to prolong the battery health.

Should probably read something more like:

> Long Life: The charger firmware reduces its charging rate and/or maximum charging percentage to a hardware specified fixed limit in order to prolong the battery health.

And for charge_control_end_threshold:

> Represents a battery percentage level, above which charging will stop. Not all hardware is capable of setting this to an arbitrary percentage. Drivers will round written values to the nearest supported value. Reading back the value will show the actual threshold set by the driver.

Should probably read more like:

> Represents a battery percentage level, above which charging will stop. Not all hardware is capable of setting this to any arbitrary value, instead providing different minimum, maximum, or step values. Drivers will round written values to the nearest supported value. Reading back the value will show the actual threshold set by the driver. For hardware that only supports a single fixed value, use charge_types instead.

Ilpo,

If you want to drop v12 from fixes I can submit a v13 fairly quickly to address this. I'll also address Rong's latest questions/comments when I do that. If you'd rather we go another route then please let me know soon. I think we'd all like to put this series to bed.

Thanks,
Derek

>> I see that there have been 2 commits merged last year that make the
>> exact same misuse of the uAPI, which probably contributed to the
>> confusion here, but the ship has sailed for those. 
>
>Those commits are working as designed and a 3th one is actually
>in the making doing the same thing:
>
>https://lore.kernel.org/linux-pm/49993a42-aa91-46bf-acef-4a089db4c2db@redhat.com/
>
>Regards,
>
>Hans
>
>