PCIe driver: build DKMS modules for the target kernel, not the running one

dkms.conf quoted the make binary: MAKE="'make' -C src/ all". dkms passes the
kernel it is building for by rewriting the leading "make" of that string into
"make -jN KERNELRELEASE=$kernelver" (dkms 3.2.1, line 1446) - an anchored
prefix substitution that the quotes defeat, so nothing was ever injected. The
Makefile then hardcoded /lib/modules/$(shell uname -r)/build and would have
ignored it in any case.

With AUTOINSTALL=yes the module was therefore always compiled against the
running kernel and installed into the tree of whichever kernel dkms was
building for. A dnf update that pulls in a new kernel builds against the old
one and drops the result in the new kernel's /extra, where it fails to load on
the next boot. Crossing RHEL 9.4 to 9.5 it would also compile the wrong side of
the vm_flags guard, which is how this was noticed.

The Makefile now takes KDIR, defaulting to the running kernel exactly as
before, and dkms.conf passes ${kernel_source_dir} - which dkms resolves for the
target kernel before sourcing the conf, and which honours --kernelsourcedir.
Dropping the quotes also lets dkms's -jN through, so the recursive invocations
become $(MAKE) to keep the jobserver.

Verified by building against a kernel other than the running one: the module
now comes out carrying the target kernel's vermagic.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PLMZgfMEdtPBZt1F2rNbRA

docs/CHANGELOG.md

@@ -3,6 +3,7 @@
 ### 1.0.0-rc.164
 This is an UNSTABLE release. It includes many experimental features, as well as many AI generated fixes. We recommend using rc.152 for production use.
 
+* The PCIe driver DKMS package builds for the kernel it is being installed for instead of the running one, so a module built while a kernel update is being applied loads after the reboot.
 * The PCIe driver builds on RHEL 9.5 and later, and on their CentOS Stream, Rocky and AlmaLinux equivalents, where the `vm_flags` kernel interface was backported into the 5.14 kernel.
 * rugnux: `--export-unmerged` writes the integrated observations as `<prefix>_unmerged.mtz`, an unmerged MTZ readable by aimless, pointless, careless and `iotbx.merging_statistics`, in `--mode mx` and `--mode scale` alike; each rotation reflection's partials are summed into one full, and `--export-unmerged-partials` writes one row per image instead. Lattice-centring absences are not written; screw and glide absences are.
 

fpga/pcie_driver/Makefile

@@ -7,11 +7,16 @@ cflags-m=-std=c99
 
 jfjoch-y := jfjoch_drv.o jfjoch_ioctl.o jfjoch_memory.o jfjoch_pcie_setup.o jfjoch_function.o jfjoch_miscdev.o jfjoch_sysfs.o jfjoch_int.o jfjoch_i2c.o jfjoch_cmac.o
 
+# Kernel to build against. DKMS builds for a kernel that need not be the running
+# one and passes its build directory in, so this has to stay overridable.
+KVER ?= $(shell uname -r)
+KDIR ?= /lib/modules/$(KVER)/build
+
 all:
-	make -C /lib/modules/$(shell uname -r)/build M=$(CURDIR) modules
+	$(MAKE) -C $(KDIR) M=$(CURDIR) modules
 
 install:
-	make -C /lib/modules/$(shell uname -r)/build M=$(CURDIR) modules_install
+	$(MAKE) -C $(KDIR) M=$(CURDIR) modules_install
 
 clean:
-	make -C /lib/modules/$(shell uname -r)/build M=$(CURDIR) clean
+	$(MAKE) -C $(KDIR) M=$(CURDIR) clean

fpga/pcie_driver/dkms.conf

@@ -5,6 +5,6 @@ DEST_MODULE_LOCATION=/extra
 BUILT_MODULE_NAME=jfjoch
 BUILT_MODULE_LOCATION=src/
 
-MAKE="'make' -C src/ all"
-CLEAN="'make' -C src/ clean"
+MAKE="make -C src/ KDIR=${kernel_source_dir} all"
+CLEAN="make -C src/ KDIR=${kernel_source_dir} clean"
 AUTOINSTALL="yes"