Linux EC Driver Framework, why haven't you trumpeted this yourself?

General Topics
1

So came across this news on Phoronix.

A little surprised it’s not on your blog or posted here on the forums somewhere. Very cool news :slight_smile:

3 Likes
2

trumpted? What’s that?

1 Like
3

Generally means to loudly sing your own praises, or announce whatever, make a big deal out of something for people to know about.

In this case maybe it isn’t necessary to make a big deal out of it, but it’d be nice to see Framework put this information up that they’re doing it, so we can look forward to it making it’s way through the process and start using it once available through the kernels & distros.

2 Likes
4

Oh, you mean “trumpeted”.

3 Likes
5

Erp. My mis-spelling, didn’t catch it, thanks.

Fixed.

1 Like
6

Regarding the article, there isn’t much info there. I have used the EC settings to change my battery threshold in Linux, but unfortunately it just gets reset to the bios setting on sleep I think. It should stay as set. As it is, you still need to reboot into the bios to set it to a different default setting.

7

There are two competing efforts towards making a driver specific to the framework laptop.

One of them is often discussed on this forum.

The other one is the subject of an article that is less than ten hours old and is a patch series that is neither authored by a Framework employee nor more than three days old. What would they have known to trumpet on such short notice? :slightly_smiling_face:

I may have a biased opinion, as my driver is not the one that this Phoronix article is about.

7 Likes
8

Currently, that’s what the kernel driver in the article is about, making it accessible to view/set those in the EC without having to reboot into the BIOS.

I don’t think I’ve come across that other driver in the forums. Only just got my FW 16 middle of last week.

9

I hope you and Thomas can collaborate :slight_smile:

3 Likes
10

The setting saves for you? As I said, using the driver to set from the OS does not survive sleep or reboots for me.

11

I presume so, that’s my reading of it. Or at the least, it’s exposed via the sysdef, which means standard system tools/systemd can ensure, on boot, that that value is set to whatever it should be.

I presume it saves the value in the EC, which would mean even off, but plugged in, it’d honor that value.

That’s a good question, @Mario_Limonciello, what’s the behavior when a value is set? Does it store it, and use it even when otherwise off bug plugged in, or does it only honor that when the OS is up and running and has set that value?

12

EC changes should be made immediately, no need to reboot.

13

I found out about this on Mastodon and Twitter / X way before I saw this thread.

1 Like
14

And it’ll save in the EC and honor it even when the OS is off, and plugged in?

That’s good.

15

I don’t know about storage - only that it would take effect immediately.

@DHowett am I right?

16

Charge limit changes will take effect immediately and be remembered until the next time you boot, at which point the charge limit set in the UEFI Setup form will take over. If you set it and power the machine down, it will use your most recently set value until the next boot. :slightly_smiling_face:

2 Likes
17

Ah, interesting. So the UEFI BIOS talks to EC and resets the value each time it powers up, which the OS can then perform the set.

That seems odd, that this won’t also push it up to the BIOS. I suppose there’s no easy way to do that? Seems like that’d kinda be the preferred option, to have these sorts of settings be pushed up to the BIOS. But at least it’s sticky when set and then powered off, that’s something.

18

Okay so a consequence of that behavior is that if you program it using something like systemd at boot then it doesn’t matter what the BIOS does.

19

Sorta, except if you boot to the bios, update/change a setting, and power off, leave it plugged in then it’s going to be staying at the bios setting, rather than what you have it in the OS.

That’s probably a pretty rare possibility, and maybe it’s just weird me, but I’m always a fan of making sure it’s updated at the location that’s the “primary”, which in this case I’d say is the BIOS.

20

I think in order to get what you’re aiming for would require Framework to export an interface to change BIOS settings from the OS. The kernel does offer an API that they can fit into for it:

Basically they need an interface in their BIOS for this. Most vendors have wrapped it with ACPI-WMI, but that’s not a requirement. Then you’ll need a kernel driver that uses the BIOS API and the class-firmware-attributes API. When that’s all done you can potentially do stuff like fwupdmgr set-bios-setting foo bar.

It’s not a light lift at all.

1 Like