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

[disy-mk]

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

• Out-of-tree ISYS driver fails to discover sensors on kernel 7.0.x (Lunar Lake / IPU7): ipu_bridge INT343E software node not reachable from ISYS fwnode graph #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.
• PSYS DKMS module permanently defers on kernel 7.0-rc7 (in-tree ISYS) #63 is the same machine class (Panther Lake, OV08X40, SVP7500) but concerns PSYS deferring on ipu7_bus_ready_to_probe, not the sensor.
• psys: r78 writes to struct ipu7_bus_device fields absent from the in-kernel intel_ipu7 (ABI break for DKMS builds) #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.

[Abrahamvdl]

Same 7.1 -> 7.2 regression boundary, different platform variant: Lunar Lake (Core Ultra 7 268V), in-tree staging intel_ipu7 (no DKMS), same OV08X40 / OVTI08F4 sensor on the Intel usbio transport. Filed as kernel Bugzilla 221988 (https://bugzilla.kernel.org/show_bug.cgi?id=221988) with full details.

Difference vs this report: on our machine the sensor's I2C client is never instantiated at all on 7.2.x - no 15-0010 client in sysfs, ov08x40 never probes (not even the dummy-regulator lines) - rather than existing and deferring. ipu-bridge still logs "Connected 1 cameras". A raw /dev/i2c-15 sweep shows the bus healthy (two devices ACK) while the sensor NACKs at 0x10, consistent with the sensor's ACPI power resources never engaging because its client was never created. ipu_bridge.ko sensor tables are string-identical between 7.1.11 and 7.2.3 (OVTI08F4 present in both), so the behavioral change is likely in built-in core code (i2c-core-acpi enumeration / driver-core software-node or dependency handling).

Your in-tree staging data point (sensor binds, ISYS still doesn't add it to the media graph) brackets our case from the other side. Will cross-post any triage or patch progress on the Bugzilla entry.

[disy-mk]

Resolved — and my original report misattributed the cause. It is not ipu-acpi.

I opened this saying the out-of-tree ipu-acpi no longer produced the sensor's fwnode graph endpoint on 7.2.x. The deferred-probe symptom was real, but the cause is in the in-tree ipu-bridge, and ipu7-drivers is not at fault. Correcting that here so nobody spends time in the wrong module.

What actually changed in 7.2

drivers/media/pci/intel/ipu-bridge.c, v7.1.8 → v7.2.3:

 static const struct acpi_device_id ivsc_acpi_ids[] = {
 	{ "INTC10CF" },
+	{ "INTC10DE" }, /* LNL */
+	{ "INTC10E0" }, /* ARL */
+	{ "INTC10E1" }, /* PTL */
 };

ivsc_acpi_ids[] is consumed only by ipu_bridge_get_ivsc_acpi_dev(). From 7.2 on, the bridge therefore recognises the CVS device (INTC10E1 on Panther Lake) as an IVSC bridge and builds the sensor's graph toward it. There is no in-tree CVS counterpart to terminate that path, so the endpoint never appears and ov08x40 sits in deferred probe — which is exactly the waiting for fwnode graph endpoint I reported.

Adding a module parameter to skip those three IDs restores the 7.1 behaviour:

legacy_cvs: Y
bind ov08x40 17-0036 nlanes is 2 port is 0
All sensor registration completed.

Sensor back in the media graph, /dev/v4l-subdev0..4 present, real frames, and it survives an s2idle suspend/resume cycle unchanged. Verified on both linux 7.2.3-arch1-3 and linux-ptl 7.2.3-arch1-1 (Dell XPS 16 DA16260). Independently found first by @klaudworks — see omacom/omarchy#10948, where the practical side of this lives.

Where this leaves the out-of-tree stack

The three IDs were also moved into acpi_honor_dep_ids[] in drivers/acpi/scan.c in the same 7.2 conversion — see kernel Bugzilla 221988. Two gates from one change, and which one a machine hits depends on whether a CVS driver is bound:

• Without any CVS driver the scan.c gate fires first: the sensor's i2c client is never instantiated (the Lunar Lake case in 221988).
• With the out-of-tree intel_cvs from vision-drivers, which does call acpi_dev_clear_dependencies(), that gate passes — the client exists and probes — and then the ipu-bridge gate stops it instead. That is this machine.

So the 7.2 bridge assumes an in-tree CVS driver that, as far as I can tell, does not exist yet, while the shipped stack still relies on the out-of-tree one. Two questions for the maintainers, either of which would fix it properly:

1. Should the bridge take the CVS path only when a driver is actually bound to the CVS device, rather than on ACPI ID match alone? A dependency on an unclaimed supplier blocking a device that worked for years looks like the general shape of the bug, and 221988 raises the same point about scan.c.
2. Or should ipu7-drivers / vision-drivers grow the piece the in-tree bridge now expects?

Happy to test either. This machine reproduces the failure and the fix on demand, and I can rebuild and boot both kernels quickly.

One unrelated correction while I am here: the jsoncpp half mentioned at the bottom of my original report is resolved — intel-ipu7-camera 1.0.5-2 is rebuilt against 1.9.8 (omacom/omarchy#10837).

[disy-mk]

Correction: I was wrong about there being no in-tree CVS driver.

7.2 added drivers/media/i2c/cvs (CONFIG_VIDEO_INTEL_CVS) in the same series as c6b1b34b5090 — it provides exactly the V4L2 sub-device the bridge routes to. My earlier comment claimed it did not exist, and the two questions I asked the maintainers were based on that mistake.

It never ran here for two reasons, neither of them ipu7-drivers:

• Arch-derived configs hide the option behind MEDIA_HIDE_ANCILLARY_SUBDRV, so olddefconfig drops it.
• The out-of-tree intel_cvs from vision-drivers has the same module name and displaces it through DKMS.

With the in-tree driver loaded the 7.2 graph is as intended — an Intel CVS entity between ov08x40 and Intel IPU7 CSI2 0, sensor enumerated, real frames, and no manage.c:1502 WARNING because that driver never had the IRQF_ONESHOT issue.

Found by @spencerbull while packaging the fix: omacom/omarchy-pkgs#418, which ships the in-tree driver as a DKMS module gated to 7.2+ and gates vision-drivers to ≤7.1 so the two cannot collide. Verified here on a Dell XPS 16 DA16260 with linux-ptl 7.2.3.

So there is nothing for this project to fix, and this issue can be closed.

Assisted-by: Claude Code:claude-opus-5