[PATCH] platform/x86: asus-wmi: temporarily revert to setting a charge limit

[PATCH] platform/x86: asus-wmi: temporarily revert to setting a charge limit

[Denis Benato]

A userspace regression has been observed leaving the battery charging
threshold unconfigured, so while the situation is being sorted revert
the change keeping the infrastructure in place to return to the
preferred behaviour whenever possible.

Link: https://gitlab.freedesktop.org/upower/upower/-/work_items/347
Closes: https://lore.kernel.org/all/CABsFS_g+V_Owum6knLhenhM15EXJRrsF0FcLiw30WZxarsTpUA@mail.gmail.com/

Signed-off-by: Denis Benato <denis.benato@linux.dev>
---
 drivers/platform/x86/asus-wmi.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 3c9ef826551d..e835779b6f5f 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1618,6 +1618,8 @@ static DEVICE_ATTR_RW(charge_control_end_threshold);
 
 static int asus_wmi_battery_add(struct power_supply *battery, struct acpi_battery_hook *hook)
 {
+	int ret, rv;
+
 	/* The WMI method does not provide a way to specific a battery, so we
 	 * just assume it is the first battery.
 	 * Note: On some newer ASUS laptops (Zenbook UM431DA), the primary/first
@@ -1635,12 +1637,30 @@ static int asus_wmi_battery_add(struct power_supply *battery, struct acpi_batter
 
 	/* The charge threshold is only reset when the system is power cycled,
 	 * 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.
+	 * platforms retains it.
+	 *
+	 * Setting a negative value would signal the threshold as unknown
+	 * until user explicitly sets it to a new value, however to avoid
+	 * regressing userspace, we initialize it to a value of 100.
 	 */
-	charge_end_threshold = -1;
+	charge_end_threshold = 100;
+	ret = asus_wmi_set_devstate(ASUS_WMI_DEVID_RSOC, charge_end_threshold, &rv);
+	if (ret) {
+		pr_err("Failed to reset battery charge threshold\n");
+		goto asus_wmi_battery_add_err;
+	}
+
+	if (rv != 1) {
+		pr_err("Error in battery charge threshold reset\n");
+		ret = -EIO;
+		goto asus_wmi_battery_add_err;
+	}
 
 	return 0;
+asus_wmi_battery_add_err:
+	device_remove_file(&battery->dev,
+			   &dev_attr_charge_control_end_threshold);
+	return ret;
 }
 
 static int asus_wmi_battery_remove(struct power_supply *battery, struct acpi_battery_hook *hook)
-- 
2.47.3

Re: [PATCH] platform/x86: asus-wmi: temporarily revert to setting a charge limit

[Ilpo Järvinen]

On Tue, 30 Jun 2026, Denis Benato wrote:

> A userspace regression has been observed leaving the battery charging
> threshold unconfigured, so while the situation is being sorted revert
> the change keeping the infrastructure in place to return to the
> preferred behaviour whenever possible.
> 
> Link: https://gitlab.freedesktop.org/upower/upower/-/work_items/347
> Closes: https://lore.kernel.org/all/CABsFS_g+V_Owum6knLhenhM15EXJRrsF0FcLiw30WZxarsTpUA@mail.gmail.com/
> 

Reported-by ?

No blank lines in tags block please.

How stable people will know which kernel this should go? The easiest way 
is put Fixes tag for that purpose. If don't want to say this "fixes" 
things, also Cc: stable... # [instruction here] is possible (more 
information about formatting in stable-kernel-rules.rst).

-- 
 i.

> Signed-off-by: Denis Benato <denis.benato@linux.dev>
> ---
>  drivers/platform/x86/asus-wmi.c | 26 +++++++++++++++++++++++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index 3c9ef826551d..e835779b6f5f 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c
> @@ -1618,6 +1618,8 @@ static DEVICE_ATTR_RW(charge_control_end_threshold);
>  
>  static int asus_wmi_battery_add(struct power_supply *battery, struct acpi_battery_hook *hook)
>  {
> +	int ret, rv;
> +
>  	/* The WMI method does not provide a way to specific a battery, so we
>  	 * just assume it is the first battery.
>  	 * Note: On some newer ASUS laptops (Zenbook UM431DA), the primary/first
> @@ -1635,12 +1637,30 @@ static int asus_wmi_battery_add(struct power_supply *battery, struct acpi_batter
>  
>  	/* The charge threshold is only reset when the system is power cycled,
>  	 * 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.
> +	 * platforms retains it.
> +	 *
> +	 * Setting a negative value would signal the threshold as unknown
> +	 * until user explicitly sets it to a new value, however to avoid
> +	 * regressing userspace, we initialize it to a value of 100.
>  	 */
> -	charge_end_threshold = -1;
> +	charge_end_threshold = 100;
> +	ret = asus_wmi_set_devstate(ASUS_WMI_DEVID_RSOC, charge_end_threshold, &rv);
> +	if (ret) {
> +		pr_err("Failed to reset battery charge threshold\n");
> +		goto asus_wmi_battery_add_err;
> +	}
> +
> +	if (rv != 1) {
> +		pr_err("Error in battery charge threshold reset\n");
> +		ret = -EIO;
> +		goto asus_wmi_battery_add_err;
> +	}
>  
>  	return 0;
> +asus_wmi_battery_add_err:
> +	device_remove_file(&battery->dev,
> +			   &dev_attr_charge_control_end_threshold);
> +	return ret;
>  }
>  
>  static int asus_wmi_battery_remove(struct power_supply *battery, struct acpi_battery_hook *hook)
> 

Re: [PATCH] platform/x86: asus-wmi: temporarily revert to setting a charge limit

[Kate Hsuan]

Hi Denis,

Upower 1.91.3 has been released, including a fix for issue #347 [1]. 
This release addresses the -ENODATA  encountered when accessing charge 
limits on Asus laptops, which previously caused UPower and GNOME to 
incorrectly report charge threshold support as unavailable. The fix 
updates the udev rule to verify file existence rather than reading the 
attribute directly. The corresponding commit can be found at:

https://gitlab.freedesktop.org/upower/upower/-/commit/83f86c75d28a57854a4b5986cbfb701249a5b6ad

[1] https://gitlab.freedesktop.org/upower/upower/-/work_items/347

Thank you :)

On 6/30/26 7:09 PM, Denis Benato wrote:
> A userspace regression has been observed leaving the battery charging
> threshold unconfigured, so while the situation is being sorted revert
> the change keeping the infrastructure in place to return to the
> preferred behaviour whenever possible.
>
> Link: https://gitlab.freedesktop.org/upower/upower/-/work_items/347
> Closes: https://lore.kernel.org/all/CABsFS_g+V_Owum6knLhenhM15EXJRrsF0FcLiw30WZxarsTpUA@mail.gmail.com/
>
> Signed-off-by: Denis Benato <denis.benato@linux.dev>
> ---
>   drivers/platform/x86/asus-wmi.c | 26 +++++++++++++++++++++++---
>   1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index 3c9ef826551d..e835779b6f5f 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c
> @@ -1618,6 +1618,8 @@ static DEVICE_ATTR_RW(charge_control_end_threshold);
>   
>   static int asus_wmi_battery_add(struct power_supply *battery, struct acpi_battery_hook *hook)
>   {
> +	int ret, rv;
> +
>   	/* The WMI method does not provide a way to specific a battery, so we
>   	 * just assume it is the first battery.
>   	 * Note: On some newer ASUS laptops (Zenbook UM431DA), the primary/first
> @@ -1635,12 +1637,30 @@ static int asus_wmi_battery_add(struct power_supply *battery, struct acpi_batter
>   
>   	/* The charge threshold is only reset when the system is power cycled,
>   	 * 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.
> +	 * platforms retains it.
> +	 *
> +	 * Setting a negative value would signal the threshold as unknown
> +	 * until user explicitly sets it to a new value, however to avoid
> +	 * regressing userspace, we initialize it to a value of 100.
>   	 */
> -	charge_end_threshold = -1;
> +	charge_end_threshold = 100;
> +	ret = asus_wmi_set_devstate(ASUS_WMI_DEVID_RSOC, charge_end_threshold, &rv);
> +	if (ret) {
> +		pr_err("Failed to reset battery charge threshold\n");
> +		goto asus_wmi_battery_add_err;
> +	}
> +
> +	if (rv != 1) {
> +		pr_err("Error in battery charge threshold reset\n");
> +		ret = -EIO;
> +		goto asus_wmi_battery_add_err;
> +	}
>   
>   	return 0;
> +asus_wmi_battery_add_err:
> +	device_remove_file(&battery->dev,
> +			   &dev_attr_charge_control_end_threshold);
> +	return ret;
>   }
>   
>   static int asus_wmi_battery_remove(struct power_supply *battery, struct acpi_battery_hook *hook)

Re: [PATCH] platform/x86: asus-wmi: temporarily revert to setting a charge limit

[Denis Benato]

On 7/9/26 05:52, Kate Hsuan wrote:
> Hi Denis,
>
> Upower 1.91.3 has been released, including a fix for issue #347 [1]. This release addresses the -ENODATA  encountered when accessing charge limits on Asus laptops, which previously caused UPower and GNOME to incorrectly report charge threshold support as unavailable. The fix updates the udev rule to verify file existence rather than reading the attribute directly. The corresponding commit can be found at:
>
> https://gitlab.freedesktop.org/upower/upower/-/commit/83f86c75d28a57854a4b5986cbfb701249a5b6ad
>
> [1] https://gitlab.freedesktop.org/upower/upower/-/work_items/347
>
> Thank you :) 
>
Thank you very much Hsuan!

Ilpo: what do we do now? I am preparing the fixed patch to revert this for stable and will soon send it.

How much do we wait to revert the revert? Or do I simply Cc stable and you don't pick the revert
in the newer kernel? In any case just say what I need to do and I'll do it.

Thanks,
Denis

> On 6/30/26 7:09 PM, Denis Benato wrote:
>> A userspace regression has been observed leaving the battery charging
>> threshold unconfigured, so while the situation is being sorted revert
>> the change keeping the infrastructure in place to return to the
>> preferred behaviour whenever possible.
>>
>> Link: https://gitlab.freedesktop.org/upower/upower/-/work_items/347
>> Closes: https://lore.kernel.org/all/CABsFS_g+V_Owum6knLhenhM15EXJRrsF0FcLiw30WZxarsTpUA@mail.gmail.com/
>>
>> Signed-off-by: Denis Benato <denis.benato@linux.dev>
>> ---
>>   drivers/platform/x86/asus-wmi.c | 26 +++++++++++++++++++++++---
>>   1 file changed, 23 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
>> index 3c9ef826551d..e835779b6f5f 100644
>> --- a/drivers/platform/x86/asus-wmi.c
>> +++ b/drivers/platform/x86/asus-wmi.c
>> @@ -1618,6 +1618,8 @@ static DEVICE_ATTR_RW(charge_control_end_threshold);
>>     static int asus_wmi_battery_add(struct power_supply *battery, struct acpi_battery_hook *hook)
>>   {
>> +    int ret, rv;
>> +
>>       /* The WMI method does not provide a way to specific a battery, so we
>>        * just assume it is the first battery.
>>        * Note: On some newer ASUS laptops (Zenbook UM431DA), the primary/first
>> @@ -1635,12 +1637,30 @@ static int asus_wmi_battery_add(struct power_supply *battery, struct acpi_batter
>>         /* The charge threshold is only reset when the system is power cycled,
>>        * 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.
>> +     * platforms retains it.
>> +     *
>> +     * Setting a negative value would signal the threshold as unknown
>> +     * until user explicitly sets it to a new value, however to avoid
>> +     * regressing userspace, we initialize it to a value of 100.
>>        */
>> -    charge_end_threshold = -1;
>> +    charge_end_threshold = 100;
>> +    ret = asus_wmi_set_devstate(ASUS_WMI_DEVID_RSOC, charge_end_threshold, &rv);
>> +    if (ret) {
>> +        pr_err("Failed to reset battery charge threshold\n");
>> +        goto asus_wmi_battery_add_err;
>> +    }
>> +
>> +    if (rv != 1) {
>> +        pr_err("Error in battery charge threshold reset\n");
>> +        ret = -EIO;
>> +        goto asus_wmi_battery_add_err;
>> +    }
>>         return 0;
>> +asus_wmi_battery_add_err:
>> +    device_remove_file(&battery->dev,
>> +               &dev_attr_charge_control_end_threshold);
>> +    return ret;
>>   }
>>     static int asus_wmi_battery_remove(struct power_supply *battery, struct acpi_battery_hook *hook)
>

[PATCH] platform/x86: asus-wmi: temporarily revert to setting a charge limit

[Denis Benato]

A userspace regression has been observed leaving the battery charging
threshold unconfigured, so while the fix is being shipped revert
the change keeping the infrastructure in place to return to the
preferred behaviour as soon as it's appropriate to do.

Link: https://lore.kernel.org/all/5db117b7-aad1-437f-a3d4-ba7b29fc68b3@redhat.com/
Link: https://gitlab.freedesktop.org/upower/upower/-/work_items/347
Closes: https://lore.kernel.org/all/CABsFS_g+V_Owum6knLhenhM15EXJRrsF0FcLiw30WZxarsTpUA@mail.gmail.com/
Fixes: 186bf9031666 ("platform/x86: asus-wmi: do not enforce a battery charge threshold")
Reported-by: Travers Biddle <traversbiddle@gmail.com>
Signed-off-by: Denis Benato <denis.benato@linux.dev>
---
 drivers/platform/x86/asus-wmi.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index c7c8fcfc1d72..0adb5cebf523 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1618,6 +1618,8 @@ static DEVICE_ATTR_RW(charge_control_end_threshold);
 
 static int asus_wmi_battery_add(struct power_supply *battery, struct acpi_battery_hook *hook)
 {
+	int ret, rv;
+
 	/* The WMI method does not provide a way to specific a battery, so we
 	 * just assume it is the first battery.
 	 * Note: On some newer ASUS laptops (Zenbook UM431DA), the primary/first
@@ -1635,12 +1637,30 @@ static int asus_wmi_battery_add(struct power_supply *battery, struct acpi_batter
 
 	/* The charge threshold is only reset when the system is power cycled,
 	 * 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.
+	 * platforms retains it.
+	 *
+	 * Setting a negative value would signal the threshold as unknown
+	 * until user explicitly sets it to a new value, however to avoid
+	 * regressing userspace, we initialize it to a value of 100.
 	 */
-	charge_end_threshold = -1;
+	charge_end_threshold = 100;
+	ret = asus_wmi_set_devstate(ASUS_WMI_DEVID_RSOC, charge_end_threshold, &rv);
+	if (ret) {
+		pr_err("Failed to reset battery charge threshold\n");
+		goto asus_wmi_battery_add_err;
+	}
+
+	if (rv != 1) {
+		pr_err("Error in battery charge threshold reset\n");
+		ret = -EIO;
+		goto asus_wmi_battery_add_err;
+	}
 
 	return 0;
+asus_wmi_battery_add_err:
+	device_remove_file(&battery->dev,
+			   &dev_attr_charge_control_end_threshold);
+	return ret;
 }
 
 static int asus_wmi_battery_remove(struct power_supply *battery, struct acpi_battery_hook *hook)
-- 
2.47.3

Re: [PATCH] platform/x86: asus-wmi: temporarily revert to setting a charge limit

[Ilpo Järvinen]

On Fri, 10 Jul 2026 16:58:41 +0000, Denis Benato wrote:

> A userspace regression has been observed leaving the battery charging
> threshold unconfigured, so while the fix is being shipped revert
> the change keeping the infrastructure in place to return to the
> preferred behaviour as soon as it's appropriate to do.


Thank you for your contribution, it has been applied to my local
review-ilpo-fixes branch. Note it will show up in the public
platform-drivers-x86/review-ilpo-fixes 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: temporarily revert to setting a charge limit
      commit: 78bf392ba77dd8b2a25656e489449d2f91cfd1eb

--
 i.