From: Daasaradhi Mannava <daasaradhimannava@gmail.com>
To: "Nikita Kravets" <teackot@gmail.com>,
"Hans de Goede" <hansg@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org,
Daasaradhi Mannava <daasaradhimannava@gmail.com>
Subject: [PATCH] platform/x86: msi-ec: Report valid charge thresholds when unset
Date: Wed, 16 Sep 2026 17:48:12 +0000 [thread overview]
Message-ID: <20260916174812.11496-1-daasaradhimannava@gmail.com> (raw)
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);
}
--
2.55.0
next reply other threads:[~2026-09-16 17:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 17:48 Daasaradhi Mannava [this message]
2026-09-17 8:44 ` Ilpo Järvinen
2026-09-18 18:49 ` Daasaradhi Mannava
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=20260916174812.11496-1-daasaradhimannava@gmail.com \
--to=daasaradhimannava@gmail.com \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®