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.
next prev parent 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.