[Framework] Battery care support for Framework A5 Laptop 13 (AMD Ryzen 7040 Series) not loaded - BIOS 3.09 needs a patch expected with Linux 6.17

[BarbUk]

[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

Following https://github.com/linrunner/TLP/issues/765:

• cros_charge-control is loaded

$ modinfo cros_charge-control
filename:       /lib/modules/6.15.4-4-cachyos/kernel/drivers/power/supply/cros_charge-control.ko.zst
license:        GPL
author:         Thomas Weißschuh <[email protected]>
description:    ChromeOS EC charge control
srcversion:     058B681F79D9FB098B3EDBF
alias:          platform:cros-charge-control
depends:        
intree:         Y
name:           cros_charge_control
retpoline:      Y
vermagic:       6.15.4-4-cachyos SMP preempt mod_unload 

• battery care plugin shows as:

Plugin: generic
Supported features: none available

Expected behavior

Plugin: cros-ec should be loaded ?

To Reproduce

1. Does the problem occur on battery or AC or both?

Both

Stats

tlp-stat -v -s -b

tlp-stat on AC

tlp-stat on BAT

dmi

$ grep . /sys/class/dmi/id/*
/sys/class/dmi/id/bios_date:04/22/2025
/sys/class/dmi/id/bios_release:3.9
/sys/class/dmi/id/bios_vendor:INSYDE Corp.
/sys/class/dmi/id/bios_version:03.09
/sys/class/dmi/id/board_asset_tag:*
/sys/class/dmi/id/board_name:FRANMDCP05
/sys/class/dmi/id/board_vendor:Framework
/sys/class/dmi/id/board_version:A5
/sys/class/dmi/id/chassis_asset_tag:FRANDRCPA552350019
/sys/class/dmi/id/chassis_type:10
/sys/class/dmi/id/chassis_vendor:Framework
/sys/class/dmi/id/chassis_version:A5
/sys/class/dmi/id/product_family:Laptop
/sys/class/dmi/id/product_name:Laptop 13 (AMD Ryzen 7040Series)
/sys/class/dmi/id/product_sku:FRANDRCP05
/sys/class/dmi/id/product_version:A5
/sys/class/dmi/id/sys_vendor:Framework

[linrunner]

Hi. modinfo does not prove that the module is loaded.

On the contrary

/sys/class/power_supply/BAT1/charge_control_start_threshold = (not available) /sys/class/power_supply/BAT1/charge_control_end_threshold = (not available) /sys/class/power_supply/BAT1/charge_behaviour = (not available)

shows that something must have gone wrong on the kernel or module side. Otherwise these sysfiles would be there. The cause of the problem does not lie within TLP.

Please show:

sudo modprobe -v cros_charge-control
ls -l /sys/bus/platform/devices/cros*
dmesg | grep cros

[BarbUk]

Hi,

Thanks for your response.

insmod /lib/modules/6.15.4-4-cachyos/kernel/drivers/power/supply/cros_charge-control.ko.zst 

lrwxrwxrwx 1 root root 0 Jul  4 11:52 /sys/bus/platform/devices/cros-ec-chardev.6.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-chardev.6.auto
lrwxrwxrwx 1 root root 0 Jul  4 11:52 /sys/bus/platform/devices/cros-ec-debugfs.7.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-debugfs.7.auto
lrwxrwxrwx 1 root root 0 Jul  4 11:52 /sys/bus/platform/devices/cros-ec-dev.2.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto
lrwxrwxrwx 1 root root 0 Jul  4 11:52 /sys/bus/platform/devices/cros-ec-gpio.3.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-gpio.3.auto
lrwxrwxrwx 1 root root 0 Jul  4 11:52 /sys/bus/platform/devices/cros-ec-hwmon.8.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-hwmon.8.auto
lrwxrwxrwx 1 root root 0 Jul  4 11:52 /sys/bus/platform/devices/cros-ec-led.4.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-led.4.auto
lrwxrwxrwx 1 root root 0 Jul  4 11:51 /sys/bus/platform/devices/cros_ec_lpcs.0 -> ../../../devices/platform/cros_ec_lpcs.0
lrwxrwxrwx 1 root root 0 Jul  4 11:52 /sys/bus/platform/devices/cros-ec-sysfs.9.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-sysfs.9.auto
lrwxrwxrwx 1 root root 0 Jul  4 11:52 /sys/bus/platform/devices/cros-keyboard-leds.5.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-keyboard-leds.5.auto

[   14.272109] cros_ec_lpcs cros_ec_lpcs.0: loaded with quirks 00000001
[   14.308257] cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered

I did try the same steps after disabling the "Battery Extender functionality" from bios 3.09, with the same results.

This issue seems to reference the same behavior: https://github.com/MrChromebox/firmware/issues/420#issuecomment-2395037192

I don't have any charge_control sysfs available:

$ grep . /sys/class/power_supply/BAT1/charge_*
/sys/class/power_supply/BAT1/charge_full:3976000
/sys/class/power_supply/BAT1/charge_full_design:3915000
/sys/class/power_supply/BAT1/charge_now:3379000

[linrunner]

The detection logic checks for /sys/bus/platform/devices/cros-charge-control.*.auto/driver which is missing on your system.

@t-8ch Do you have any idea what's going on here? You mentioned a broken firmware in mid March.

[BarbUk]

With ectool:

$ sudo ectool battery
Battery 0 info:
  OEM name:               NVT
  Model number:           FRANGWAT01
  Chemistry   :           LION
  Serial number:          036A
  Design capacity:        3915 mAh
  Last full charge:       3976 mAh
  Design output voltage   15480 mV
  Cycle count             4
  Present voltage         16676 mV
  Present current         -667 mA
  Remaining capacity      3286 mAh
  Desired voltage         17800 mV
  Desired current         3915 mA
  Flags                   0x06 BATT_PRESENT DISCHARGING

$ sudo ectool chargecontrol normal 75 85
Charge state machine is in normal mode with sustainer enabled.

Strace show that the tool talk with /dev/cros_ec:

12:17:33.673440 read(3</dev/cros_ec<char 10:121>>, "1.0.0\nazalea_v3.4.113385-ec:c25dec,os\nazalea_v3.4.113385-ec:c25dec,os\nread-only", 79) = 79 <0.001674>
12:17:33.675153 ioctl(3</dev/cros_ec<char 10:121>>, _IOC(_IOC_READ|_IOC_WRITE, 0x3a, 0, 0x28), 0x7ffec58bbf80) = -1 ENOTTY (Inappropriate ioctl for device) <0.000021>
12:17:33.675221 ioctl(3</dev/cros_ec<char 10:121>>, CROS_EC_DEV_IOCRDMEM, 0x7ffec58bbdd0) = 2 <0.000091>
12:17:33.675374 uname({sysname="Linux", nodename="framework", ...}) = 0 <0.000015>
12:17:33.675440 ioctl(3</dev/cros_ec<char 10:121>>, CROS_EC_DEV_IOCXCMD, 0x55fa439e34c0) = 12 <0.001175>
12:17:33.676670 ioctl(3</dev/cros_ec<char 10:121>>, CROS_EC_DEV_IOCXCMD, 0x55fa439e34f0) = 4 <0.001550>
12:17:33.678301 ioctl(3</dev/cros_ec<char 10:121>>, CROS_EC_DEV_IOCXCMD, 0x55fa439e34c0) = 0 <0.003441>
12:17:33.681833 fstat(1</dev/pts/3<char 136:3>>, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x3), ...}) = 0 <0.000018>
12:17:33.681945 write(1</dev/pts/3<char 136:3>>, "Charge state machine is in normal mode with sustainer enabled.\n", 63Charge state machine is in normal mode with sustainer enabled.

But:

$ sudo ectool chargecontrol
Charge mode = NORMAL (0)
Battery sustainer = off (-1% ~ -1%)

[t-8ch]

In any case you'll need to set cros_charge-control.probe_with_fwk_charge_control.

What is the output of ectool inventory? You probably need a patch to fix compatibility with bios 3.09.

[linrunner]

@t-8ch

In any case you'll need to set cros_charge-control.probe_with_fwk_charge_control.

You once wrote that this is only needed if framework_laptop is also loaded. How do you recognize this situation in the present case?

EDIT: charge_control_end_threshold should be there even with framework_laptop in charge.

[t-8ch]

You once wrote that this is only needed if framework_laptop is also loaded.

It is always necessary on a Framework machine. It is a promise by the user not to use the custom Framework API. Either through framework_laptop, ectool or the firmware setup. All of them are incompatible with what my driver does.

My hope is that Framework will unify all their features around the upstream API and drop their custom one.

[linrunner]

@t-8ch

It is always necessary on a Framework machine. It is a promise by the user not to use the custom Framework API.

Oops. I must have fundamentally misunderstood you :-(. Thanks for clarifying.

@self hurry to correct the docs ....

[linrunner]

Done: https://linrunner.de/tlp/settings/bc-vendors.html#chromebooks-and-framework

[BarbUk]

Thank you both for your responses.

What is the output of ectool inventory?

EC supported features:
1   : Flash support
2   : Direct Fan power management support
3   : Keyboard backlight support
5   : LED support
7   : Keyboard support
9   : BIOS Port 80h access support
10  : Thermal management support
13  : Host event support
14  : GPIO support
15  : I2C controller support
16  : Charger support
17  : Simple Battery support
18  : Smart Battery support
25  : Temporary secure vstore support
32  : Unified wake masks for LPC/eSPI support
33  : 64-bit host events support
34  : Execute code in RAM support

In any case you'll need to set cros_charge-control.probe_with_fwk_charge_control.

$ sudo modprobe -v cros_charge-control probe_with_fwk_charge_control=1
insmod /lib/modules/6.15.4-4-cachyos/kernel/drivers/power/supply/cros_charge-control.ko.zst probe_with_fwk_charge_control=1

$ ls -l /sys/bus/platform/devices/cros*
lrwxrwxrwx 1 root root 0 Jul  4 13:48 /sys/bus/platform/devices/cros-ec-chardev.6.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-chardev.6.auto
lrwxrwxrwx 1 root root 0 Jul  4 13:48 /sys/bus/platform/devices/cros-ec-debugfs.7.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-debugfs.7.auto
lrwxrwxrwx 1 root root 0 Jul  4 13:48 /sys/bus/platform/devices/cros-ec-dev.2.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto
lrwxrwxrwx 1 root root 0 Jul  4 13:48 /sys/bus/platform/devices/cros-ec-gpio.3.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-gpio.3.auto
lrwxrwxrwx 1 root root 0 Jul  4 13:48 /sys/bus/platform/devices/cros-ec-hwmon.8.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-hwmon.8.auto
lrwxrwxrwx 1 root root 0 Jul  4 13:48 /sys/bus/platform/devices/cros-ec-led.4.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-led.4.auto
lrwxrwxrwx 1 root root 0 Jul  4 13:45 /sys/bus/platform/devices/cros_ec_lpcs.0 -> ../../../devices/platform/cros_ec_lpcs.0
lrwxrwxrwx 1 root root 0 Jul  4 13:48 /sys/bus/platform/devices/cros-ec-sysfs.9.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-sysfs.9.auto
lrwxrwxrwx 1 root root 0 Jul  4 13:48 /sys/bus/platform/devices/cros-keyboard-leds.5.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-keyboard-leds.5.auto

ectool inventory give the same output

You probably need a patch to fix compatibility with bios 3.09.

I will try to build the kernel with this patch and report back.

[BarbUk]

You probably need a patch to fix compatibility with bios 3.09.

Patch applied against stable kernel 6.15.4. Build without issue.

After reboot:

sudo modprobe -v cros_charge-control probe_with_fwk_charge_control=1
insmod /lib/modules/6.15.4-2-cachyos/kernel/drivers/power/supply/cros_charge-control.ko.zst probe_with_fwk_charge_control=1

[   13.420248] cros_ec_lpcs cros_ec_lpcs.0: loaded with quirks 00000001
[   13.443380] cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered
[   13.491349] cros-charge-control cros-charge-control.6.auto: Framework charge control detected, preventing load

Now I have:

$ ls -l /sys/bus/platform/devices/cros*
lrwxrwxrwx 1 root root 0 Jul  4 14:48 /sys/bus/platform/devices/cros-charge-control.6.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-charge-control.6.auto
lrwxrwxrwx 1 root root 0 Jul  4 14:48 /sys/bus/platform/devices/cros-ec-chardev.7.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-chardev.7.auto
lrwxrwxrwx 1 root root 0 Jul  4 14:48 /sys/bus/platform/devices/cros-ec-debugfs.8.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-debugfs.8.auto
lrwxrwxrwx 1 root root 0 Jul  4 14:48 /sys/bus/platform/devices/cros-ec-dev.2.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto
lrwxrwxrwx 1 root root 0 Jul  4 14:48 /sys/bus/platform/devices/cros-ec-gpio.3.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-gpio.3.auto
lrwxrwxrwx 1 root root 0 Jul  4 14:48 /sys/bus/platform/devices/cros-ec-hwmon.9.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-hwmon.9.auto
lrwxrwxrwx 1 root root 0 Jul  4 14:48 /sys/bus/platform/devices/cros-ec-led.4.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-led.4.auto
lrwxrwxrwx 1 root root 0 Jul  4 14:48 /sys/bus/platform/devices/cros_ec_lpcs.0 -> ../../../devices/platform/cros_ec_lpcs.0
lrwxrwxrwx 1 root root 0 Jul  4 14:48 /sys/bus/platform/devices/cros-ec-sysfs.10.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-ec-sysfs.10.auto
lrwxrwxrwx 1 root root 0 Jul  4 14:48 /sys/bus/platform/devices/cros-keyboard-leds.5.auto -> ../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-keyboard-leds.5.auto

$ ls -l /sys/bus/platform/devices/cros-charge-control.*.auto/
-rw-r--r-- 1 root root 4096 Jul  4 14:51 driver_override
-r--r--r-- 1 root root 4096 Jul  4 14:51 modalias
drwxr-xr-x 2 root root    0 Jul  4 14:51 power
lrwxrwxrwx 1 root root    0 Jul  4 14:51 subsystem -> ../../../../../bus/platform
-rw-r--r-- 1 root root 4096 Jul  4 14:51 uevent

$ cat /sys/bus/platform/devices/cros-charge-control.*.auto/driver_override
(null)

[BarbUk]

Patch applied against stable kernel 6.15.4.

Should I test with mainline kernel ?

[t-8ch]

[   13.491349] cros-charge-control cros-charge-control.6.auto: Framework charge control detected, preventing load

Seems like your parameter is not set correctly. But it does look fine to me. Did you unload the module before loading it again with the parameters?

Should I test with mainline kernel ?

No, 6.15 is fine.

[BarbUk]

Did you unload the module before loading it again with the parameters?

No, it was after rebooting, so I was falsely thinking the module was not loaded.

$ sudo modprobe -v cros_charge-control probe_with_fwk_charge_control=1
insmod /lib/modules/6.15.4-2-cachyos/kernel/drivers/power/supply/cros_charge-control.ko.zst probe_with_fwk_charge_control=1

$ sudo dmesg | grep cros
[   14.562926] cros_ec_lpcs cros_ec_lpcs.0: loaded with quirks 00000001
[   14.588843] cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered
[   14.639677] cros-charge-control cros-charge-control.6.auto: Framework charge control detected, preventing load
[  250.295416] cros-ec-dev cros-ec-dev.2.auto: Some logs may have been dropped...
[  783.871116] ACPI: battery: new hook: cros-charge-control.6.auto

$ ls -l /sys/bus/platform/devices/cros-charge-control.*.auto/
total 0
lrwxrwxrwx 1 root root    0 Jul  4 15:01 driver -> ../../../../../bus/platform/drivers/cros-charge-control
-rw-r--r-- 1 root root 4096 Jul  4 14:51 driver_override
-r--r--r-- 1 root root 4096 Jul  4 14:51 modalias
drwxr-xr-x 2 root root    0 Jul  4 14:51 power
lrwxrwxrwx 1 root root    0 Jul  4 14:51 subsystem -> ../../../../../bus/platform
-rw-r--r-- 1 root root 4096 Jul  4 14:51 uevent

$ ls -l /sys/bus/platform/devices/cros-charge-control.*.auto/driver/
total 0
--w------- 1 root root 4096 Jul  4 15:01 bind
lrwxrwxrwx 1 root root    0 Jul  4 15:01 cros-charge-control.6.auto -> ../../../../devices/platform/cros_ec_lpcs.0/cros-ec-dev.2.auto/cros-charge-control.6.auto
lrwxrwxrwx 1 root root    0 Jul  4 15:01 module -> ../../../../module/cros_charge_control
--w------- 1 root root 4096 Jul  4 15:01 uevent
--w------- 1 root root 4096 Jul  4 15:01 unbind

And now battery care is loading the cros-ec plugin:

$ sudo tlp-stat -b 
--- TLP 1.8.0 --------------------------------------------

+++ Battery Care
Plugin: cros-ec
Supported features: charge thresholds, recalibration
Driver usage:
* natacpi (cros_charge-control) = active (charge thresholds, recalibration) - EC cmd v3
Parameter value ranges:
* START_CHARGE_THRESH_BAT0/1:  0(off)..99
* STOP_CHARGE_THRESH_BAT0/1:   1..100(default)

+++ Battery Status: BAT1
/sys/class/power_supply/BAT1/manufacturer                   = NVT
/sys/class/power_supply/BAT1/model_name                     = FRANGWA
/sys/class/power_supply/BAT1/cycle_count                    =      4
/sys/class/power_supply/BAT1/charge_full_design             =   3915 [mAh]
/sys/class/power_supply/BAT1/charge_full                    =   3976 [mAh]
/sys/class/power_supply/BAT1/charge_now                     =   3031 [mAh]
/sys/class/power_supply/BAT1/current_now                    =   -560 [mA]
/sys/class/power_supply/BAT1/status                         = Discharging

/sys/class/power_supply/BAT1/charge_control_start_threshold =      0 [%]
/sys/class/power_supply/BAT1/charge_control_end_threshold   =    100 [%]
/sys/class/power_supply/BAT1/charge_behaviour               = [auto] inhibit-charge force-discharge

Charge                                                      =   76.2 [%]
Capacity                                                    =  101.6 [%]

[linrunner]

Great.

[BarbUk]

Last question for @t-8ch before closing this issue.

I see that your proposed fix was pulled in for-mfd-next from Lee Jones tree.

Is it safe to think this will target a kernel 6.17 merge ?

[t-8ch]

Is it safe to think this will target a kernel 6.17 merge ?

If nothing unexpected happens it will make it into 6.17

[BarbUk]

Thank you :)

[LinuxOnTheDesktop]

    Hello. I too have a AMD Framework 13 (and, again, of the Ryzen 7040 series). On that machine, with tlp 1.8.0, tlp-stat reports that no supported features are available. Is that because I have the latest (sic) BIOS for the machine, viz., 3.09? But, ah: is one to take it from the above that version 6.17 of the Linux kernel will make the tlp battery threshold stuff work? The documentation (this being the relevant part) does not mention that. Indeed the documentation tells one that one needs a module loaded, imparts further (if one digs a bit) that the kernel should load the module, and/but does not disclose how one can check whether the module is loaded.

    TL;DR: Seemingly tlp's documentation is wrong to claim that tlp can handle battery thresholds on (some?) Framework laptops. For, seemingly, that feature will exist only in the future, with an as-yet unreleased Linux kernel. Or perhaps that is the case only if one has the latest BIOS.

[t-8ch]

The currently newest firmware versions will require Linux 6.17. Older firmwares do work with older kernels. The documented module parameter is always necessary, until Framework remove the incompatibility.

[BarbUk]

I have updated the title of the issue to make that requirement more visible.

[linrunner]

@t-8ch

The currently newest firmware versions will require Linux 6.17.

Does this apply only to the Framework 13 or to all Framework models?

[t-8ch]

@linrunner

Does this apply only to the Framework 13 or to all Framework models?

Should be all of them. The specific version number differs by model. More abstractly, firmware without 22 : USB Cros Power Delivery support in ectool inventory needs the patch.

[LinuxOnTheDesktop]

I have updated the title of the issue to make that requirement more visible.

That is helpful. Thank you, @BarbUK. But it seems to me that really the documentation needs updating.

[linrunner]

Docs have been updated and issue reopened (temporarily) for better visibility.

[BarbUk]

Docs have been updated and issue reopened (temporarily) for better visibility.

Thanks.

I'll add that Thomas patch was successfully merged in the 6.17-rc1 window, and Linus included it in his changelog under Lee Jones:

Lee Jones (2):
    MFD updates
    LED updates

So using 6.17-rc release will now include the patch.

For those who want to wait for the 6.17 stable release, it's expected late September.

[linrunner]

@BarbUk Thanks for the info. I'll keep the wording "A driver fix is expected for Linux 6.17." until the release.

[linrunner]

Has anyone tried 6.17 to see if it works again?

[LevitatingBusinessMan]

I personally haven't had any issues on 6.17 next for the past month.

[BarbUk]

Has anyone tried 6.17 to see if it works again?

Yes, it's working correctly:

❯ uname -a
Linux framework 6.17.1-2-cachyos #1 SMP PREEMPT_DYNAMIC Mon, 06 Oct 2025 15:17:14 +0000 x86_64 GNU/Linux

❯ sudo tlp-stat -b
--- TLP 1.8.0 --------------------------------------------

+++ Battery Care
Plugin: cros-ec
Supported features: charge thresholds, recalibration
Driver usage:
* natacpi (cros_charge-control) = active (charge thresholds, recalibration) - EC cmd v3
Parameter value ranges:
* START_CHARGE_THRESH_BAT0/1:  0(off)..99
* STOP_CHARGE_THRESH_BAT0/1:   1..100(default)

+++ Battery Status: BAT1
/sys/class/power_supply/BAT1/manufacturer                   = NVT
/sys/class/power_supply/BAT1/model_name                     = FRANGWA
/sys/class/power_supply/BAT1/cycle_count                    =     14
/sys/class/power_supply/BAT1/charge_full_design             =   3915 [mAh]
/sys/class/power_supply/BAT1/charge_full                    =   3991 [mAh]
/sys/class/power_supply/BAT1/charge_now                     =   2034 [mAh]
/sys/class/power_supply/BAT1/current_now                    =    640 [mA]
/sys/class/power_supply/BAT1/status                         = Discharging

/sys/class/power_supply/BAT1/charge_control_start_threshold =     75 [%]
/sys/class/power_supply/BAT1/charge_control_end_threshold   =     80 [%]
/sys/class/power_supply/BAT1/charge_behaviour               = [auto] inhibit-charge force-discharge

Charge                                                      =   51.0 [%]
Capacity                                                    =  101.9 [%]