media: ipu-bridge: do not use the CVS device lookup for IVSC

Since commit c6b1b34b5090 ("media: pci: intel: Add CVS support for IPU bridge driver") the internal camera no longer works on laptops where the sensor sits behind an IVSC, for example a Dell XPS 16 9640 (IPU6, INTC10CF, ov02c10):

intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00 intel-ipu6 0000:00:05.0: Connected 1 cameras
ivsc_csi intel_vsc-92335fcf-3203-4472-af93-7b4453ac29da: mei-csi probed
without device fwnode!

No sensor subdevice is registered, the media graph has no sensor entity and userspace finds no camera at all.

ipu_bridge_get_ivsc_csi_dev() first looks for the platform device named "intel_vsc" and returns its mei-csi child. That device is created by mei_vsc, which on this machine only appears once the LJCA USB bridge and its SPI controller have probed, about a second after the IPU6 probe that runs the bridge:

  07:59:29.297  platform INTC10CF:00 created (ACPI scan)
  07:59:41      intel-ipu6 probe -> ipu_bridge_init()
  07:59:42.391  platform intel_vsc created (mei_vsc)

The commit above added two fallbacks for CVS which match on the ACPI companion alone. They are reached for every entry of ivsc_acpi_ids[], IVSC IDs included. The IVSC ACPI device has two physical nodes:

INTC10CF:00/physical_node -> platform/INTC10CF:00 (no driver bound)
INTC10CF:00/physical_node1 -> platform/intel_vsc (mei_vsc)

so bus_find_device_by_acpi_dev(&platform_bus_type, adev) returns the bare platform device. ipu_bridge_instantiate_ivsc() then attaches the IVSC software node to that device instead of to the mei-csi client, the bridge reports success, and the probe is never retried. mei_csi later probes without a fwnode, the CSI-2 link is never described, and the sensor ACPI device, which has an honoured _DEP on the IVSC device, is never enumerated.

Before those fallbacks existed the lookup returned NULL here, the bridge failed with -ENODEV and the probe was retried once the IVSC device had shown up.

Restrict the two fallbacks to the CVS IDs. CVS binds a driver to the ACPI device itself, so matching on the companion is unambiguous there.

---
Changes since v1:
- Wrap the ACPI ID match in a named helper, ipu_bridge_is_cvs_dev(), so the polarity is readable at the call site. acpi_match_device_ids() returns 0 on a match, which made the v1 condition easy to misread. No functional change.

v1: https://lore.kernel.org/linux-media/[email protected]/

The functional testing below was done with v1 on the affected machine (Dell XPS 16 9640, IPU6 + IVSC + ov02c10) on top of 7.2.2, where drivers/media/pci/intel/ipu-bridge.c is byte-identical to v7.2. v2 changes only how the same condition is spelled, so I rebuilt it but did not boot it again. Without the patch libcamera finds no camera at all; with it:

  $ cam -l
  1: Internal front camera (\_SB_.PC00.LNK1)

  $ cam -c1 --capture=5
  202.794954 (30.05 fps) cam0-stream0 seq: 000003 bytesused: 8386560
  202.828224 (30.06 fps) cam0-stream0 seq: 000004 bytesused: 8386560

The media graph gains the entities that were missing:

- entity 349: Intel IVSC CSI (2 pads, 2 links, 0 routes)
- entity 368: ov02c10 21-0036 (1 pad, 1 link, 0 routes)

and the restored retry is visible in dmesg:

pci 0000:00:05.0: deferred probe pending: intel-ipu6: IPU6 bridge init failed intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00 intel-ipu6 0000:00:05.0: Connected 1 cameras

"mei-csi probed without device fwnode!" is gone, ov02c10 binds to i2c-OVTI02C1:00, and eight v4l-subdev nodes appear.

This patch is against v7.3-rc1. The version tested on 7.2.2 is the same change without the INTC10FA entry, which 7.2.x does not have. Building drivers/media/pci/intel/ipu-bridge.c with W=1 produces no new warnings.

Not covered: v2 itself is only compile-tested (no new warnings with W=1); I have no CVS hardware, so the CVS path is only reasoned about, not tested; and I have not booted v7.3-rc1 itself.

This patch was produced with the help of an AI coding assistant; see the Assisted-by tag above and Documentation/process/generated-content.rst.

 drivers/media/pci/intel/ipu-bridge.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

index 1bb3a3e98d6b..a29d4bdb8f02 100644
@@ -232,6 +232,20 @@ static const struct acpi_device_id ivsc_acpi_ids[] = {
 	{ "INTC10FA" }, /* NVL */
 };
 
+/* The subset of ivsc_acpi_ids[] which are CVS, rather than IVSC, devices. */
+static const struct acpi_device_id cvs_acpi_ids[] = {
+	{ "INTC10DE" }, /* LNL */
+	{ "INTC10E0" }, /* ARL */
+	{ "INTC10E1" }, /* PTL */
+	{ "INTC10FA" }, /* NVL */
+	{ }
+};
+
+static bool ipu_bridge_is_cvs_dev(struct acpi_device *adev)
+{
+	return !acpi_match_device_ids(adev, cvs_acpi_ids);
+}
+
 static struct acpi_device *ipu_bridge_get_ivsc_acpi_dev(struct acpi_device *adev)
 {
 	unsigned int i;

@@ -283,6 +297,17 @@ static struct device *ipu_bridge_get_ivsc_csi_dev(struct acpi_device *adev)
 		return csi_dev;
 	}
 
+	/*
+	 * The lookups below match on the ACPI companion alone. That is fine for
+	 * CVS, which binds a driver to that very device, but not for IVSC: there
+	 * the ACPI device also has a driverless platform device, which would be
+	 * returned instead of the mei-csi client. Return NULL for IVSC so that
+	 * the caller fails and the probe is retried once the IVSC device shows
+	 * up.
+	 */
+	if (!ipu_bridge_is_cvs_dev(adev))
+		return NULL;
+
 	/* Try to locate CVS device on the I2C bus */
 	csi_dev = bus_find_device_by_acpi_dev(&i2c_bus_type, adev);
 	if (csi_dev)

2.55.0