saidsay-so/acpi_ec

Seem to fail to install on Arch with Linux-Kernel 6.4.12-arch1-1

Closed this issue · 5 comments

running install.sh gives me the following logs, although i am not quite sure what to make of them (i fully uninstalled the module beforehand)

neko@Arch ~/acpi_ec (master)> sudo ./install.sh
WARNING: Secure Boot is not enabled!
Creating symlink /var/lib/dkms/acpi_ec/v1.0.2/source -> /usr/src/acpi_ec-v1.0.2
Sign command: /usr/lib/modules/6.4.12-arch1-1/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j12 KERNELRELEASE=6.4.12-arch1-1 -C /usr/lib/modules/6.4.12-arch1-1/build M=/var/lib/dkms/acpi_ec/v1.0.2/build/src modules...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.4.12-arch1-1 (x86_64)
Consult /var/lib/dkms/acpi_ec/v1.0.2/build/make.log for more information.


neko@Arch ~/acpi_ec (master) [10]> cat /var/lib/dkms/acpi_ec/v1.0.2/build/make.log
DKMS make.log for acpi_ec-v1.0.2 for kernel 6.4.12-arch1-1 (x86_64)
Fr 1. Sep 18:29:26 CEST 2023
  CC [M]  /var/lib/dkms/acpi_ec/v1.0.2/build/src/acpi_ec.o
In file included from ./include/linux/linkage.h:7,
                 from ./include/linux/preempt.h:10,
                 from ./include/linux/spinlock.h:56,
                 from ./include/linux/mmzone.h:8,
                 from ./include/linux/gfp.h:7,
                 from ./include/linux/slab.h:15,
                 from ./include/linux/resource_ext.h:11,
                 from ./include/linux/acpi.h:13,
                 from /var/lib/dkms/acpi_ec/v1.0.2/build/src/acpi_ec.c:13:
/var/lib/dkms/acpi_ec/v1.0.2/build/src/acpi_ec.c: In function ‘acpi_ec_create_dev’:
./include/linux/export.h:27:22: error: passing argument 1 of ‘class_create’ from incompatible pointer type [-Werror=incompatible-pointer-types]
   27 | #define THIS_MODULE (&__this_module)
      |                     ~^~~~~~~~~~~~~~~
      |                      |
      |                      struct module *
/var/lib/dkms/acpi_ec/v1.0.2/build/src/acpi_ec.c:115:39: note: in expansion of macro ‘THIS_MODULE’
  115 |   if (IS_ERR(dev_class = class_create(THIS_MODULE, "chardev"))) {
      |                                       ^~~~~~~~~~~
In file included from ./include/linux/device.h:31,
                 from ./include/linux/acpi.h:14:
./include/linux/device/class.h:230:54: note: expected ‘const char *’ but argument is of type ‘struct module *’
  230 | struct class * __must_check class_create(const char *name);
      |                                          ~~~~~~~~~~~~^~~~
/var/lib/dkms/acpi_ec/v1.0.2/build/src/acpi_ec.c:115:26: error: too many arguments to function ‘class_create’
  115 |   if (IS_ERR(dev_class = class_create(THIS_MODULE, "chardev"))) {
      |                          ^~~~~~~~~~~~
./include/linux/device/class.h:230:29: note: declared here
  230 | struct class * __must_check class_create(const char *name);
      |                             ^~~~~~~~~~~~
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:252: /var/lib/dkms/acpi_ec/v1.0.2/build/src/acpi_ec.o] Error 1
make: *** [Makefile:2032: /var/lib/dkms/acpi_ec/v1.0.2/build/src] Error 2

Since its throwing Secure Boot at me, do i need to enable that? What about the other errors mentioned in the logs?

Also, come to think of it. shouldnt it attempt to build the module first and only then afterwards, upon completion, create a symlink? Because as it is right now i have a Symlink in my DKMS-Tree to something that seems to be a nonworking module. And at least in my little monkeybrain, that doesnt make much sense.

I stumbled upon the same error on Ubuntu 23.10, since the kernel was upgraded from 6.2.0 (Ubuntu 23.04) to 6.5.0. Good to know that it's an issue with 6.4.12 too.

It looks like the kernel changed the API without backward compatibility (regarding the class_create function, that now expects only 1 argument instead of 2). Seems like removing THIS_MODULE from the call should resolve the issue. I'm gonna test this and create a PR.

UPDATE: According to the code, it looks like the API change was already expected from 6.4.0.

Seems to be a duplicate of #9.

Fixed in #10, just not released yet.

I just tested that it works, the issue can be closed now.

Sorry, I will create a release which includes the fix.

Seems to be a duplicate of #9.

Fixed in #10, just not released yet.

I just tested that it works, the issue can be closed now.

the new version released last week seems to build without issues. i will try and see if now i can access /dev/ec again