FAILED message in system boot log about "Huawei WMI Reinstate". charge_thresholds: No such file or directory

[RangerNJU]

Describe the bug "Fail to get WMI Privilege and Reinstate" message in system boot log.

To Reproduce Install the 3.4 version driver via DKMS . Boot using ly and Archlinux with lts kernel version: 5.4.72-1-lts.

Type sudo journalctl and search for Huawei WMI Reinstate.

Then you will see messages like:

Oct 20 11:49:39 Mi3 chgrp[901]: /usr/bin/chgrp: cannot access '/sys/devices/platform/huawei-wmi/charge_thresholds': No such file or directory
Oct 20 11:49:39 Mi3 systemd[1]: huawei-wmi-privilege.service: Main process exited, code=exited, status=1/FAILURE
Oct 20 11:49:39 Mi3 systemd[1]: huawei-wmi-privilege.service: Failed with result 'exit-code'.
Oct 20 11:49:39 Mi3 systemd[1]: Failed to start Huawei WMI Privilege.
Oct 20 11:49:39 Mi3 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=huawei-wmi-privilege comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Oct 20 11:49:39 Mi3 systemd[1]: Starting Huawei WMI Reinstate...
Oct 20 11:49:39 Mi3 sh[903]: cat: /sys/devices/platform/huawei-wmi/charge_thresholds: No such file or directory
Oct 20 11:49:39 Mi3 sh[902]: Old charge thresholds
Oct 20 11:49:39 Mi3 sh[905]: /usr/bin/sh: /sys/devices/platform/huawei-wmi/charge_thresholds: Permission denied
Oct 20 11:49:39 Mi3 systemd[1]: huawei-wmi-reinstate.service: Main process exited, code=exited, status=1/FAILURE
Oct 20 11:49:39 Mi3 systemd[1]: huawei-wmi-reinstate.service: Failed with result 'exit-code'.
Oct 20 11:49:39 Mi3 systemd[1]: Failed to start Huawei WMI Reinstate.

Expected behavior No such error messages in system boot log.

Desktop (please complete the following information):

• Kernel [5.4.72-1-lts] uname -a

• Distro [Arch Linux] `

• Loaded WMI modules lsmod | grep wmi

  huawei_wmi             24576  0
  ledtrig_audio          16384  3 snd_hda_codec_generic,huawei_wmi,snd_hda_codec_realtek
  sparse_keymap          16384  1 huawei_wmi
  wmi_bmof               16384  0
  intel_wmi_thunderbolt    20480  0
  wmi                    36864  3 intel_wmi_thunderbolt,huawei_wmi,wmi_bmof
  battery                20480  1 huawei_wmi

• Dmesg log dmesg > dmesg.txt it's very long(~900 lines) and maybe no need at all.

• ALSA log if applicable alsa-info.sh maybe no need at all.

Additional context Since the config file related to charging is now called charge_control_thresholds, which is not match with charge_thresholds, a simple solution may be just check out the source files and edit so that the filename matches?(However I'm not sure where to edit)

[nekr0z]

This is the issue with the service, not the driver, and should be reported there (although I believe in can be easily fixed by simply updating the service to the current version).

[n3vu0r]

Yes, the latest version (master branch) works with the new (charge_control_thresholds) driver interface.

[aymanbagabas]

It was named that way to match the kernel ABI https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-power

[RangerNJU]

Thank you everyone for your quick response:)

Yes, the latest version (master branch) works with the new (charge_control_thresholds) driver interface.

I've search AUR but got no package for the service, I'm wondering whether the Makefile is compatible with Arch? In other words, all I need to do is clone the service then go to the generic folder and sudo make install ?(Maybe a better practice would be copy the commands in the Makefile and execute them manually.)

BTW is the service only about the Start and end thresholds getting reset issue? I didn't notice such issue using Matebook13 2019 i3 version for the last 24 hours. Can I simply disable the service if the thresholds won't get reset at all?

[RangerNJU]

update: the thresholds get reset to 0 0, and by default the battery won't charge in this situation, which is fine for me.

[nekr0z]

@RangerNJU

• The service does things other than mitigate the thresholds reset. You may or may not need those things, it's entirely up to you whether to use the service or just use the driver.
• Creating and maintaining an AUR package is really easy. If you think one is needed, why don't you do that?
• Distribution-specific question are better asked where the distribution is discussed. The Makefile in question is supposed to work in any sanely maintained Linux installation, independent of the distribution. Whether it is compatible with "the Arch way", whatever that may be, or even works with Arch, is something to ask Arch people.
• Either you are mistaken or your model is an interesting one. All the models I've encountered until now threat 0 0 as "battery protection off, charge whenever plugged". Can you please double-check that your device refuses to charge when set to 0 0? I may need to take this corner case into account for the applet.
• I'm sorry I repeat myself, but it's not really polite to continue discussing a whole other project in this repository. There may be people subscribed to this repository that don't care about the service at all; for them, the emails with the comments on this issue are just spam.

[RangerNJU]

I'd like to close this issue and say sorry to everyone subscribed to this repository that don't care about the service. Thank you for your courtesy and patience @nekr0z .

• I'll check out how to create and maintain an AUR package later.
• When set to 0 0 and plugged, my device keeps the current battery charge percentage(in other words, won't charge to 100 percent). I get the motherboard replaced at the official service center last weekend, not sure if it is related.