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

[Daasaradhi Mannava <daasaradhimannava@gmail.com>]

[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