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

[Denis Benato]

On 3/4/26 17:12, Denis Benato wrote:
> On 3/4/26 17:07, Antheas Kapenekakis wrote:
>> On Wed, 4 Mar 2026 at 14:52, Denis Benato <denis.benato@xxxxxxxxx> wrote:
>>> On 3/4/26 14:39, Antheas Kapenekakis wrote:
>>>> On Wed, 4 Mar 2026 at 14:37, Denis Benato <denis.benato@xxxxxxxxx> wrote:
>>>>> On 3/4/26 14:30, Antheas Kapenekakis wrote:
>>>>>> On Wed, 4 Mar 2026 at 14:26, Denis Benato <denis.benato@xxxxxxxxx> 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@xxxxxxxxxxx>
>>>>>>> Suggested-by: Derek J. Clark <derekjohn.clark@xxxxxxxxx>
>>>>>>> Signed-off-by: Denis Benato <denis.benato@xxxxxxxxx>
>>>>>>> ---
>>>>>>>  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.
>> This is not true. Powerdevil supports the Asus driver and has done so
>> for at least a year.
>>
>> The setting is under "Power Management -> Advanced Power Settings". On
>> mainline it works properly but resets after every reboot due to this
>> bug.
> I never noticed it... Interesting... well thank you.
>
>> With your patch applied, at least with -ENODATA there is no error. KDE
>> defaults to 50%. So perhaps this could be doable to merge, -EIO made
>> it fail. If you verify Gnome works properly or just does not support
>> battery limits, but actually verify it mind you, this should be good
>> to merge.
> Alright I will test gnome and cosmic and will let you know. Thanks
> for covering KDE!
I don't see anything bad. Both gnome and cosmic reports the current
charge level.
>> Antheas
>>
>>
>> Antheas
>>
>>> 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
>>>>>>>
>>>>>>>