ov08x40 stuck at "waiting for fwnode graph endpoint" on kernel 7.2.x (Panther Lake / OVTI08F4) — works on 7.1.x

まず、動作する 7.1.8 kernel と失敗する 7.2.3 kernel の間で、DKMS ipu-acpi と in-tree ipu-bridge の動作を比較します。ov08x40 の deferred-probe メッセージ、作成された software_node、intel_ipu7_isys の登録経路を調査し、報告された debugfs の出力、media-ctl の出力、および利用可能な ACPI SSDB/_DSD データを使用します。7.2.x でセンサーがバインドされ、ISYS メディアグラフに表示されれば完了です。

Summary

On kernel 7.2.x the out-of-tree ipu-acpi no longer produces the sensor's fwnode graph endpoint, so ov08x40 sits in deferred probe forever and never reaches the ISYS media graph. The exact same setup works on 7.1.8. Booting the in-tree staging driver instead gets the sensor bound — which points at ipu-acpi rather than at the sensor driver or the bridge concept.

This is a clean 7.1 → 7.2 regression boundary, which I did not find in #79 / #63 / #93 (see "Relation to existing issues" below).

Environment

Machine	Dell XPS 16 DA16260, Core Ultra X7 358H (Panther Lake), BIOS 1.10.1
Sensor	OV08X40, ACPI OVTI08F4:00, behind Synaptics SVP7500 (06cb:0701)
Distro	Arch Linux (Omarchy 4.0.3), intel-ipu7-camera 1.0.5
Driver source	ipu7-drivers 1.0.5 (DKMS), built cleanly for every kernel below
Kernels	linux-ptl 7.1.8-arch1-2 (works) vs 7.2.3-arch1-1 (broken); stock 7.2.3-arch1-3 behaves the same as 7.2.3-ptl

Symptom on 7.2.3

ov08x40 binds to nothing and stays deferred:

# cat /sys/kernel/debug/devices_deferred
i2c-OVTI08F4:00	ov08x40: waiting for fwnode graph endpoint

The IPU7 side comes up and even reports the sensor, but ISYS never binds it:

intel-ipu7 0000:00:05.0: Found supported sensor OVTI08F4:00
intel-ipu7 0000:00:05.0: Connected 1 cameras
intel-ipu7 0000:00:05.0: CSE authenticate_run done
intel_ipu7_psys.psys intel_ipu7.psys.40: IPU psys probe done.
ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator
   <- nothing further; no "bind ov08x40", no "All sensor registration completed."

media-ctl -p -d /dev/media0 shows 36 entities (ISYS Capture 0-31 + CSI2 0-3) and no ov08x40 entity. /sys/bus/i2c/devices/i2c-OVTI08F4:00/software_node exists, so something was created, but the graph endpoint the sensor waits for is not reachable.

Same machine on 7.1.8 — works

intel-ipu7 0000:00:05.0: Connected 1 cameras
ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator
intel_ipu7_isys.isys intel_ipu7.isys.40: bind ov08x40 17-0036 nlanes is 2 port is 0
intel_ipu7_isys.isys intel_ipu7.isys.40: All sensor registration completed.

entity 233: ov08x40 17-0036 (1 pad, 1 link), /dev/v4l-subdev4, camera streams normally. Nothing about the userspace, the ACPI tables or the hardware changed between the two boots — only the kernel.

Data point: the in-tree staging driver gets further

Uninstalling the DKMS modules for that kernel (dkms uninstall ipu7-drivers/1.0.5 -k 7.2.3-arch1-1-ptl, which restores the archived in-tree intel-ipu7.ko / intel-ipu7-isys.ko) changes the picture:

• ov08x40 binds, and the deferred-probe entry is gone — so the in-tree ipu-bridge does produce a usable endpoint for this sensor on 7.2.3
• ISYS still does not add the sensor to the media graph, and libcamera 0.7.2 reports SimplePipeline: No sensor found for /dev/media0, so this is not a complete workaround

A possibly relevant difference: the in-tree ipu-bridge carries OVTI08F4 in its supported-sensor table

$ strings .../ipu-bridge.ko | grep -E '^(OVTI|HIMX)[0-9A-Z]{4}$' | sort -u | tr '\n' ' '
HIMX11B1 HIMX2170 HIMX2172 OVTI01A0 OVTI01AS OVTI02C1 OVTI02E1 OVTI05C1 OVTI08A1 OVTI08F4 OVTI13B1 OVTI2680 OVTI5675 OVTI8856 OVTIDB10

whereas the DKMS ipu-acpi.ko contains no OVTI08F4 string at all (0 matches) and appears to rely purely on generic SSDB parsing.

Reproduction

1. Panther Lake laptop with OV08X40 behind SVP7500, ipu7-drivers 1.0.5 via DKMS
2. Boot any 7.1.x kernel → camera works
3. Boot 7.2.x, same userspace and same DKMS source → cat /sys/kernel/debug/devices_deferred shows ov08x40: waiting for fwnode graph endpoint, no sensor entity in /dev/media0

Relation to existing issues

• #79 (Lunar Lake, OV02C10, kernel 7.0.12) analyses bridge-created software nodes not being reachable from the ISYS fwnode traversal. Very likely the same underlying fragility, but that report is ISYS-side (no subdevice info provided) and on a different platform/kernel; mine is sensor-side and has a sharp 7.1 → 7.2 boundary.
• #63 is the same machine class (Panther Lake, OV08X40, SVP7500) but concerns PSYS deferring on ipu7_bus_ready_to_probe, not the sensor.
• #93 concerns the struct ipu7_bus_device ABI break when mixing DKMS psys with in-kernel intel_ipu7.

Note: this machine also hit an unrelated userspace breakage at the same time — a jsoncpp soname bump
that stops Intel's HAL plugin from loading (tracked at omacom/omarchy#10837). That one is fixed here and
is not the cause of the sensor problem above: with the HAL working, the sensor still never binds on 7.2.x,
and on 7.1.8 it binds regardless.

Happy to test patches, collect additional traces (dynamic debug on intel_ipu7_isys produced no output here), or dump the ACPI SSDB/_DSD data for this sensor if that helps.