Re: [PATCH v3] media: ipu-bridge: do not use the CVS device lookup for IVSC

[Manuel Knitza <manuel.knitza@googlemail.com>]

The CVS side of the same commit breaks cameras too, in the mirror image of
what this patch fixes, and I think it is the "separate series" you mention.

Dell XPS 16 DA16260, Panther Lake, IPU7, ov08x40 behind a CVS device
(INTC10E1). 7.1.8 works, 7.2 does not:

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

No sensor entity in /dev/media0, no subdev, no camera in userspace.
Traced to the same commit you cite, c6b1b34b5090 - not by bisect, by
diffing ipu-bridge.c between v7.1.8 and v7.2.3: it adds
INTC10DE/INTC10E0/INTC10E1 to ivsc_acpi_ids[] and touches nothing else in
that file.

Your reasoning for keeping the fallbacks for CVS is

    CVS binds a driver to the ACPI device itself, so matching on the
    companion stays unambiguous there.

The match is indeed unambiguous. The problem is what is bound. On this
machine the driver on that i2c device is Intel's out-of-tree intel_cvs
(from intel/vision-drivers), and it provides only ownership arbitration and
firmware update - no CSI-2 subdevice. ipu_bridge_instantiate_ivsc()
attaches the software node to it and reports success, so the sensor's graph
terminates at a device that offers no endpoint, and the sensor waits
forever. There is no in-tree CVS driver to take that role.

So the lookup finds the right device and the wrong kind of device. Skipping
the three CVS IDs in ipu_bridge_get_ivsc_acpi_dev() restores the 7.1
behaviour with everything else unchanged:

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

Sensor and CSI-2 link back in the media graph, real frames, and it survives
s2idle suspend/resume. Tested on 7.2.3, stock and Panther-Lake kernels
alike; both carry identical ipu-bridge source.

That is only a workaround - it disables CVS support wholesale, which is not
what anyone wants. The shape of a real fix is presumably the separation you
already named: take the CVS path only when something is bound that actually
provides the CSI-2 subdevice, rather than on an ACPI ID match. Gating on a
bound driver would also cover the ACPI half of the same conversion,
c28527ce5d06, where a dependency on an unclaimed supplier blocks
enumeration outright - kernel bugzilla 221988.

I am happy to test patches; this machine reproduces both the failure and
the fix on demand, and I can build and boot either kernel quickly.

Reports with the details, if useful:
  https://bugzilla.kernel.org/show_bug.cgi?id=221988  (comments 9 and 10)
  https://github.com/intel/ipu7-drivers/issues/102
  https://github.com/omacom/omarchy/issues/10948

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