ov08x40 stuck at "waiting for fwnode graph endpoint" on kernel 7.2.x (Panther Lake / OVTI08F4) — works on 7.1.x
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- c, linux
- Domain
- operating-systems
Research direction
Start by comparing the DKMS ipu-acpi and in-tree ipu-bridge behavior across the working 7.1.8 and failing 7.2.3 kernels. Inspect the ov08x40 deferred-probe message, the created software_node, and intel_ipu7_isys registration path; use the reported debugfs, media-ctl output, and available ACPI SSDB/_DSD data. Done means the sensor binds and appears in the ISYS media graph on 7.2.x.
Written by the indexing model from the issue text.
Description
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:
ov08x40binds, and the deferred-probe entry is gone — so the in-treeipu-bridgedoes 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
- Panther Lake laptop with OV08X40 behind SVP7500, ipu7-drivers 1.0.5 via DKMS
- Boot any 7.1.x kernel → camera works
- Boot 7.2.x, same userspace and same DKMS source →
cat /sys/kernel/debug/devices_deferredshowsov08x40: 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_deviceABI break when mixing DKMS psys with in-kernelintel_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.
- Dominant language
- C
- Stars
- 14
- Forks
- 39
- Avg merge
- 28d 29m
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from intel/ipu7-drivers
-
MSI Prestige 16 AI+ (Lunar Lake): OV5675 not probed — TPS68470 “No board-data found for this model”Open
Difficulty 4/5 3-5 days Newbie friendliness 48/100
intel/ipu7-drivers#115 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
intel/ipu7-drivers#111 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
intel/ipu7-drivers#93 · 1 comment · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
intel/ipu7-drivers#92 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
intel/ipu7-drivers#86 ·
All issues in intel/ipu7-drivers
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
InukaAsith/TwinDesk#84 ·
Maintainers usually reply within 2 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
CanadaHonk/porffor#426 ·