psys: r78 writes to struct ipu7_bus_device fields absent from the in-kernel intel_ipu7 (ABI break for DKMS builds)

[jibsta210]

Since the 2026-06-29 drop (0e8c71a, released as r76/r78), the out-of-tree psys driver is ABI-incompatible with an in-kernel intel_ipu7, and the failure is silent: /dev/ipu7-psys0 never appears and the RGB camera is gone.

The change

0e8c71a appends two fields to struct ipu7_bus_device in drivers/media/pci/intel/ipu7/ipu7-bus.h:

struct mutex acquire_fw_task_buffer_lock;
unsigned int (*get_running_fw_task_count)(struct ipu7_bus_device *adev);

ipu7_psys_probe() writes to the second:

adev->get_running_fw_task_count = ipu7_psys_get_running_fw_task_count;

and ipu_psys_task_request() takes the new mutex.

Why that breaks

struct ipu7_bus_device is allocated by intel_ipu7. On any distro shipping the staging intel_ipu7 with the kernel while psys comes from DKMS, the two disagree about the struct:

intel_ipu7       kernel/drivers/staging/media/ipu7/intel-ipu7.ko.zst
intel_ipu7_psys  updates/dkms/intel-ipu7-psys.ko.zst

The kernel allocated the shorter struct; the DKMS psys was compiled against the longer one. So the probe-time assignment writes past the end of the allocation, and the mutex lock operates on memory that is not a mutex.

Verified against the running kernel module: intel-ipu7.ko contains ipu7_bus_ready_to_probe — a field of the same struct — and zero occurrences of either new field.

Reproduced

Two machines, independently:

• Dell XPS 16 DA16260, Panther Lake, CachyOS 7.2.0-rc4 — pinned at r74 (24d8923), works. r76 previously produced a runtime psys_ioctl GPF here.
• Dell (reporter), CachyOS 7.1.4 — r78, /dev/ipu7-psys0 MISSING after a clean rebuild and reboot, intel_ipu7_psys loaded, no RGB camera. Details in Not working on Dell Pro Plus 14, PB14250 #26.

This affects every Arch/CachyOS user on a recent kernel, since the staging intel_ipu7 landed in-tree while psys did not.

Related, same root cause

ipu7_psys_probe() also begins:

if (!adev->isp->ipu7_bus_ready_to_probe)
        return -EPROBE_DEFER;

That is a read of a field on the same kernel-owned struct, and it fails the same way when the layouts disagree — psys defers forever while isys binds normally, because isys ships alongside intel_ipu7. That asymmetry makes the failure look selective and sends people debugging the wrong component entirely.

Suggestions

The out-of-tree psys reaching into a struct owned by a module it does not build alongside is fragile by construction. Options that would help:

1. Version the interface. A version field or a size check on struct ipu7_bus_device, so a mismatched psys refuses to probe with a clear message instead of corrupting memory.
2. Keep new state in psys. get_running_fw_task_count and the FW-task mutex are psys concerns; storing them on the shared bus device is what creates the coupling.
3. Document the constraint. If the vendor tree is only supported when intel_ipu7 is also built from it, saying so in the README would save people a lot of time — the current failure gives no hint.

Happy to test patches; I have the hardware and a reproducer on two machines.