[PATCH] platform/x86: msi-ec: Report valid charge thresholds when unset

[PATCH] platform/x86: msi-ec: Report valid charge thresholds when unset

[Daasaradhi Mannava]

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

Re: [PATCH] platform/x86: msi-ec: Report valid charge thresholds when unset

[Ilpo Järvinen]

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.

Re: [PATCH] platform/x86: msi-ec: Report valid charge thresholds when unset

[Daasaradhi Mannava]

[Resending as plain text, the lists rejected my previous reply.]

On Thu, 17 Sep 2026, Ilpo Järvinen wrote:
> 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.

Hi Ilpo,

Thanks for the pointers.

I agree -ENODATA describes the state better. The asus-wmi revert was
caused by upower's udev rule reading the attribute to detect support
(upower#347). That was fixed in upower 1.91.3 (commit 83f86c75,
July 2026), but current stable distros still ship older versions,
e.g. Debian 13 has 1.90.9 and Ubuntu 26.04 has 1.91.1. Returning
-ENODATA from msi-ec now would hide the GNOME battery health toggle
for most MSI users.

Unlike asus-wmi before 186bf9031666, msi-ec never writes the threshold
at boot, so this patch only changes what is reported: today it is
-10/0, which is outside the documented 0-100 range and makes the
limit look set to 0%.

So I'd suggest taking this patch as is for now, and switching both
drivers to -ENODATA together once a fixed upower is widely available.
If you'd rather have -ENODATA right away, I'm happy to send a v2.

Thanks,
Daasaradhi