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

[Antheas Kapenekakis]

On Wed, 4 Mar 2026 at 14:39, Antheas Kapenekakis <lkml@xxxxxxxxxxx> 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.
>
> Which is why I settled with sending a fake 100 value instead and never
> upstreamed it.

*to be clear here I did EIO, not EDATA so this might be handled differently.

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