Unsupported userspace charge control

[tlvince]

Device Information

System Model or SKU

Please select one of the following

• Framework Laptop 13 (11th Gen Intel® Core™)
• Framework Laptop 13 (12th Gen Intel® Core™)
• Framework Laptop 13 (13th Gen Intel® Core™)
• Framework Laptop 13 (AMD Ryzen™ 7040 Series)
• Framework Laptop 13 (Intel® Core™ Ultra Series 1)
• Framework Laptop 13 (AMD Ryzen™ AI 300 Series)
• Framework Laptop 16 (AMD Ryzen™ 7040 Series)

BIOS VERSION

3.03

DIY Edition information

• Memory: Crucial CT2K16G56C46S5 32GB DDR5-5600 SODIMM
• Storage: SK hynix Platinum P41 1TB SSD

Port/Peripheral information

1. USB-C expansion card: Framework 60W charger
2. USB-C expansion card (no peripheral)
3. USB-C expansion card (no peripheral)
4. USB-C expansion card (no peripheral)

Standalone Operation

• Yes
• No

Describe the bug

Loading cros_charge-control with probe_with_fwk_charge_control=1 should provide /sys/class/power_supply/BAT1/charge_control_{start,end}_threshold for userspace charge control e.g. GNOME 48's Preserve Battery Health feature.

This doesn't work on the AI 300 series (BIOS 3.03). On the 7040's, BIOS 3.09 caused a regression.

Operating System (please complete the following information):

• OS/Distribution: NixOS
• Version: 25
• Linux Kernel Version: 6.14.6

[Serafean]

Hi, I've been going through this issue here.

The TLDR version is you need this kernel patch and probe_with_fwk_charge_control=1.

So should be fixed in kernel 6.15.

[JohnAZoidberg]

Hi, I've been going through this issue here.

The TLDR version is you need this kernel patch and probe_with_fwk_charge_control=1.

So should be fixed in kernel 6.15.

Oh thanks, I haven't seen that.
But 6.15 was already released without this patch.

[Serafean]

Oh thanks, I haven't seen that. But 6.15 was already released without this patch.

My bad, made the assumption that it had landed...
Good to know.

[tlvince]

The TLDR version is you need this kernel patch and probe_with_fwk_charge_control=1.

Thanks. Applied on top of v6.14.7. Works for me:

❯ upower -i /org/freedesktop/UPower/devices/battery_BAT1
    ...
    charge-start-threshold:        75%
    charge-end-threshold:          80%
    charge-threshold-enabled:          1
    charge-threshold-supported:          1

Although the start threshold seems to be ignored - it hovers around 80% /cc @t-8ch.

[Serafean]

@tlvince since you're also using charge control, could you please confirm a separate issue?
When I set the start and end thresholds to the same number, it never starts charging. The discharge rate slows down to a minimum when it hits that percentage, but level still falls.

[JohnAZoidberg]

When I set the start and end thresholds to the same number, it never starts charging. The discharge rate slows down to a minimum when it hits that percentage, but level still falls.

What do you expect to happen? What's the purpose of setting them to the same number?

Although the start threshold seems to be ignored

Yes, it's not implemented in the EC

[Serafean]

What do you expect to happen? What's the purpose of setting them to the same number?

My expectation is for the charge level to stay at that percentage while on AC.

right now I have start 79%, end 80%.

[Serafean]

Also the KDE UI sort of leads to setting them to the same number.

https://github.com/user-attachments/assets/0e87663a-878d-407c-805c-edf7da307e81
Manually set max to 83, min to 82, then used scroll wheel in "stop charging at" . Note how they're tied.

[JohnAZoidberg]

What do you expect to happen? What's the purpose of setting them to the same number?

My expectation is for the charge level to stay at that percentage while on AC.

right now I have start 79%, end 80%.

But it's enough to set the maximum, no? Then the system charges until that number, stops and stays there

[Serafean]

The reason I reported this it is that I just scrolled the max down to 80% in the KDE UI (which set the min to 80%, hadn't even thought about setting that), applied.
Then in the morning found the AC connected laptop discharged to about 60% - under both thresholds. Found the behaviour to be very surprising, so reporting it.
This may be because powerdevil sets both numbers, while the EC expectation is that only one will be set?

[tlvince]

Yes, it's not implemented in the EC

Please consider implementing this 😄

When I set the start and end thresholds to the same number, it never starts charging

Setting both to the same value doesn't make sense, IMO. Sounds like a validation bug. Although not charging at all sounds like its triggering another bug.

Either way, I think we can close this issue.

[JohnAZoidberg]

Please consider implementing this 😄

Yes, we're planning to retire our own host commands eventually and use the battery limit/saver commands of chromium ec.

Either way, I think we can close this issue.

Great, thanks, good that it's wroking now.