Bug 2529031

Created attachment 2156777 [details]
journalctl --no-hostname -k > dmesg-7.1.13-200.txt

Created attachment 2156778 [details]
journalctl --no-hostname -k > dmesg-7.1.12-200.txt

Created attachment 2157383 [details]
journalctl --no-hostname -k > dmesg-7.2.4-200.txt

unfortunately, 7.2.4 exhibits the same problem.

Root cause candidate, with the evidence so far.

What fails: all four CS35L57 amps get -EBUSY from
gpiod_get_array_optional("spk-id") in
cs35l56_get_speaker_id() and probe fails, so no card.
-EBUSY there means the spk-id property resolved to a GPIO
line another consumer already holds (gpiolib.c,
gpiod_request_commit).

Which line: a DSDT decode from the same model (openSUSE
7.2.2, thesofproject/sof issue #11152) shows every amp's
spk-id-gpios pointing at one GpioIo, \_SB.GPI1 pin 20,
Shared + InputOnly + NoPull. Same -EBUSY there, so this
is not Fedora-only.

What changed in 7.1.13-200: the build enabled
CONFIG_VIDEO_INTEL_CVS=m and backported the intel_cvs
driver (kernel-ark MR 4726). Your 7.1.13 log has

  intel_cvs i2c-INTC10E1:00: Quirks: 0x7a (VID:0x06cb
  PID:0x0701)

before the amp failures; 7.1.12 has no intel_cvs. Nothing
in v7.1.12..v7.1.13 touches gpio, pinctrl, ACPI or
SoundWire.

Why intel_cvs: the in-tree driver claims all four of its
_CRS GPIOs with devm_gpiod_get(), including the wake line,
which it only uses via gpiod_to_irq(). The vendor DKMS
driver (intel/vision-drivers) maps wake to an IRQ with
acpi_dev_gpio_irq_get_by() and never requests that line.
On another DA14260 (BIOS 1.8.2, Arch 7.1.5 plus the DKMS
driver) cvs probes first and all four amps still load
their firmware (jibsta210/svp7500-camera-fix-pack issue
#4). The wake GpioInt is the one line the in-tree driver
holds that the vendor driver does not. On fedora-7.1 the
driver also never binds: ipu-bridge there lacks the CVS
endpoints (mainline c6b1b34b5090, v7.2), CSI init returns
-EPROBE_DEFER, and each retry re-claims the GPIOs.

Not yet verified: that the wake entry in INTC10E1's _CRS
is GPI1 pin 20. That needs the DSDT.

Fix: take the wake IRQ from the GpioInt entry the way the
I2C core does for client->irq, without claiming the GPIO.
Posted to linux-media:
https://lore.kernel.org/r/20260908105717.496232-1-junjie.cao@intel.com

Two things from your side would settle it:

1. sudo acpidump -o acpidump.dat   (attach)

2. Boot with modprobe.blacklist=intel_cvs and confirm
   sound is back. 7.2.4-200 and 7.2.5-200 carry the same
   driver, and on 7.2 ipu-bridge lets it bind, so the
   line is held for as long as the driver is loaded.

Same failure, same model: BZ 2531233 (7.1.12 and 7.2.4
logs attached there, 7.2.5-200 still broken per its
comment 5) and BZ 2531966.

Created attachment 2157638 [details]
acpidump -o acpidump.dat

as requested

(In reply to junjie.cao from comment #5)
> 2. Boot with modprobe.blacklist=intel_cvs and confirm
>    sound is back. 7.2.4-200 and 7.2.5-200 carry the same
>    driver, and on 7.2 ipu-bridge lets it bind, so the
>    line is held for as long as the driver is loaded.

i can confirm that adding modprobe.blacklist=intel_cvs to the kernel command line brings back sound capabilities (using 7.2.4-200).

thanks for providing the detailed explanation and a workaround.

Backport MR for Fedora 43/44 (7.2.y) carrying the patch
above, pending upstream review:

  https://gitlab.com/cki-project/kernel-ark/-/merge_requests/4744

Comment 7 settles which consumer holds the line. The
acpidump narrows it further:

- Each amplifier (\_SB.PC00.HDAS.IDA.SNDW.SWD2..SWD5, AF01)
  carries a static GpioIo (Shared, PullNone, InputOnly,
  "\_SB.GPI1") { 0x0014 } in its _CRS, and spk-id-gpios
  points at it. All four read GPI1 pin 20.

- \_SB.PC00.CVSS (INTC10E1) builds its _CRS as
  G_IN(LDGP, ...) + G_IO(LRGP, ...) + two GpioIo on the
  USB expander VGPO + I2C on VIC1. The driver takes GPIO
  index 0 as "wake", so wake is a PCH GpioInt at pad LDGP.
  LDGP and LRGP are NVS fields, not constants in the DSDT,
  so the pad number is only visible at runtime.

Two dumps would close it, both on 7.2.4-200:

1. Normal boot (intel_cvs loaded, no sound):
     sudo cat /sys/kernel/debug/gpio > gpio-cvs.txt
   The line labelled "wake" or "cvs_wake" shows the chip
   and offset the driver holds.

2. Boot with modprobe.blacklist=intel_cvs:
     sudo cat /sys/kernel/debug/gpio > gpio-nocvs.txt
   The amps' line shows up as "spk-id" on the GPI1 chip.

If both name the same gpio number, the fix posted upstream
(https://lore.kernel.org/linux-media/20260908105717.496232-1-junjie.cao@intel.com/)
is the right one and I will resend it with your report and
this decode; the Fedora backport is MR 4744.

Two updates.

The fix has been exercised on the same model by a third
party. Omarchy's linux-ptl packaging PR
(https://github.com/omacom/omarchy-pkgs/pull/419) ships
the patched intel_cvs as a DKMS module on 7.2.4-arch1.
With it loaded the sof-soundwire card is back, all four
amps load their tuning with no -EBUSY, and the camera
still probes. Only the wake request differs from the
stock driver, so the wake line is the one the amps need.
That makes the second dump from comment 9 unnecessary;
cs35l56 releases the speaker-ID line after reading it,
so it would not show in debugfs anyway. The first dump
is still welcome as a record of the pin, nothing waits
on it.

MR 4744 is merged into fedora-7.2 (commit 31d42d7d) and
listed for 7.2.6, so the fix arrives with
kernel-7.2.6-200.fc44 once upstream 7.2.6 is out. When
it shows up in updates-testing, boot it without the
blacklist and confirm the card. v2 of the upstream patch
with the acpidump decode and the test above:
https://lore.kernel.org/r/20260913133017.624919-1-junjie.cao@intel.com

*** Bug 2531966 has been marked as a duplicate of this bug. ***

*** Bug 2531233 has been marked as a duplicate of this bug. ***

FEDORA-2026-bf6a65487f (kernel-7.2.6-300.fc45) has been submitted as an update to Fedora 45.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-bf6a65487f

FEDORA-2026-1649616d86 (kernel-7.2.6-200.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-1649616d86

FEDORA-2026-77a0319608 (kernel-7.2.6-100.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-77a0319608

FEDORA-2026-bf6a65487f has been pushed to the Fedora 45 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-bf6a65487f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-bf6a65487f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2026-1649616d86 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-1649616d86`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-1649616d86

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2026-77a0319608 has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-77a0319608`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-77a0319608

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Appears resolved on kernel 7.2.6 in Fedora 44, waiting for additional confirmations. 

thanks!

FEDORA-2026-bf6a65487f (kernel-7.2.6-300.fc45) has been pushed to the Fedora 45 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2026-1649616d86 (kernel-7.2.6-200.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2026-77a0319608 (kernel-7.2.6-100.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.