Fedora Account System
Red Hat Associate
Red Hat Customer
1. Please describe the problem: sound stopped being available with kernel 7.1.13-200 2. What is the Version-Release number of the kernel: 7.1.13-200 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : 7.1.12-200 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: - boot kernel 7.1.13-200 - open gnome control center, go to sound, only dummy output available 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: dunno; i'd rather not use /rawhide/ on a production system 6. Are you running any modules that not shipped with directly Fedora's kernel?: no 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Reproducible: Always
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!