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

[Antheas Kapenekakis]

On Wed, 18 Mar 2026 at 15:16, Denis Benato <denis.benato@xxxxxxxxx> wrote:
>
>
> 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.

Great,
fine by me to merge

Tested-by: Antheas Kapenekakis <lkml@xxxxxxxxxxx>

Best,
Antheas

> >> 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
> >>>>>>>
> >>>>>>>
>