3.3 release breaks access to charge thresholds, fn_lock on 18.04 about huawei-wmi

[aymanbagabas]

Can you please try https://github.com/aymanbagabas/Huawei-WMI/tree/fix-v3.3

[BigBossAnwer]

Success!
Looks like the null pointer fix was on the money. On fix-v3.3, it looks like all battery charge protection and fn_lock functionality has returned and the control files exists / are writable:

Install
Installed using build from source as described in the readme:

1. Kernel headers (Debian): sudo apt-get install linux-headers-$(uname -r)

2. Build:

git clone --single-branch --branch fix-v3.3 https://github.com/aymanbagabas/Huawei-WMI
cd Huawei-WMI
make

3. Update:

sudo mkdir -p  /lib/modules/$(uname -r)/updates/
sudo cp huawei-wmi.ko /lib/modules/$(uname -r)/updates/
sudo depmod
reboot

4. Install as described in readme threw some errors (that might be a consequence of my environment) / not sure if it worked (didn't matter as the update approach worked, just including it in case it helps):
   sudo make install
   throws

make -C /lib/modules/5.0.0-37-generic/build/ M=/home/devblade/Downloads/Huawei-WMI modules_install
make[1]: Entering directory '/usr/src/linux-headers-5.0.0-37-generic'
  INSTALL /home/devblade/Downloads/Huawei-WMI/huawei-wmi.ko
At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: ../crypto/bio/bss_file.c:72
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: ../crypto/bio/bss_file.c:79
sign-file: certs/signing_key.pem: No such file or directory
  DEPMOD  5.0.0-37-generic
Warning: modules_install: missing 'System.map' file. Skipping depmod.
make[1]: Leaving directory '/usr/src/linux-headers-5.0.0-37-generic'
depmod -a

Just in case this helps:
Dmesg log on 3.3 fix: dmesg3.3fix.txt

Thank you for the incredibly quick turnaround as well as the awesome work you've done here on this! It is deeply appreciated!

[aymanbagabas]

Hey, I've updated fix-v3.3 branch. Could you please verify that it's working and provide a dmesg log? This is critical since v3.3 is part of kernel 5.5 and if this is causing a bug we have to fix it asap. I just wanna verify that my fix works. Thank you!

[BigBossAnwer]

All functionality continues to function as expected on the current fix-v3.3 branch.
Install:

Functionality:

Dmesg log:
dmesg3.3-2.txt

[aymanbagabas]

Thank you!

[aymanbagabas]

I've released v3.4. I'd love if you can test it and provide a dmesg log.

[BigBossAnwer]

Lack of Access / Functionality in 3.4 release

Describe the bug
Updated to version 3.4, and I no longer have access to the charge threshold control files (/sys/class/power_supply/BAT0/charge_control_{start,end}_threshold, and /sys/devices/platform/huawei-wmi/charge_control_thresholds), as well as no access to the fn_lock control file at /sys/devices/platform/huawei-wmi/fn_lock_state:

While on version 3.2 and 3.3fix all files /sys/devices/platform/huawei-wmi/charge_thresholds, and /sys/devices/platform/huawei-wmi/fn_lock_state were accessible / writable

To Reproduce
Steps to reproduce the behavior:

1. Download huawei-wmi-3.4-source-only.dkms.tar.gz from the release page
2. Add dkms tarball and install module according to instructions in the readme
3. Reboot
4. "Lose" access to charge / fn_lock control files

Expected behavior
Writable files at the locations indicated in the readme to control battery protection charge levels and fn_lock state

Desktop:

• Kernel: Linux devblade-MPX9 5.0.0-37-generic #40~18.04.1-Ubuntu SMP Thu Nov 14 12:06:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
• Distro: KDE Neon User 5.17
• Loaded WMI modules:

snd_rawmidi            36864  1 snd_seq_midi
snd_seq_device         16384  3 snd_seq,snd_seq_midi,snd_rawmidi
huawei_wmi             20480  1
ledtrig_audio          16384  3 snd_hda_codec_generic,huawei_wmi,snd_hda_codec_realtek
snd                    86016  19 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_compress,snd_soc_core,snd_pcm,snd_rawmidi
sparse_keymap          16384  1 huawei_wmi
intel_wmi_thunderbolt    20480  0
wmi_bmof               16384  0
wmi                    28672  3 intel_wmi_thunderbolt,huawei_wmi,wmi_bmof

• DKMS Status:

acpi-call, 1.1.0, 4.15.0-60-generic, x86_64: installed
acpi-call, 1.1.0, 4.15.0-62-generic, x86_64: installed
acpi-call, 1.1.0, 4.15.0-64-generic, x86_64: installed
acpi-call, 1.1.0, 4.15.0-65-generic, x86_64: installed
acpi-call, 1.1.0, 4.15.0-66-generic, x86_64: installed
acpi-call, 1.1.0, 4.15.0-69-generic, x86_64: installed
acpi-call, 1.1.0, 4.15.0-70-generic, x86_64: installed
acpi-call, 1.1.0, 4.15.0-72-generic, x86_64: installed
acpi-call, 1.1.0, 5.0.0-36-generic, x86_64: installed
acpi-call, 1.1.0, 5.0.0-37-generic, x86_64: installed
bbswitch, 0.8, 4.15.0-60-generic, x86_64: installed
bbswitch, 0.8, 4.15.0-62-generic, x86_64: installed
bbswitch, 0.8, 4.15.0-64-generic, x86_64: installed
bbswitch, 0.8, 4.15.0-65-generic, x86_64: installed
bbswitch, 0.8, 4.15.0-66-generic, x86_64: installed
bbswitch, 0.8, 4.15.0-69-generic, x86_64: installed
bbswitch, 0.8, 4.15.0-70-generic, x86_64: installed
bbswitch, 0.8, 4.15.0-72-generic, x86_64: installed
bbswitch, 0.8, 5.0.0-36-generic, x86_64: installed
bbswitch, 0.8, 5.0.0-37-generic, x86_64: installed
huawei-wmi, 3.2, 5.0.0-36-generic, x86_64: installed (original_module exists)
huawei-wmi, 3.2, 5.0.0-37-generic, x86_64: built (original_module exists)
huawei-wmi, 3.3, 5.0.0-37-generic, x86_64: built (original_module exists)
huawei-wmi, 3.4, 5.0.0-37-generic, x86_64: installed (original_module exists)
nvidia, 430.50, 4.15.0-69-generic, x86_64: installed
nvidia, 430.50, 4.15.0-70-generic, x86_64: installed
nvidia, 430.50, 4.15.0-72-generic, x86_64: installed
nvidia, 430.50, 5.0.0-36-generic, x86_64: installed
nvidia, 430.50, 5.0.0-37-generic, x86_64: installed

• Dmesg log: dmesg3.4.txt

[BigBossAnwer]

Fixed with merge of master with fix-v3.3/huawei-wmi.c

Poked around the diff between master and fix-v3.3 and noticed the null pointer issue might still be there (fix-v3.3 on left, current 3.4 master on right):

Merged those two line changes and built from source / installed. All control files are writable again and functionality has been restored:

"Fixed" huawei-wmi.c
Diff (current 3.4 master on left, current 3.4 master merged with fix-v3.3 on left): https://www.diffchecker.com/XdJCgwLf
3.4 Master huawei-wmi.c merged with fix-v3.3 huawei-wmi.c huawei-wmi.c.fix3.4.txt

Master3.4_fix-v3.3_merge Dmesg Log: dmesg3.4fix.txt

As an aside it seems Install as described in readme continues to throw some errors (again not sure if just a consequence of my environment). Which again it didn't matter as the update approach worked, just noteing it in case it helps.
sudo make install throws:

Huawei-WMI on  master [!] took 3s 
λ sudo make install
[sudo] password for devblade: 
make -C /lib/modules/5.0.0-37-generic/build/ M=/home/devblade/Downloads/Huawei-WMI modules_install
make[1]: Entering directory '/usr/src/linux-headers-5.0.0-37-generic'
  INSTALL /home/devblade/Downloads/Huawei-WMI/huawei-wmi.ko
At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: ../crypto/bio/bss_file.c:72
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: ../crypto/bio/bss_file.c:79
sign-file: certs/signing_key.pem: No such file or directory
  DEPMOD  5.0.0-37-generic
Warning: modules_install: missing 'System.map' file. Skipping depmod.
make[1]: Leaving directory '/usr/src/linux-headers-5.0.0-37-generic'
depmod -a

[aymanbagabas]

Just use v3.2. This is happening because in kernel 5.0, the struct wmi_device_id has a pointer initialized to NULL by default. So when dereferencing that, it causes an error. Kernel 5.1 and above use a fixed-size string so dereferencing that would give a zero not a NULL pointer dereference error.

I've also updated the README to say use v3.2 when using 5.0

Thank you!

[BigBossAnwer]

Sure thing! Thank you again for the work you've done here.

Just curious, what was the functionality change that resulted from using the battery charge api in 3.3?

[aymanbagabas]

This way it's more standard and follows the kernel api instead of creating an arbitrary module attribute like the one in v3.2. The next task would be to use something like TLP to control this. You can see that they already have a working one here but it's only for ThinkPads (not sure, haven't tested it). You could also use udev to auto-set these values on every boot.