From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) (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 4CF0B390234 for ; Wed, 4 Mar 2026 13:37:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772631422; cv=none; b=XxEsGEyIQjiN0URhvTAQu7gQkHvk5oVEGf4aENwY0Xu+WShLGlIpGyksCHiVnoXyCN2O8+2UcBwNzvqjszdkuEa63IA5XQ0YF6zKvzcH3zAI4hCsXfHd4y9Puu/BChqGTJclz+nhZWjpY7PXFM0z2yqCc1wNcePN9jQO+aSWuJI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772631422; c=relaxed/simple; bh=zkjSsOBsL2BSpYn+aQE7AI3TMi+qLRLVddFYIVLMl2w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=U82XfOguI8TSdfdJbaLwAU9Axm8ocyzkUQvvuAbwwdJLkDcOo/4hQ8k6l2obHe5dHnLdFFOFETM5Rz/Chs4N21Cp1qZmjz95Cqin/rogZNbSb8ePfmu7H4xw26LW2SMoAyrAEyOqGwOH5aCBfTEZHLDIx47fpJxDPi0e8EARrbg= 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=t2QQ5J/3; arc=none smtp.client-ip=95.215.58.176 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="t2QQ5J/3" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1772631418; 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=EIj9XLBcfTDcgaXVrpNLzw13xcJ4Pj1kurSh3pRWHCA=; b=t2QQ5J/3TgtgDhxgrGGFMULWR04ru/dFW+PKnycVFS09ptDLHymXQEkyCjNFVZfJQUnZ1p taDJ9Kfdzu6NcjfAiyX0YC/njeZR8IkCR154vvULKMswiHF6G+yJRORzQU9J4Uxa/gL1we n4dOpQQf2bYhRDrnce7xOwkUtBW37c4= Date: Wed, 4 Mar 2026 14:36:49 +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: 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 , Denis Benato 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 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 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 >> >>