public inbox for platform-driver-x86@vger.kernel.org
 help / color / mirror / Atom feed
From: Denis Benato <denis.benato@linux.dev>
To: Antheas Kapenekakis <lkml@antheas.dev>
Cc: linux-kernel@vger.kernel.org,
	platform-driver-x86@vger.kernel.org,
	"Hans de Goede" <hansg@kernel.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Luke D . Jones" <luke@ljones.dev>,
	"Derek John Clark" <derekjohn.clark@gmail.com>,
	"Denis Benato" <benato.denis96@gmail.com>
Subject: Re: [PATCH] platform/x86: asus-wmi: do not enforce a battery charge threshold
Date: Wed, 4 Mar 2026 14:36:49 +0100	[thread overview]
Message-ID: <a934337f-9055-40b8-93ef-294fd5f0a0f6@linux.dev> (raw)
In-Reply-To: <CAGwozwGhr6hwRz5jBkDGQrmJf9oK8FDE3dCE9_sAAChP5qrTGQ@mail.gmail.com>


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

  reply	other threads:[~2026-03-04 13:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-04 13:26 [PATCH] platform/x86: asus-wmi: do not enforce a battery charge threshold Denis Benato
2026-03-04 13:30 ` Antheas Kapenekakis
2026-03-04 13:36   ` Denis Benato [this message]
2026-03-04 13:39     ` Antheas Kapenekakis
2026-03-04 13:40       ` Antheas Kapenekakis
2026-03-04 13:51       ` Denis Benato
2026-03-04 16:07         ` Antheas Kapenekakis
2026-03-04 16:12           ` Denis Benato
2026-03-18 14:16             ` Denis Benato
2026-03-18 14:17               ` Antheas Kapenekakis
2026-03-04 13:32 ` Ilpo Järvinen
2026-03-18 14:30 ` Derek J. Clark
2026-03-24 17:31 ` Ilpo Järvinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a934337f-9055-40b8-93ef-294fd5f0a0f6@linux.dev \
    --to=denis.benato@linux.dev \
    --cc=benato.denis96@gmail.com \
    --cc=derekjohn.clark@gmail.com \
    --cc=hansg@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@antheas.dev \
    --cc=luke@ljones.dev \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox