Using 6.8 and 6.9 os-build tree's from kernel-ark (fedora rawhide) with the cros_ec quirks patch applied in kernel.

Adding the framework-kmod kernel (via manual build/akmod) ( commit : a9e8db9 ) results in framework 13 returning from suspend in an unstable state:

On resume:

• Takes a long time to present screen
• Power Indicator LED still breathes/flashes even when lid open/power on
• Waylabd Plasma greeter appears after >15 Seconds
• Keypress input is erratic ; keystrokes not registering and or doubled/trippled into password input box
• System becomes unusable until reboot

Journal log of boot attached:

journallog.txt

Heya! So I am really excited about this work! Just got my 16 and am trying to get this installed. But I am running Universal Blue ( https://ublue.it ) using Blue Build right now ( https://blue-build.org/ ) and I've been banging my head against the wall for a few hours so far attempting to install the module during the image build process and have gotten nowhere. I did open an issue on Ublue's repo because they have a streamlined way to add kmods ( ublue-os/akmods#137 ), but figure I'd attack this problem from multiple angles and ask here as well? During the build process it appears that the current directory for the building of modules doesn't exist? /usr/src/kernels/6.7.6-200.fc39.x86_64 which from where I am sitting, is required by your make script. I'll happily assist in any way I can in this and would happily make a PR back even if its documentation if we can figure it out!

Thanks,
Matt

P.S. If you wanna chat in the Framework discord, I'm Waffleophagus there as well.

So I installed the module via the yay method and after that loaded it with modprobe.

I made sure that cros_ec and cros_ec_lpcs were loaded

Then after ensuring that the module was loaded via lsmod, I listed the exposed stuff under /sys/class/power_supply/BAT1 but I couldn't find the charge_control_end_threshold which was the main reason I wanted this kmod

Did I do something wrong?

On my Framework 13 Ryzen 7840, when trying to load cros with a 6.8.5 kernel drivers with the v2 patcheset, I get this in my dmesg:

$ dmesg | grep cros
[    2.365684] cros_ec_lpcs cros_ec_lpcs.0: loaded with quirks 00000002
[    2.366295] cros_ec_lpcs cros_ec_lpcs.0: couldn't reserve region1
[    2.366848] cros_ec_lpcs: probe of cros_ec_lpcs.0 failed with error -16
[    4.031967] framework_laptop framework_laptop: framework_laptop: failed to find EC cros-ec-dev.

Going back to the v1 patchest makes things work again.

[    3.976497] cros_ec_lpcs cros_ec_lpcs.0: loaded with quirks 00000003
[    3.986984] cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered

As the title says, is it possible (if not done already) to commit this into the upstream Linux kernel?
I don't know the rules for submitting this kind of driver.

System Information

• Bios-version: 03.06
• Bios-release-date: 11/10/2022
• OS: Fedora Linux 39 (Workstation Edition) x86_64
• CPU: 12th Gen Intel i5-1240P (16) @ 4.400GHz
• Kernel: 6.6.7-200.fc39.x86_64
• DE: GNOME 45.2

Issue

• Readme tell us that:

This module requires cros_ec and cros_ec_lpcs to be loaded and functional.

I am facing the issue with Fn key getting stuck, and was advised to disable cros_ec_lpcs as per here.

Question

I wanted to ask if using this kernel module it also fixes the Fn issue? I got to this repository through this link

Kernel: 5.15.0-89-generic
Framework 13 11th Gen (i5-1135G7)

The README and modprobe --show-depends framework_laptop show that this module depends on cros_ec and cros_ec_lpcs, however on my system cros_ec_lpcs is not loaded, and trying to load it with insmod gives an error: cros_ec_lpcs.ko: No such device.

Am i missing the requisite hardware for this module to work? it sorta sounded like all intel FW 13" laptops had the MEC chip mentioned here

$ uname -a
Linux Destructor 6.6.38-gentoo #4 SMP Fri Jul 12 04:38:25 EDT 2024 x86_64 AMD Ryzen 9 7940HS w/ Radeon 780M Graphics AuthenticAMD GNU/Linux

$ zgrep '^[^#].*_CROS_EC' /proc/config.gz 
CONFIG_MFD_CROS_EC_DEV=y
CONFIG_CROS_EC=y
CONFIG_CROS_EC_LPC=y
CONFIG_CROS_EC_PROTO=y

$ dmesg | grep -F -e cros_ec -e framework
[    2.129146] framework_laptop framework_laptop: framework_laptop: failed to find EC cros-ec-dev.
[    2.129377] framework_laptop: probe of framework_laptop failed with error -22
[    2.130883] cros_ec_lpcs cros_ec_lpcs.0: loaded with quirks 00000001
[    2.223334] cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered

Is it okay for framework_laptop to be loading before cros_ec_lpcs? (My kernel doesn't support loadable modules, so I integrated your framework_laptop.c into my kernel tree in drivers/platform/x86/.)

Maybe there is a missing dependency specification somehow, or maybe I need to enable another piece of CrOS support that you didn't mention in your README? (I initially didn't have MFD_CROS_EC_DEV enabled, but I tried enabling it to see if it would solve my issue. It didn't.)

Hi,

I was just wondering if there was a plan to expose fan speed potentially in hwmon?

I might have a go implementing it myself next week if it isn't too hard, but I've only ever made small one line changes to older broken kernel modules before, so this might be way out of my skill set.

Edit: It's at least not automatically exposed by ACPI on my AMD Framework, idk about the Intel models.

Thanks,
Steve

LTS versions of many linux distributions seem to mostly still be running kernel versions 5.X. Based on my testing of kernel versions 5.15.0-89, and 5.13.0-40 it seems like there is an issue with building on kernels older than 6.0

The error i got when building on the above kernels (snippet from make output):

framework_laptop.c:252:24: error: initialization of ‘int (*)(struct power_supply *)’ from incompatible pointer type ‘int (*)(struct power_supply *, struct acpi_battery_hook *)’ [-Werror=incompatible-pointer-types]
  252 |         .add_battery = framework_laptop_battery_add,
      |                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

Theres a very similar error for framework_laptop_battery_remove as well

after running sudo apt install linux-headers-6.2.0-37-generic, i was able to compile (using make KDIR=/lib/modules/6.2.0-37-generic/build) this module no problem.

Is this an issue that is able to be fixed relatively easily for 5.X kernels more easily than me dealing with trying to distrohop to something that has a 6.x kernel?

Keyboard LED

The Framework 16 uses an input modules system, and the stock keyboards run QMK, with the VIA HID protocol enabled. This means the brightness can be controlled using eg qmk_hid. Currently, framework-laptop-kmod will expose a keyboard backlight LED in the kernel that is fully nonfunctional on framework 16 (because the EC doesn't control it). I think that either the node should not be created at all when the hardware is detected to be framework 16, or the implementation should attempt to use the HID protocol for controlling the brightness. Some issues with this are

1. The keyboard module is not guaranteed to be running the stock firmware. Custom firmware could mean the HID interface is not available
2. If the kernel binds the HID interface, it might interfere with userspace. The interface is primarily designed to be used with the VIA web configuration tool, and I'm not sure there's precedent for pulling that into kernel space. My personal opinion is that it would be good though

Power/fingerprint button LED

Framework 16 also allows control of the power button LED via the EC. this is exposed in framework_tool --fp-brightness. Adding an LED node for this when it is present would be nice to have.