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

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

[Denis Benato]

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

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

[Antheas Kapenekakis]

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.

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

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

[Denis Benato]

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

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

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

[Antheas Kapenekakis]

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.

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

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@antheas.dev> 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.
>
> 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
> > >>
> > >>
> >

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

[Denis Benato]

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

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

[Antheas Kapenekakis]

On Wed, 4 Mar 2026 at 14:52, Denis Benato <denis.benato@linux.dev> wrote:
>
>
> 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.

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.

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.

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

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

[Denis Benato]

On 3/4/26 17:07, Antheas Kapenekakis wrote:
> On Wed, 4 Mar 2026 at 14:52, Denis Benato <denis.benato@linux.dev> wrote:
>>
>> 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.
> 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!
> 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
>>>>>>
>>>>>>

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@linux.dev> wrote:
>>> 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.
>> 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
>>>>>>>
>>>>>>>

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@linux.dev> 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@linux.dev> wrote:
> >>> 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.
> >> 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@antheas.dev>

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

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

[Ilpo Järvinen]

On Wed, 4 Mar 2026, Denis Benato 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

I'll deal with this while merging. If nothing else comes up, no need to 
send v2 just because of it (I'm just sending this to remind myself).

--
 i.

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

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

[Derek J. Clark]

On March 4, 2026 5:26:08 AM PST, 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
>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>

Hi Denis,

LGTM.

Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>

- Derek
>---
> 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;
> }
> 
> 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;
> }

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

[Ilpo Järvinen]

On Wed, 04 Mar 2026 14:26:08 +0100, Denis Benato 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
> charge limit at boot and return -ENODATA on charge_end_threshold to
> signal for an unknown limit.
> 
> 
> [...]


Thank you for your contribution, it has been applied to my local
review-ilpo-next branch. Note it will show up in the public
platform-drivers-x86/review-ilpo-next branch only once I've pushed my
local branch there, which might take a while.

The list of commits applied:
[1/1] platform/x86: asus-wmi: do not enforce a battery charge threshold
      commit: 186bf9031666602d61b40832181b6b6fdc3ba4dc

--
 i.