From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F303448B9B for ; Tue, 1 Sep 2026 19:51:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788292301; cv=none; b=SeZlIK2PWSjFpYNIAs7EnZxlLctH0iJ/rKLxpNd+MZbBVSqKmVs7F9pwoG0y9pPPzUBIbLA9psfUEvnyKNXxL0EfZCG+Siejv2ZdbyZGIOnK1cr5k0wMduplTyygMIrQFG9tcI27gA271UdyIrjZcAoYqk8wV5LdbyVSJBt/dso= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788292301; c=relaxed/simple; bh=jngS6x+tIf4czuIBq+LweYf0mEUL/modiUynUQ9e7Nw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HJPlluqoEwFkqyq/IQSc2HNfNGUFiYQNcI4hCRErgcAWD49X9HfMn2/mEBB6WgeSVL2uA5SGlzzT0uVuQ0dmhfQCWpfFWAnq7ulUxfT0+8tDyTnL3nsaxrBmo2cIj4he6sRLa6Xql3FfGTP6fUeJ6RSV8+XeIfyoEtdfH4/d13A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ICd/UeuP; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ICd/UeuP" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so1871125e9.1 for ; Tue, 01 Sep 2026 12:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788292297; x=1788897097; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=6xYO5+e2rLJr7nQr6IUR30t9mLQPc96NvTA35d5T/wc=; b=ICd/UeuP2/+rdRQMeAR884JF6BdAwGHiGEU2hEcYaF5cdmsytMZ6upS2FbK8Zzjf5I HI0a40LqUPO/IC9AMmKeNfPj4JCOUrtvuWZIvm9oblUKMOtsH0Hdr+99TPJwDyXQTpja Yqr/8AxORd/bjiCv9UyHpiqlzW+5ytkSOkOXzMd4iTBaY3xQqS5LGNLWW50TTHQB6PnW LRZCSe8gEU8eOXOQLdjpBHPe5pzNdnE/6t9c1XaXxdwY+/aOvRD199z7sx2UI5/FP6w8 L1oCaLsjCAq6jRFy9PV8QlaNXj/q+cJWs4kxHvxOSCw9tKRFeE7rnrPPJsklL3qe2T41 38KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788292297; x=1788897097; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=6xYO5+e2rLJr7nQr6IUR30t9mLQPc96NvTA35d5T/wc=; b=OZrU0SoKoyD/DXH9roeJoAtHJkC6Zi+ro4vmWWt2NDPiA1KzLszeWfU7hTxX3wK98X fbVCFm7OdJuG1dmB2RD90OgaNLAea8uj9kJ1whs33h8GT5SgpPLXahBT5AqTX9LD+DJD RMbUTqQFsEzMdFwCEP4oWpYczNGZOP9aIxbdXcOHUN1+9hXt32p99DOewk5jVHilkUzm Whcw/scdSdRhOLkCK6auAC8RjIGJrRFwEKB6n7ruoND+8i3ksLhy5+Z+P+Vy4fX8bGNT pHsYsqAX4BMgB1amadUT6H+62gJ8SPpJ1U9WyclQtwXefkzp6aoPfXTReVYJyvSBRNxv gcrQ== X-Gm-Message-State: AFuF++ktgFyn6QcA1qZs8MU0khBn5oRrQfOqMp2u3cZaDdWcib241qCP QYgcPm/yfSikcL1ZPl6hXCowWEvbXK3rTiHk4Zm4Uuc9O2N+xN3rPpc= X-Gm-Gg: AR+sD13GjbfSW165IBtGdx9hZY4Up7IE+vXEICEC2DyAENLSv1z2t+ICU2Flk8tQHZk uCKAN5ThRcsT7uv1UE0I8Eny5FR2UCrT/HvQnY1JFXF/r4gJK6RiQrhvufzSi2RxqoroGrm7Sc8 PhddmnkMtt/V/aETXNYV/KK+UTbA39insjXt62tvsr4NcE7ipiKcXYbkFG3qrzeVfrrYhlU9Xqn FPXRhDZbNC6pP4rtorpDm9xwtGGSA0zDZeeS2ucF4OTINRDCWbnMw97L+M2ab0Qy1+RJUkOODYO 4X6ULbCA6fHXKKwO+YesXwcyOE9YuYrL805uazK/Uvf8daiQciRTqryWtrM0yP+zKIUCxY1bjNk hYog/Ou53x5jsCNpceQrWPwXc/Bs67jFXEEbDtVPROvSIySjMuDe4VZVgrEhQn1lDAjtEVE6KvR G6qTKyPuw52QIq5QxAY2MqgQaFEC6VdCFz0NEKX1vkrImDD91R7eMVuO6WfjofrPRSPj7uHbAWa NZenqpQ/gFcIr0qETjtvpgmh5bVTqUvWanlXV1dN1xsAX93Ze3EuKZlz1W2J0T1gdWedCAthQ== X-Received: by 2002:a05:600c:a086:b0:495:48d7:f178 with SMTP id 5b1f17b1804b1-49ce5815dddmr66415e9.11.1788292297027; Tue, 01 Sep 2026 12:51:37 -0700 (PDT) Received: from chateau ([148.69.202.63]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce4761dd1sm5567285e9.0.2026.09.01.12.51.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Sep 2026 12:51:36 -0700 (PDT) From: Sergey Zagursky To: Miguel Vadillo , Sakari Ailus , Mehdi Djait , Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, regressions@lists.linux.dev, Sergey Zagursky , stable@vger.kernel.org Subject: [PATCH] media: ipu-bridge: do not use the CVS device lookup for IVSC Date: Tue, 1 Sep 2026 20:50:36 +0100 Message-ID: <20260901195036.7648-1-gvozdoder@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901194526.6369-1-gvozdoder@gmail.com> References: <20260901194526.6369-1-gvozdoder@gmail.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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. Fixes: c6b1b34b5090 ("media: pci: intel: Add CVS support for IPU bridge driver") Link: https://lore.kernel.org/linux-media/20260901194526.6369-1-gvozdoder@gmail.com/ Cc: stable@vger.kernel.org Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Sergey Zagursky --- Tested 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. 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: 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. The bug report this replies to describes what the tool did. drivers/media/pci/intel/ipu-bridge.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c index 1bb3a3e98d6b..2c3b9efb0b2f 100644 --- a/drivers/media/pci/intel/ipu-bridge.c +++ b/drivers/media/pci/intel/ipu-bridge.c @@ -232,6 +232,15 @@ 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 struct acpi_device *ipu_bridge_get_ivsc_acpi_dev(struct acpi_device *adev) { unsigned int i; @@ -283,6 +292,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 (acpi_match_device_ids(adev, cvs_acpi_ids)) + 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