When setting charge_stop_threshold, charge_start_threshold is ALSO set with the same value

[mercmobily]

[x] I've read and accepted the Bug Reporting Howto [x] I've provided all required tlp-stat outputs via Gist (see below)

Describe the bug

I am having problems setting the thresholds with setcharge. The stop threshold is always set as the start threshold.

Expected behavioUr

I expect the start and stop threshold to be set properly.

To Reproduce

root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# tlp setcharge 93 94 BAT0
Setting temporary charge thresholds for BAT0:
  start =  93
  stop  =  94
root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# cat charge_start_threshold
93
root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# cat charge_stop_threshold
93
root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# 

Here is the gist for tlp-stat

Additional context

I thought it was a BIOS problem. So, I updated the BIOS to the latest version. The current bios was released in February 2022, so it's very up to date.

UPDATE

Actually this might well be a kernel problem... I tried with this:

root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# cat charge_start_threshold
93
root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# cat charge_stop_threshold
93
root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# echo 92 > /sys/class/power_supply/BAT0/charge_start_threshold 
root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# cat charge_start_threshold
92
root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# cat charge_stop_threshold
92
root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# 

So, it looks like the kernel is stubbornly setting the stop threshold the same as the start one, regardless of how it's set. Should I file a bug with them?

I am running this kernel: Linux merc-ThinkPad-X390-Yoga 5.15.0-22-generic #22-Ubuntu SMP Tue Feb 8 10:16:30 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

I am also getting weird issues while trying to set some values:

root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# echo 93 > /sys/class/power_supply/BAT0/charge_start_threshold 
root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# echo 92 > /sys/class/power_supply/BAT0/charge_start_threshold 
root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# echo 94 > /sys/class/power_supply/BAT0/charge_start_threshold 
-bash: echo: write error: Invalid argument
root@merc-ThinkPad-X390-Yoga:/sys/class/power_supply/BAT0# 

[mercmobily]

I realise this is most likely a kernel problem. Two questions:

1) Have you come across issues like these? 2) Which maintainer/subsystem shall I report this to?

Thanks

[linrunner]

Hi,

the best strategy is to always check the FAQ before opening an issue: Charge thresholds shown by tlp-stat -b do not correspond to the configured ones.

What you observe is a limitation of the ACPI calls used by the kernel to read the thresholds which occurs only for certain ThinkPad series. Afaik writing the thresholds works and the written values function correctly. The problem is just that the wrong values are read back from the EC.

Said ACPI calls (never officially documented by Lenovo) were first implemented in the tpacpi-bat tool ~10 years ago and have been implemented directly in the kernel module _thinkpadacpi with 4.17. Filing an issue here or a kernel bug will not suffice. You need at least figure out by reengineering which calls Lenovo's Vantage tool uses on your hardware.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/x86/thinkpad_acpi.c?id=HEAD#n9237

[mercmobily]

the best strategy is to always check the FAQ before opening an issue: Charge thresholds shown by tlp-stat -b do not correspond to the configured ones https://linrunner.de/tlp/faq/battery.html#charge-thresholds-shown-by-tlp-stat-b-do-not-correspond-to-the-configured-ones .

Apologies -- I did look, and even read that part, but didn't click that it was my problem. I should have figured it out -- sorry.

What you observe is a limitation of the ACPI calls used by the kernel to read the thresholds which occurs only for certain ThinkPad series. Afaik writing the thresholds works and the written values function correctly. The problem is just that the wrong values are read back from the EC.

OK.

Sazd ACPI calls (never officially documented by Lenovo) were first implemented in the tpacpi-bat tool ~10 years ago and have been implemented directly in the kernel module thinkpad_acpi with 4.17.

OK

Filing an issue here or a kernel bug will not suffice. You need at least figure out by reengineering which calls Lenovo's Vantage tool uses on your hardware.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/x86/thinkpad_acpi.c?id=HEAD#n9237

I am a software developer. These days I spend my days on Javascript. However, I do know C and AT&T Assembly.

I had never heard of Lenovo Vantage before. I am assuming it's one of those monstrous Windows-only app to "manage" your laptop.

I assume the way to do this would be to install Windows on my laptop, install Lenovo Vantage, run it with some development tools to trap I/O calls (no idea how to do that), and figure out what is being asked the battery exactly.

I could do that (installing Windows on an external disk), but I need some guidance. Is there a tutorial, or a cheat sheet, to get this done? I would like to help.

[linrunner]

I have no experience in the field and know of no such tutorial. My own many years of IT experience, leads me to believe that the required skills are quite broad and it is not done with a tutorial.

[mercmobily]

Well I can read and write assembler and used to be one of those annoying kids back in the 90s who would go through the code of video games to bypass copy protection... I didn't mean like a "step by step" tutorial, more like a list of tools and tricks to use. But all good, I will figure it out -- sorry for the bother!

[linrunner]

No problem. If you find out something, I can put you in contact with the kernel dev who last worked on the charge thresholds.

[mercmobily]

Thanks.

On Fri, 18 Mar 2022, 3:46 pm linrunner, @.***> wrote:

No problem. If you find out something, I can put you in contact with the kernel dev who last worked on the charge thresholds.

— Reply to this email directly, view it on GitHub https://github.com/linrunner/TLP/issues/627#issuecomment-1072108492, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQHWXQFWPD6BDS4WD3ITRDVAQYEVANCNFSM5Q5PJTQA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you modified the open/close state.Message ID: @.***>