The wake line is only used as an IRQ source, yet the driver requests
it with devm_gpiod_get(). On the Dell XPS 14 DA14260 (Panther Lake)
that request lands on the pin the four CS35L57 amplifiers read their
speaker ID from. Each amplifier's _CRS carries

  GpioIo (Shared, PullNone, 0, 0, IoRestrictionInputOnly,
          "\_SB.GPI1", 0, ResourceConsumer,,) {20}

and INTC10E1 builds its _CRS at runtime from pad numbers kept in NVS:
a GpioInt (Edge, ActiveLow, Shared) first, then an Exclusive
output-only GpioIo for reset and two lines on the USB GPIO expander.
The driver maps index 0 to "wake". While it holds the line, cs35l56
fails and does not retry:

  cs35l56 sdw:0:2:01fa:3557:01:2: error -EBUSY: Failed to get spk-id-gpios

All four fail and no card is registered. Fedora 7.1.13 is the first
Fedora kernel with the driver enabled; 7.1.12 on the same board
creates the card, and 7.2.4 creates it again with intel_cvs
blacklisted. Where ipu-bridge does not expose the CSI endpoints, CSI
init returns -EPROBE_DEFER and every retry claims the line again for
the length of the handshake, which is how 7.1 fails as well.

Take the IRQ from the GpioInt entry with acpi_dev_gpio_irq_get_by(),
as the I2C core does for client->irq; this also applies the trigger
type from _CRS. The vendor driver in intel/vision-drivers does the
same. The driver binds as a platform device too, hence the explicit
lookup. A DKMS build of the patched driver on a DA14260 running
7.2.4 binds with all four amplifiers probing and the camera working
(third link).

Fixes: 8e2b43d2c10b ("media: i2c: cvs: Add driver of Intel Computer Vision Sensing Controller(CVS)")
Cc: stable@vger.kernel.org
Reported-by: jan p. springer <regnirpsj@gmail.com>
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2529031
Link: https://github.com/thesofproject/sof/issues/11152
Link: https://github.com/omacom/omarchy-pkgs/pull/419
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
---
v2: decode the INTC10E1 _CRS from the reporter's acpidump; add the
    blacklist confirmation and the tested DKMS build; Reported-by and
    Closes. Code unchanged.
v1: https://lore.kernel.org/r/20260908105717.496232-1-junjie.cao@intel.com

 drivers/media/i2c/cvs/core.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/media/i2c/cvs/core.c b/drivers/media/i2c/cvs/core.c
index d4a3b9c3bab1e..8d857bbd8ab51 100644
--- a/drivers/media/i2c/cvs/core.c
+++ b/drivers/media/i2c/cvs/core.c
@@ -725,8 +725,6 @@ static int cvs_core_probe(struct device *dev, struct i2c_client *i2c)
 	}
 
 	if (ctx->res == ICVS_FULLCAP) {
-		struct gpio_desc *wake;
-
 		ctx->rst = devm_gpiod_get(dev, "rst", GPIOD_OUT_HIGH);
 		if (IS_ERR(ctx->rst)) {
 			ret = dev_err_probe(dev, PTR_ERR(ctx->rst),
@@ -734,14 +732,12 @@ static int cvs_core_probe(struct device *dev, struct i2c_client *i2c)
 			goto err_put_ipu;
 		}
 
-		wake = devm_gpiod_get(dev, "wake", GPIOD_IN);
-		if (IS_ERR(wake)) {
-			ret = dev_err_probe(dev, PTR_ERR(wake),
-					    "failed to get wake GPIO\n");
-			goto err_put_ipu;
-		}
-
-		ctx->irq = gpiod_to_irq(wake);
+		/*
+		 * Do not request the line: another device's _CRS may list
+		 * the same pin, and its driver would then fail with -EBUSY.
+		 */
+		ctx->irq = acpi_dev_gpio_irq_get_by(ACPI_COMPANION(dev),
+						    "wake", 0);
 		if (ctx->irq < 0) {
 			ret = dev_err_probe(dev, ctx->irq,
 					    "failed to get wake IRQ\n");
-- 
2.43.0

Resending here at your request, so the tag is picked up with v2. Same
test, unchanged - v2 carries the same code.

Tested-by: Manuel Knitza <manuel.knitza@googlemail.com>

Answering the DA16260 question you asked in the ipu-bridge thread, and
giving the tag here where it belongs.

Dell XPS 16 DA16260, INTC10E1, ov08x40, linux-ptl 7.2.3. No spk-id
conflict: all four CS35L56 amplifiers bind, no -EBUSY, audio works.

Note what that does and does not show. I am running your change, but as
a DKMS copy of drivers/media/i2c/cvs rather than a kernel build - Arch
derived configs cannot enable CONFIG_VIDEO_INTEL_CVS, exactly as you
described, so the Omarchy packaging carries the in-tree driver as a DKMS
module and applies this patch verbatim on top (omacom/omarchy-pkgs#418).
So it is a test of the patched code, not of the unpatched driver on this
model - I never ran that, and cannot say whether the DA16260 would have
hit the conflict without it.

The rest of your analysis matches what I see. With vision-drivers gated
out and the in-tree driver bound, the graph is as intended:

  intel_cvs i2c-INTC10E1:00: Quirks: 0x7a (VID:0x06cb PID:0x0701)
  intel_ipu7_isys: bind Intel CVS nlanes is 2 port is 0
  intel_ipu7_isys: All sensor registration completed.

"Intel CVS" sits between ov08x40 and Intel IPU7 CSI2 0 on
/dev/v4l-subdev4, the sensor enumerates and frames flow. The
manage.c:1502 WARNING from the out-of-tree module is gone too, since that
driver never had the IRQF_ONESHOT issue.

Thanks for the correction in the other thread - I had claimed there was
no in-tree CVS driver, which was wrong.

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