From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5727534EEE2 for ; Wed, 4 Mar 2026 16:12:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772640734; cv=none; b=RFQn3M2D9iFYxt4ReXsnhpOO1rTi84Zjit0uQb5ZYDkSWCSz8ucINDhdkjGw04vgnhs9BG6RvlYIDcwJNo9MH7ZPi4cTUX8ZDstOAkVYxKPFcz7P9MVlR4nPobUEk1kmyfdm38i26SfG4LlRpY4gEhXbxu3k/Q2Fon6looNAAA8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772640734; c=relaxed/simple; bh=xYsJzU1dmsSFwD0vSaoyOtw1KMCz/KdpbeFonCurhRM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fgVGqUtvJJX2dyRt3wnvd1VewJ92h76VJskunVUYIJ3/xszD9iPcnmzA07/ckup5ehNpx/er+4w6kMdCtLECZfvMsnokmCiu3xPPQ0V11zr8lMN1/6C4l8lQ87f+GvrtzG57oXwI8UtxWCTM2v40p4A5jL8bC6KeViFDtP13u9U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=G5PRkcNr; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="G5PRkcNr" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-48375f10628so47366545e9.1 for ; Wed, 04 Mar 2026 08:12:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772640732; x=1773245532; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=EWWdCJuQGlN7X7iTx+gVa+1b409IvnSuR7fQE4Mf/lA=; b=G5PRkcNrzZZ9KIXuELKD359VGbICZzTsmVQDYAOwDVQOci8oK2Ua7SXD2d94l6x78r 4VnJeG5vP4pn25LfvytUGoT1goiORdOoHZ0xS19TLWqyXWdVvSQA1DqAafE7KrIfwMA4 mrnev2rbGuqyYxRb0wnR8UViYSPxHC+TDro3FldlRraCVHjz+T9nMu2lLfJ4H8SJM3Ui XZnxmsWFHvShOQaaR4spCkyBf1AYYW4oaiY5QHnFGE0c/3Nkhfu6d3IBLMjWaFCNTE+k yATCYPPb7f2o83Bs9kkjXsKRGmJ8r8k0tct7vg3YW8+T4AcfdWvN2AZe6Lji4ECy4k0l rpeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772640732; x=1773245532; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EWWdCJuQGlN7X7iTx+gVa+1b409IvnSuR7fQE4Mf/lA=; b=kUaQ1sOTi6k4FoK1nlPcgYUhAdrRCLGOQKrN2jbSx/7bdpvqSiCJEcwtG7czO9O8oN KFCUvghXCamQRDBFggo9tKqCENpiVs0cAwJxOzij+aiZ1svPpLvVLRrd2PH6TVmkqr/y YlBTInE/RNEgl12e1PbAa026lrMhK+LcPHv9yY9DLzGIPwan+y5BcOAoiPfkGVpbF+22 IK63aeOQCuGfRCXAyeBMyo4uLIP4RYpJHs7J5rLkB7FMNxXt3wzsl1wR9CgCUbiEoCFc SMvQVN92IUb1HoYhJsW4JuSi+PG6U4VE4zfASD9pU45rjsRqXKieAKdww+6Ra7+BEp40 mhlA== X-Gm-Message-State: AOJu0Yzv25hPcEJzkuvbijHmVAiNIY50mkd2JX0MlijhDF5BgKkmzWOD tpGlOuS1B8uimVn1n381zOw3EfyoUekTfhf51naEN8h9CwYuzsFUmkuf X-Gm-Gg: ATEYQzzHtx8VmDLZtn7n8xjq0T5506OtgnvIz1egPd37wfAfoD7hOsqNOy1WKfNSHeF EYMkL01yH7XNKUcnr3qoAgWsjp+jHzbd1BClIQIqH9qrEcuOvMzEpkdW8Evf1wy4FrReJkktBJU YZ3b0gtnjPPiVDfo/LoRJy6RCr+EslJO753E+elOHLVe3eAGDL8yzb+YCaNMN+k4XzGMmNEVQsi XFox6ZjoE05bOz0fv3akIDqPczFBYfhj1oKvfRw91UodQFBcAS9mX1qhnu0cHwOPvv2bP8uauyz EH0zP9EiZMKXmnVBF3SxncwdhRqfrJi1qqzTvWYIJhIrrp9LJx6oOe+t3PvPrfdWFaaP56+s0cs jbqAT7rKo4EKhRGnt4cF+H12lDPtnOOoYO8rxbVabrdmbUH1uhojitjSX5FanQKY+vk6rRRkwv5 nsr2hXEJd5qU3ppOp9v004AR4SrjqU3NhAKNLuQX6dxiju X-Received: by 2002:a05:600c:6099:b0:480:4ae2:def1 with SMTP id 5b1f17b1804b1-48519847dedmr50273295e9.13.1772640731303; Wed, 04 Mar 2026 08:12:11 -0800 (PST) Received: from [192.168.1.121] ([151.61.18.239]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485187bf2fcsm62564985e9.4.2026.03.04.08.12.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 08:12:10 -0800 (PST) Message-ID: Date: Wed, 4 Mar 2026 17:12:10 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] platform/x86: asus-wmi: do not enforce a battery charge threshold To: Antheas Kapenekakis , Denis Benato 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 From: Denis Benato In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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! > 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 >>>>>> >>>>>>