Re: [PATCH] platform/x86: asus-wmi: do not enforce a battery charge threshold

[Denis Benato <denis.benato@linux.dev>]

On 3/4/26 14:39, Antheas Kapenekakis wrote:
> On Wed, 4 Mar 2026 at 14:37, Denis Benato <denis.benato@linux.dev> wrote:
>>
>> On 3/4/26 14:30, Antheas Kapenekakis wrote:
>>> On Wed, 4 Mar 2026 at 14:26, Denis Benato <denis.benato@linux.dev> wrote:
>>>> Users are complaining for the battery limit being reset at 100% during
>>>> the boot process while the general consensus appears to not apply
>>>> unsolecited hardware changes, therefore stop resetting the battery
>>> *unsolicited. But I would rephrase to using this causes the device to
>>> reset its limits on boot, which might have been set by e.g. windows so
>>> if userspace is not aware to restore them, this causes a functionality
>>> degradation. This is the case with the current implementation by KDE.
>>>
>>>> charge limit at boot and return -ENODATA on charge_end_threshold to
>>>> signal for an unknown limit.
>>>>
>>>> Suggested-by: Antheas Kapenekakis <lkml@antheas.dev>
>>>> Suggested-by: Derek J. Clark <derekjohn.clark@gmail.com>
>>>> Signed-off-by: Denis Benato <denis.benato@linux.dev>
>>>> ---
>>>>  drivers/platform/x86/asus-wmi.c | 13 ++++++++-----
>>>>  1 file changed, 8 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
>>>> index 6ba49bd375df..dc330a8ee2f2 100644
>>>> --- a/drivers/platform/x86/asus-wmi.c
>>>> +++ b/drivers/platform/x86/asus-wmi.c
>>>> @@ -1557,7 +1557,10 @@ static ssize_t charge_control_end_threshold_show(struct device *device,
>>>>                                                  struct device_attribute *attr,
>>>>                                                  char *buf)
>>>>  {
>>>> -       return sysfs_emit(buf, "%d\n", charge_end_threshold);
>>>> +       if ((charge_end_threshold >= 0) && (charge_end_threshold <= 100))
>>>> +               return sysfs_emit(buf, "%d\n", charge_end_threshold);
>>>> +
>>>> +       return -ENODATA;
>>> Please verify this does not cause KDE to display a warning and block
>>> modifying the energy consumption. If it does as has been my
>>> experience, communicate with KDE devs or Gnome (if it has a similar
>>> issue) and block this from merging until there is a solution from
>>> their side.
>> KDE doesn't yet allow to modify that value as upower is not picking up batteries
>> with only end_threshold by default. Discussion is ongoing:
>>
>> https://gitlab.freedesktop.org/upower/upower/-/merge_requests/308
> I have tested this exact patch you posted on my Z13 last November. KDE
> does pick it up and display a warning.
Displaying a warning about the current limit not being recognised is what
is expected and correct behavior, not an ABI change: software isn't breaking.

You talked about setting (as in writing) the limit and that, as of now
(at least in KDE) is not possible.

There already exists widely in use software that changes the battery
level when started setting it to the previous value, so that warning
is not to be seen; moreover said class of software is going to earn
a new entry so I don't see any problem here.

Perhaps Ilpo has some more insights on the matter.

In addition to that, after the removal from the kernel of acpi_platform
asus-wmi ABI are going to change anyway, regardless of what I do.
> Which is why I settled with sending a fake 100 value instead and never
> upstreamed it.
>
> Antheas
>
>> since it has never worked there is nothing to break.
>>> Returning an error from this function when there is proper function is
>>> a slight ABI change compared to current drivers that implement this
>>> method.
>>>
>>> Thanks,
>>> Antheas
>>>
>>>>  }
>>>>
>>>>  static DEVICE_ATTR_RW(charge_control_end_threshold);
>>>> @@ -1580,11 +1583,11 @@ static int asus_wmi_battery_add(struct power_supply *battery, struct acpi_batter
>>>>                 return -ENODEV;
>>>>
>>>>         /* The charge threshold is only reset when the system is power cycled,
>>>> -        * and we can't get the current threshold so let set it to 100% when
>>>> -        * a battery is added.
>>>> +        * and we can't read the current threshold, however the majority of
>>>> +        * platforms retains it, therefore signal the threshold as unknown
>>>> +        * until user explicitly sets it to a new value.
>>>>          */
>>>> -       asus_wmi_set_devstate(ASUS_WMI_DEVID_RSOC, 100, NULL);
>>>> -       charge_end_threshold = 100;
>>>> +       charge_end_threshold = -1;
>>>>
>>>>         return 0;
>>>>  }
>>>> --
>>>> 2.53.0
>>>>
>>>>