All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Daasaradhi Mannava <daasaradhimannava@gmail.com>,
	 Denis Benato <denis.benato@linux.dev>
Cc: Nikita Kravets <teackot@gmail.com>,
	Hans de Goede <hansg@kernel.org>,
	 platform-driver-x86@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] platform/x86: msi-ec: Report valid charge thresholds when unset
Date: Thu, 17 Sep 2026 11:44:26 +0300 (EEST)	[thread overview]
Message-ID: <12cdf224-08aa-d19f-62fd-fbc6e26d6103@linux.intel.com> (raw)
In-Reply-To: <20260916174812.11496-1-daasaradhimannava@gmail.com>

On Wed, 16 Sep 2026, Daasaradhi Mannava wrote:

> The charge thresholds are computed by subtracting a fixed offset from
> the raw EC value. When no charge limit has been set, the EC can hold a
> value below range_min (0x80 on an MSI GL65 Leopard 9SCXK), and reading
> the sysfs attributes returns nonsense:
> 
>   charge_control_start_threshold: -10
>   charge_control_end_threshold:   0
> 
> Both attributes are documented to be within 0 - 100, and an end
> threshold of 0 wrongly suggests that charging is disabled.
> 
> The store path already rejects values outside range_min..range_max.
> Apply the same range to the show path and report the maximum threshold
> for any value outside of it.
> 
> Tested on an MSI GL65 Leopard 9SCXK (EC firmware 16U8EMS2.100) with
> the EC holding 0x80: the attributes now read 90 and 100.
> 
> Fixes: 392cacf2aa10 ("platform/x86: Add new msi-ec driver")
> Assisted-by: LLM
> Signed-off-by: Daasaradhi Mannava <daasaradhimannava@gmail.com>
> ---
>  drivers/platform/x86/msi-ec.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/platform/x86/msi-ec.c b/drivers/platform/x86/msi-ec.c
> index 566dfc73c..1762551e0 100644
> --- a/drivers/platform/x86/msi-ec.c
> +++ b/drivers/platform/x86/msi-ec.c
> @@ -1279,6 +1279,15 @@ static ssize_t charge_control_threshold_show(u8 offset,
>  	if (result < 0)
>  		return result;
>  
> +	/*
> +	 * The EC may hold an out-of-range value (e.g. 0x80) when no charge
> +	 * limit has been set. Report the maximum threshold instead of a
> +	 * meaningless (possibly negative) percentage.
> +	 */
> +	if (rdata < conf.charge_control.range_min ||
> +	    rdata > conf.charge_control.range_max)
> +		rdata = conf.charge_control.range_max;
> +
>  	return sysfs_emit(buf, "%i\n", rdata - offset);
>  }

Hi,

This seems similar to case in commits:

186bf9031666 ("platform/x86: asus-wmi: do not enforce a battery charge threshold")
78bf392ba77d ("platform/x86: asus-wmi: temporarily revert to setting a charge limit")

(The latter reverts first one as userspace could not handle -ENODATA but 
thought the feature was available.)

So ideally, I'd tend to think we'd want to return -ENODATA when the 
threshold hasn't been set. But whether userspace survives that is a 
question we cannot ignore.

-- 
 i.


  reply	other threads:[~2026-09-17  8:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16 17:48 [PATCH] platform/x86: msi-ec: Report valid charge thresholds when unset Daasaradhi Mannava
2026-09-17  8:44 ` Ilpo Järvinen [this message]
2026-09-18 18:49   ` Daasaradhi Mannava
2026-10-05 17:44 ` 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=12cdf224-08aa-d19f-62fd-fbc6e26d6103@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=daasaradhimannava@gmail.com \
    --cc=denis.benato@linux.dev \
    --cc=hansg@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=teackot@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.