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

[MaxTurcHot]

System

• Hardware: Dell XPS, Intel Core Ultra 7 258V (Lunar Lake)
• Sensor: OmniVision OV02C10 (ACPI ID: OVTI02C1) on I2C bus 16, address 0x36, 2 MIPI lanes
• Kernel: 7.0.12-201.fc44.x86_64 (Fedora 44)
• ipu7-drivers: latest main branch (PACKAGE_VERSION=0.0.0)
• ipu_bridge: in-kernel (from kernel 7.0.12 staging)

Setup

Since kernel 7.0.x includes intel-ipu7.ko and intel-ipu7-isys.ko in staging, the DKMS config only builds intel-ipu7-psys. However, the out-of-tree psys module hangs indefinitely during probe when binding to the auxiliary device created by the in-kernel intel-ipu7.ko (stuck in pm_runtime_resume_and_get), indicating an ABI mismatch between the in-kernel and out-of-tree versions.

Workaround attempted: Force-build all three modules (intel-ipu7, intel-ipu7-isys, intel-ipu7-psys) from ipu7-drivers by removing the kernel version check in the Makefile/dkms.conf. This makes psys probe successfully and /dev/ipu7-psys0 appears.

Problem

With the full out-of-tree stack loaded, the ISYS driver logs:

intel_ipu7_isys.isys intel_ipu7.isys.40: no subdevice info provided

And the sensor never binds — media-ctl -p shows no OV02C10 entity, and gst-launch-1.0 icamerasrc ... reports No sensors available.

Root Cause

ipu_bridge_init() (called from ipu7_isys_init() in ipu7.c) creates a software node named INT343E with the sensor graph endpoints:

/sys/kernel/software_nodes/INT343E/port@0/endpoint@0
/sys/kernel/software_nodes/OVTI02C1-0/port@0/endpoint@0

However, this INT343E software node is not attached to the IPU7 PCI device (0000:00:05.0, ACPI path \_SB_.PC00.IPU0) as a secondary fwnode. On Lunar Lake there is no INT343E ACPI device — the IPU is exposed directly on the PCI bus.

As a result, isys_notifier_init() in ipu7-isys.c calls:

ep = fwnode_graph_get_endpoint_by_id(dev_fwnode(dev), i, 0,
                                     FWNODE_GRAPH_ENDPOINT_NEXT);

This searches dev_fwnode(&isp->pdev->dev) which is the ACPI fwnode for \_SB_.PC00.IPU0 — it has no graph endpoints, so no sensors are found and the notifier's waiting list stays empty.

The in-kernel staging intel-ipu7-isys.ko does not have this problem (sensor binds correctly at boot), suggesting the in-kernel version handles this differently.

Kernel log (boot with out-of-tree full stack)

intel-ipu7 0000:00:05.0: Found supported sensor OVTI02C1:00   ← bridge works
intel-ipu7 0000:00:05.0: Connected 1 cameras
ov02c10 i2c-OVTI02C1:00: supply dovdd not found, using dummy regulator
intel_ipu7_isys.isys intel_ipu7.isys.40: no subdevice info provided  ← spdata NULL (expected)
                                                                        ← no sensor bind

Expected behavior

• isys_notifier_init() should find the sensor endpoints created by ipu_bridge and register the async notifier
• ov02c10 should bind to the ISYS
• /dev/video* should show a working camera pipeline

Questions for maintainers

1. How does the in-kernel staging intel-ipu7-isys.ko (kernel 7.0.12) discover sensors — does it use a different fwnode traversal or a different code path?
2. Should ipu7_isys_init() in ipu7.c call set_secondary_fwnode(dev, software_node_fwnode(swnode)) after ipu_bridge_init() to attach the INT343E node to the PCI device?
3. Should isys_notifier_init() in ipu7-isys.c fall back to software_node_find_by_name(NULL, IPU_HID) when dev_fwnode(dev) has no graph endpoints?
4. Is the psys probe hang with the in-kernel intel-ipu7.ko (kernel 7.0.x) a known issue? Is using the full out-of-tree stack the intended path on these kernels?