Controlling heat while charging in embedded applications. (mainboard stacked on top of the battery with a small heatshield in between. Trying to keep temps under 55C for battery longevity, decrease the liklihood of swelling, etc.
I’m sorry but I’m not used to reading linux mailing lists, how can I know the status of the patches merging into the kernel? Really interested in all those patches 
Basic sensors: v6.11
More sensors: unknown as of now
Keyboard backlight: likely v6.11
LEDs: v6.11
Charge control: Could make v6.11, unsure
5 Likes
Since the 6.11 merge window has closed, can we get an update on the status of these?
I am also interested in being notified of future revisions, should there be any.
Thanks!
All of them except “More sensors” have been merged for 6.11.
3 Likes
Nice. Is “more sensors” scheduled for a later release?
I’ll need to spend some more time on it.
Hi, wanted to have a spin of the charge control one and just rebooted on a fresh 6.11-rc4. No charge_control_end_threshold sysfs node (had to look up what the expected sysfs entry was, maybe documenting them here would help testers). I’m getting the following in dmesg
[ 34.038944] cros_ec_lpcs cros_ec_lpcs.0: loaded with quirks 00000001
[ 34.048343] cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered
[ 34.062606] cros-charge-control cros-charge-control.4.auto: Framework charge control detected, preventing load
[ 34.064840] cros-usbpd-charger cros-usbpd-charger.5.auto: No USB PD charging ports found
[ 34.071454] cros-usbpd-charger cros-usbpd-charger.5.auto: Unexpected number of charge port count
[ 34.071504] cros-usbpd-charger cros-usbpd-charger.5.auto: Failing probe (err:0xffffffb9)
[ 34.071506] cros-usbpd-charger cros-usbpd-charger.5.auto: probe with driver cros-usbpd-charger failed with error -71
That’s on an AMD BIOS 3.05. Any other info you’d like?
EDIT: Thought it’d be related to my blacklisting of ucsi_acpi, but removing it doesn’t change anything.
For what it’s worth, I’m getting the same
cros-usbpd-charger cros-usbpd-charger.5.auto error with just plain current 6.10.4, on NixOS (on FW13 AMD 7840u).
The error wasn’t there on 6.9.x, so I assume it’s caused by the EC patches merged into 6.10. I couldn’t find a way to fix it so far.
Not really an issue…if I’m understanding the ‘warning’ correctly:
https://lore.kernel.org/lkml/20240406191734.137797-1-superm1@gmail.com/t/
…but appears to be EC incorrectly reporting a feature?
That’s a great find, @Second_Coming, thanks for posting the reference! My searches did not come across it.
Yes, it looks like the EC reports that feature - 22, if I am not mistaken - as supported, currently:
❯ sudo 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
22 : USB Cros Power Delivery 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
You need to load the module with the parameter probe_with_fwk_charge_control=1.
And do not
- Use the charge control settings in the firmware setup
- mess with charge control settings via
ectool - use the charge control logic from
framework-laptop-kmod
Just modprobed it right back in with this parameter and the sysfs nodes appear.
If I’m reading the source correctly, you can use the firmware setup (or any other charge control interface for that matter), just that in this case the changes using those other tools will not be propagated to the sysfs nodes, right?
Also, the EC seems to get configured with the module’s hardcoded defaults of 0-100 on init, hence using it with the FW setup should be fine as long as you then issue the same charging limits?
No, there are in fact two separate implementations of charge management in the Framework EC.
The upstream one and their custom one. If the custom one is active it breaks the upstream one.
The mainline driver uses the upstream API, everything else uses the Framework API.
If you want to keep them always the same as the firmware setup,
what is the point of using the module?
(And I’m not sure it would even work)
1 Like
Ah, that’s very good to know and explains what I was observing, thanks!
Given the above it would most likely not work, yes. My use case is to have a 60% threshold almost all of the time, but when I know I’ll be traveling I temporarily raise that to 100%, and I want that to also work on Windows. Would the EC retain the thresholds set by the upstream API when powered off, until they’re set again, this way I don’t have to worry about the battery charging up for no reason when powered off? (also can you confirm that to disable the firmware charge control setting it to 100% in the setup is enough?)
EDIT: I probably should have tried myself first setting fw charge control to 100 in the setup is in fact enough, and using this sysfs node the threshold settings are kept across reboots… up until cros_charge_control is loaded again and resets everything to default. It would be nice to have this be preserved across reboots if possible! Works like a charm otherwise.
Notable PRs for charge limit UI in GNOME and the corresponding UPower enhancement. With any luck, this’ll land in GNOME 47 (2024-09-17).
4 Likes
Do we have something similar for Plasma?
I’ve tried this option with the stable kernel 6.11 on Fedora 40 on a Framework 13 12th gen (Bios 3.08).
lsmod tells me that the driver is correctly loaded and I’ve set the respective framework parameter to 1, resulting in
cat /sys/module/cros_charge_control/parameters/probe_with_fwk_charge_control
Y
A new option in the battery system popped up, that was not there before:
cat /sys/class/power_supply/BAT1/charge_behaviour
[auto] inhibit-charge force-discharge
Unfortunately, no charge limit files (start and end limits) are present for the battery, and also TLP reports these as unavailable:
/sys/class/power_supply/BAT1/charge_control_start_threshold = (not available)
/sys/class/power_supply/BAT1/charge_control_end_threshold = (not available)
I’ve set the bios limit to 100 (and even loaded the default settings). I never installed ec_tool and the framework kmod, that I’ve used once, is not loaded nor installed.
What am I doing wrong? Or is this a bug?
EDIT: I’ve compiled the most recent version of the framework kmod and loaded it. This driver gives me a charge_control_end_threshold file (that reports 100 when read).
For the kernel-included driver: I’m happy to help with debug messages or system information, if anyone helps in telling me how to gather these…
You are on an older Intel model?
Then it seems these ECs are not compatible with the full functionality.
(There are different versions of the command)
The framework kmod used a different interface.
I’m on a 12th Gen Model (Intel Alder Lake) with the latest bios and firmware versions installed - I’ve checked this twice 