From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EEAE12309B2 for ; Wed, 18 Mar 2026 14:16:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773843404; cv=none; b=UGdQ5FxYxOcoMOI4bVCn6nSg83ov8IbKWFHBpw1+IoKLI5Chp/Y+BvTnqDwWOawW6Sqqt4kAyYeHZGBEdsTc6K1hk4VN5bgrPwDY7FpctKklanV5iZijoNjjzffGtZ/3Sx2UXwzLaspXwSv/Cdwg+FlFIGaxd5zbBd9V62ooAVw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773843404; c=relaxed/simple; bh=592Skkw5UZ7NoiHvZZKMKRHtD96L5DkEhvXVn0UaBPo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QpV9jylNCTzXPAX83CptYm2Ymfyv43Xjyogxy2o7QO2nWxyLhphyJZBbbfVAECIzHCHtnQpWnsvyB8L1Dcd3fvANeTZBhaocSjNYy0kq4oeo4FDrfKG4NIlNAJnEdd3a9Lnb4izw75Cgn+1e7pmM5iOYtYBUeN4c7lCU+tBDJ6A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=jHeV4jQo; arc=none smtp.client-ip=91.218.175.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="jHeV4jQo" Message-ID: <21f1e4d6-10a1-403e-a1f0-8658655d2557@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1773843389; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RQswZ4y5OucjNc4joUKNR64/Rl+IXO2Y/BMhP3ifY00=; b=jHeV4jQo8yYhZJOMrpzw10Ut+sx1rgWEc708XjrgpbGmaQNa6NSz81mcrywzNYXZdbwEsl nid4xewJkk7wzcFZocQDiVQXFvh6DrlRX+ZdpcEV7/+FpWpfGWpoJiEVcB1rBzAkv8SQWR MQf+1qWMBRRdr2Ya7gEgXZfiXovP4ug= Date: Wed, 18 Mar 2026 15:16:26 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] platform/x86: asus-wmi: do not enforce a battery charge threshold To: Denis Benato , Antheas Kapenekakis Cc: linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, Hans de Goede , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , "Luke D . Jones" , Derek John Clark References: <20260304132608.33815-1-denis.benato@linux.dev> Content-Language: en-US, it-IT, en-US-large X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Denis Benato In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT 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 wrote: >>> On 3/4/26 14:39, Antheas Kapenekakis wrote: >>>> On Wed, 4 Mar 2026 at 14:37, Denis Benato wrote: >>>>> On 3/4/26 14:30, Antheas Kapenekakis wrote: >>>>>> On Wed, 4 Mar 2026 at 14:26, 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. 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 >>>>>>> Suggested-by: Derek J. Clark >>>>>>> Signed-off-by: Denis Benato >>>>>>> --- >>>>>>> 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 >>>>>>> >>>>>>>