summaryrefslogtreecommitdiff
path: root/sound
AgeCommit message (Collapse)Author
41 hoursMerge tag 'asoc-fix-v7.3-rc6' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v7.3 A fairly small collection of fixes and a few device quirks, nothing especially remarkable unless you have the affected system.
2 daysASoC: amd: acp: Add more ACP7.0 match entries for Cirrus Logic partsSimon Trimmer
This adds the following SoundWire configuration: cs42l43b link 0 UID 1 cs35l57 link 0 UID 0 cs35l57 link 0 UID 1 Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Link: https://patch.msgid.link/20261007130857.102432-1-simont@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2 daysASoC: amd: acp: Add DMI override for ASUS EXPERTBOOK AM7406CKASimon Trimmer
A BIOS for this SKU has been observed with an incorrect acp-audio-config-flag, add the override so that it is forced to the correct value. Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Link: https://patch.msgid.link/20261007130835.102325-1-simont@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
3 daysASoC: cs35l56/57/62/63: Use the correct SoundWire DP for feedbackMark Brown
Richard Fitzgerald <rf@opensource.cirrus.com> says: The amp feedback path (AEC) was incorrectly using SoundWire DP3. The firmware outputs SDCA OT25 feedback on DP4. DP3 is reserved for SDCA companion amp. This series adds a DAI for OT25 and switches the sdw machine driver to use the new DAI for the feedback path. Link: https://patch.msgid.link/20261005155235.1386525-1-rf@opensource.cirrus.com
3 daysASoC: sdw_utils: Switch CS35L56/57/62/63 to use OT25 DAIRichard Fitzgerald
Change the CS35L56/57/62/63 entries in codec_info_list[] to use the OT25 DAI for amp feedback. The AMP feedback was incorrectly using a DAI connected to DP3, but that is reserved for SDCA companion amp. The correct amp output is DP4, which is the SDCA OT25 feedback output. Fixes: 898cd43bde307 ("ASoC: intel: sof_sdw: Add support for CS35L63 into machine driver") Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20261005155235.1386525-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
3 daysASoC: cs35l56: Add DAI for SDCA OT25 streamRichard Fitzgerald
Add a DAI for the SDCA OT25 stream on SoundWire DP4. The SDCA-defined OT25 stream is an amp reference feedback, typically used for AEC. The firmware outputs this on DP4. The firmware owns all control registers for this stream so there are no mixer controls or any other configuration options. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20261005155235.1386525-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
3 daysASoC: samsung: i2s: enable op_clk in probe to balance runtime PMMarek Szyprowski
The probe function puts the device into the runtime PM active state with only the "iis" bus clock enabled, but it also sets priv->op_clk to the parent of the RCLK_SRC mux without enabling it. The runtime PM suspend callback disables both clocks, so the first runtime suspend after probe disables op_clk once more than it was enabled. On Exynos5250 Arndale both clocks resolve to the same EXYNOS_I2S_BUS gate, so this triggers the following warning during boot: WARNING: drivers/clk/clk.c:1270 at clk_core_disable+0xe4/0x23c, CPU#0: kworker/u8:3/45 i2s_bus already disabled ... Workqueue: pm pm_runtime_work Call trace: ... clk_core_disable from clk_disable+0x28/0x34 clk_disable from i2s_runtime_suspend+0x58/0x68 [snd_soc_i2s] i2s_runtime_suspend [snd_soc_i2s] from genpd_runtime_suspend+0xc4/0x298 genpd_runtime_suspend from __rpm_callback+0x48/0x18c __rpm_callback from rpm_callback+0x4c/0x50 rpm_callback from rpm_suspend+0xf4/0x718 rpm_suspend from pm_runtime_work+0x9c/0xa0 ... Fix this by enabling op_clk in probe right after getting it, so the clock state matches the runtime PM active state, and by disabling it in remove. Fixes: 48279c53fd1d ("ASoC: samsung: i2s: Prevent external abort on exynos5433 I2S1 access") Assisted-by: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://patch.msgid.link/20261002092116.585466-1-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
3 daysASoC: adau1372: fix invalid default state of output ASRC and DAC muxesAlvin Šipraga
The chip has strange power-on reset values for the registers that control the output ASRC and DAC source muxes - the values are actually marked "Reserved" in the datasheet [1]. This means that until the underlying kcontrols are modified, the codec will not function as expected. The registers in question are: register / field reset value valid values ASRCO_SOURCE_0_1 0x10 ASRC_OUT_SOURCE0 0 4 .. 16 ASRC_OUT_SOURCE1 1 4 .. 16 ASRCO_SOURCE_2_3 0x10 ASRC_OUT_SOURCE2 2 4 .. 16 ASRC_OUT_SOURCE3 3 4 .. 16 DAC_SOURCE_0_1 0x10 DAC_SOURCE_0 0 12 .. 13 DAC_SOURCE_1 1 12 .. 13 Set some sane defaults during the driver probe: ADC Decimator0 -> Output ASRC0 ADC Decimator1 -> Output ASRC1 ADC Decimator2 -> Output ASRC2 ADC Decimator3 -> Output ASRC3 Input ASRC0 -> DAC0 Input ASRC1 -> DAC1 With this, the chip will behave as advertised by the default kcontrol state exposed by the driver. [1] https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1372.pdf Fixes: 6cd4c6459e47 ("ASoC: Add ADAU1372 audio CODEC support") Signed-off-by: Alvin Šipraga <alvin.sipraga@analog.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20261006-asoc-adau1372-fixes-v1-2-599cc17fb5f6@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
3 daysASoC: adau1372: allow sleepy powerdown GPIOsAlvin Šipraga
gpiod_set_value() emits a WARN when the GPIO provider indicates that it can sleep, as is typical for I2C controlled GPIO expanders. Since the powerdown GPIO is only manipulated in process context, use the _cansleep variant instead. This lets the driver use sleepy GPIOs to power off the chip. Fixes: 6cd4c6459e47 ("ASoC: Add ADAU1372 audio CODEC support") Signed-off-by: Alvin Šipraga <alvin.sipraga@analog.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20261006-asoc-adau1372-fixes-v1-1-599cc17fb5f6@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
4 daysASoC: amd: yc: Add DMI quirk for Acer Aspire Go 15 (AG15-21P)Michael Garland
The Acer Aspire Go 15 (AG15-21P, board MDC Herbag2_MDU) has two PDM DMICs connected to the ACP. The BIOS does not set the AcpDmicConnected _DSD property, so the acp6x machine driver never registers the DMIC card. The existing Herbag_MDU entry does not match this board name, so add a DMI quirk for it. Tested on BIOS V1.11: the acp6x DMIC capture device is registered and records audio on both channels. Cc: stable@vger.kernel.org Signed-off-by: Michael Garland <minimelkav@gmail.com> Link: https://patch.msgid.link/20261005-acp6x-herbag2-quirk-v1-1-a1f2683d758f@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
7 daysALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg3xxx (103c:8bfd)Jaidheer Sirigineedi
The mute LED on the HP Pavilion Laptop 15-eg3xxx (PCI SSID 103c:8bfd, Realtek ALC287) does not work because the machine has no entry in the quirk table. No fixup is applied, so the mute LED is never driven, even though the mute function itself works. The LED is controlled via GPIO pin 4 (mask 0x10), which is exactly what ALC287_FIXUP_HP_GPIO_LED configures. This was verified on the hardware with hda-verb: setting the GPIO data bit lights the mute LED, and clearing it turns the LED off. hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x10 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION 0x10 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x10 # LED on hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x00 # LED off Add a quirk entry for 103c:8bfd using ALC287_FIXUP_HP_GPIO_LED. Signed-off-by: Jaidheer Sirigineedi <jaidheer7@gmail.com> Link: https://patch.msgid.link/20261002185951.33855-1-jaidheer7@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
7 daysALSA: hda/tas2781: Accept V1 calibration data without CRCMohamed Yassine Jebabli
Some Lenovo BIOSes (e.g. Legion Pro 7 16IRX9H, SSID 17aa:38cd) store valid V1 calibration data in the CALI_DATA EFI variable but leave the TimeStamp and CRC fields zeroed. The driver rejects such data, so the amplifiers always run with default parameters on these machines. The rejection was silent until commit 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") turned it into "V1 CRC error". The stored values are consistent (R0 = 3.82/3.83 ohm, 1/R0 matching within 1e-4), so accept V1 data when both TimeStamp and CRC are zero and the first device entry is non-zero, and emit a warning. Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Yassine Jebabli <med.jebabli@gmail.com> Link: https://patch.msgid.link/20261001-tas2781-v1-nocrc-v1-1-ff0c1032ce76@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
7 daysALSA: ctxfi: Fix memory leakage when clearing DAO input mappersHarin Lee
Commit e576e7843c0d ("ALSA: ctxfi: Simplify dao_clear_{left,right}_input() functions") centralized the DAO input mapper clearing logic in dao_clear_input(), but omitted the kfree() calls. It removes the mapper entries from the list and sets their pointers to NULL without freeing the allocated array. This leaks memory each time dao_clear_input() is called. Store the base pointer of the allocation before clearing the mapper entries and free the array after removing entries from the list. Fixes: e576e7843c0d ("ALSA: ctxfi: Simplify dao_clear_{left,right}_input() functions") Cc: stable@vger.kernel.org Signed-off-by: Harin Lee <me@harin.net> Link: https://patch.msgid.link/20261001144501.3050667-2-me@harin.net Signed-off-by: Takashi Iwai <tiwai@suse.de>
7 daysALSA: hda/realtek: Add quirk for ASRock NUC BOX-358HEckhart Mohr
Fix headphone jack detection for some devices Signed-off-by: Eckhart Mohr <e.mohr@tuxedocomputers.com> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Link: https://patch.msgid.link/20261001183403.103990-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
7 daysALSA: usb-audio: Add native DSD support for Cambridge Audio streamersMatus Gajdos
The Cambridge Audio streamer advertises the UAC2 RAW_DATA format on altsetting 2 of its playback interface, but without the DSD_RAW quirk flag the driver exposes it only as a SPECIAL format that cannot be used. Add QUIRK_FLAG_DSD_RAW for the device (USB ID 22e8:ca10), so the altsetting is exposed as DSD_U32_BE, enabling native DSD64/128/256 playback. Tested with: gst-launch-1.0 filesrc location=file.dsf ! \ avdemux_dsf ! dsdconvert ! \ alsasink device=hw:2,0 Signed-off-by: Matus Gajdos <matuszpd@gmail.com> Link: https://patch.msgid.link/20261002125237.82188-1-matuszpd@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
8 daysMerge tag 'asoc-fix-v7.3-rc5' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v7.3 A bigger collection of fixes than usual due to your vacation but nothing hugely remarkable here, just fairly standard quirks and driver specific bugfixes.
8 daysALSA: ice1712: Fix the error handling via auto-cleanup at probeTakashi Iwai
We used the auto-cleanup via snd_card_unref() for errors at probe of ice1712 driver, but this may be problematic in a subtle way when an error happens at snd_card_register(); since snd_card_unref() skips the snd_card_disconnect() call, it may miss some resource clearance. For fixing the issue, use the new __free(snd_card_free) instead, which does call snd_card_free() explicitly at errors for avoiding such a pitfall. Fixes: d736eba9c453 ("ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup") Link: https://patch.msgid.link/20261001151039.592033-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
9 daysALSA: hda/realtek: Add ALC235 support for headset modeZeyu Li
The ALC235 (0x10ec0235) is registered as the ALC255 codec variant in patch_alc269(), but the headset mode functions were missing a case for it, so the CTIA/OMTP jack type detection and routing never ran on this codec. As a result, a plugged-in headset is detected (jack presence works) but the microphone signal is never routed, leaving the capture stream permanently silent. Verified on an ASUS M5451GA laptop (HDA:10ec0235,10431814): with the ALC255 coef sequence applied, the headset microphone works correctly. Signed-off-by: Zeyu Li <13776528859@163.com> Link: https://patch.msgid.link/20260926140336.27896-1-13776528859@163.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
9 daysALSA: hda/realtek: Add micmute LED quirk for Acer Swift SFG16-72Jakub Gawlik
The Acer Swift SFG16-72 (1025:173b) uses the ALC245 codec, but its mic-mute LED is not enabled by default. Apply the existing ALC245_FIXUP_ACER_MICMUTE_LED quirk to enable the mic-mute LED. Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Jakub Gawlik <jakubgawlik13@gmail.com> Link: https://patch.msgid.link/20260930145839.374762-1-jakubgawlik13@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
10 daysALSA: hda/realtek: Fix mute and micmute LEDs on HP ENVY x360 15-ey0xxxHarrison Lucas
The HP ENVY x360 2-in-1 Laptop 15-ey0xxx (SSID 103c:8a31, ALC245 with CS35L41 I2C amps) currently only gets ALC287_FIXUP_CS35L41_I2C_2, so the mute and micmute LEDs on the keyboard never light up. On this machine the mute LED is driven by COEF 0x0b bits 2-3 and the micmute LED by GPIO 0x04 (active low), which is exactly what ALC245_FIXUP_HP_X360_MUTE_LEDS sets up. Switch the quirk to ALC287_FIXUP_CS35L41_I2C_2_HP_MUTE_LEDS, which keeps the CS35L41 setup and chains to that LED fixup. Verified by driving the COEF and GPIO values by hand with hda-verb, following Master Playback Switch and Mic ACP LED Capture Switch. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Harrison Lucas <tiiowsalt@gmail.com> Link: https://patch.msgid.link/20260929174348.167537-1-tiiowsalt@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
10 daysALSA: hda/realtek: Add mute LED quirk for HP Pavilion 14-dv1001TUrenpanpan
The HP Pavilion 14-dv1001TU (subsystem ID 103c:8987) uses a Realtek ALC287 codec. The mute LED on this machine is controlled by GPIO bit 0x10, which was verified via hda-verb, but the subsystem ID is missing from the quirk table. As a result, the ALC287_FIXUP_HP_GPIO_LED fixup that drives GPIO 0x10 is never applied and the mute LED stays off even though the associated LED class device toggles correctly. Add the missing SND_PCI_QUIRK entry to map this subsystem ID to ALC287_FIXUP_HP_GPIO_LED so the mute LED works as expected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221810 Signed-off-by: renpanpan <renpanpan@kylinos.cn> Link: https://patch.msgid.link/20260930065504.24151-1-rppxj178543@163.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
10 daysALSA: ctxfi: Fix silent playback on Titanium HD (SB1270)Harin Lee
Commit 4b490e0d103c ("ALSA: ctxfi: Add ADC helper functions for GPIO") moved the GPIO_DATA read into hw_adc_stop(), but the Titanium HD (SB1270) setup in hw_adc_init() uses the local data variable holding the GPIO_CTRL value. Writing this value to GPIO_DATA sets the output mute bits. Playback runs without errors, but the outputs stay muted. Re-read GPIO_DATA before setting the speed mode bits. Also, add the delay after writing the mode bits, as in the original sequence. On affected kernels, switching the output selection was reported to restore clean playback. Fixes: 4b490e0d103c ("ALSA: ctxfi: Add ADC helper functions for GPIO") Cc: stable@vger.kernel.org Reported-by: Dany Patoine <dany_patoine@hotmail.com> Closes: https://lore.kernel.org/linux-sound/DM6PR02MB5433A42E81FEFAC400DD1905EA8B2@DM6PR02MB5433.namprd02.prod.outlook.com/ Signed-off-by: Harin Lee <me@harin.net> Link: https://patch.msgid.link/20260930115824.739412-1-me@harin.net Signed-off-by: Takashi Iwai <tiwai@suse.de>
10 daysALSA: usb-audio: Apply IGNORE_CTL_ERROR quirk to all Audient devicesTakashi Iwai
Faaris reported a problem with Audient EVO4 device and it turned out to be a regression by the recent fix commit 87a6f2fa6e6c ("ALSA: usb-audio: Propagate write errors in generic mixer put callbacks"). It exhibited that the hardware gives errors at accessing the mixer unit 10 on certain channels, and the change above made it a fatal error. We had already a quirk for Audient iD14 to work around such errors from the mixer controls, and we can simply apply the same for EVO4. OTOH, it's highly possible that other Audient devices suffer from the same issue; they must be using similar firmware, after all. So, in this patch, we apply the quirk generically to all devices with the vendor ID Audient (2708), instead. Ignoring the control error isn't usually less critical than overreaction to the firmware misbehavior. Fixes: 87a6f2fa6e6c ("ALSA: usb-audio: Propagate write errors in generic mixer put callbacks") Reported-and-tested-by: Faaris Ansari <faarisansari@googlemail.com> Closes: https://lore.kernel.org/CANBVYRCL=8QdLxGg4S6qrahrFtwJxhv-aSGpW7-1S=+iOe4ZGA@mail.gmail.com Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20260929144132.1521617-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
10 daysALSA: usb-audio: Apply boot quirk for Behringer models genericallyTakashi Iwai
Jan reported that a few Behringer devices became broken since the recent optimization to avoid usb_string() call at probe time at the commit b364a0d23cae ("ALSA: usb-audio: Use strings in struct usb_dev for manufacturer & co"). Interestingly, the devices seem requiring the explicit descriptor read at probing time, and the optimization above dropped it. There is already a boot quirk for another model, Behringer CM1A (1397:1234), that adds a device descriptor read, and this seems working for them, too. As the quirk is safe and cheap, just apply the same boot quirk to all Behringer devices for avoiding the pitfall again. Fixes: b364a0d23cae ("ALSA: usb-audio: Use strings in struct usb_dev for manufacturer & co") Reported-by: Jan Lentfer <jan.lentfer@web.de> Closes: https://lore.kernel.org/e7087d42-5e74-4d85-b1c5-b11eff235d41@web.de Link: https://patch.msgid.link/20260929122938.1471867-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
11 daysASoC: codecs: lpass-wsa-macro: rewrite the interpolator volume after ↵Liviu Nicoara
enabling clocks Commit 902f497a1ff5 ("ASoC: codecs: lpass-wsa-macro: remove useless gain read/write sequence") removed the read and write of the digital volume register in wsa_macro_enable_interpolator(), on the grounds that writing back the value just read does nothing. The comment above it, "apply gain after int clk is enabled", was left in place. On the Dell XPS 13 9345 (X1E80100, four WSA8845 amplifiers on two WSA macros) the write does something: a volume change made while the path is idle does not take effect when playback starts. Lowering the digital volume from 81 to 63 with nothing playing, then playing a test tone, gave about the same level as before the change. With the rewrite restored, lowering it from 81 to 69 while idle played audibly quieter, and restoring 81 while idle brought the level back. Changes made during playback take effect with or without the rewrite. The register already holds the new value when this happens. Without the rewrite, after an idle change from 69 to 81, playback stayed at the old level while the register, read from the hardware through /dev/mem, held the new one (0xfd). Writing that same value back through /dev/mem brought the level up at once. This is the behaviour described in commit 46188db080bd ("ASoC: codecs: lpass-wsa-macro: fix compander volume hack"): "the volume registers still need to be written after enabling clocks in order for any prior updates to take effect." The value read comes from the register cache, so the write pushes the last requested volume to the hardware once its clock runs. Restore the rewrite in the interpolator's POST_PMU event only. The mix path event removed later in the same series is not brought back. Fixes: 902f497a1ff5 ("ASoC: codecs: lpass-wsa-macro: remove useless gain read/write sequence") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Liviu Nicoara <lnicoara@thinkoid.org> Reviewed-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260929115755.6096-1-lnicoara@thinkoid.org Signed-off-by: Mark Brown <broonie@kernel.org>
11 daysALSA: hda/realtek: Fix speakers on ASUS PM3406CHAMuhtasham Nawr al-Mahmud
The ASUS ExpertBook PM3406CHA uses an ALC256 codec with subsystem ID 1043:1664. On Linux boot, the internal speakers are silent even though playback is routed to the codec and the speaker pin is configured for output. The codec starts with coefficient 0x10 set to 0x1d20. Writing 0x7f20 to coefficient 0x10 immediately restores internal speaker output. This was reproduced on the affected hardware from a fresh boot using hda-verb. Reducing a larger initialization sequence showed that this coefficient write alone is sufficient; no GPIO, EAPD, pin-control, or other coefficient changes are required. After applying the coefficient in userspace, speaker output also remains functional across suspend and resume. Add a machine-specific HDA fixup that writes the required coefficient. The fixup has been compile-tested, but could not be boot-tested because the affected hardware is no longer available. Closes: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/2162718 Signed-off-by: Muhtasham Nawr al-Mahmud <muhtaseem2005@gmail.com> Link: https://patch.msgid.link/20260924144512.3989-1-muhtaseem2005@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
11 daysALSA: hda/realtek: Add quirk for HP Pavilion AiO 24 speakerZhang Heng
Add ALC225_FIXUP_HP_AIO_SPK to enable the internal speaker on HP Pavilion AiO 24 (103c:85ba). Link: https://bugzilla.kernel.org/show_bug.cgi?id=221691 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260929091109.400313-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
11 daysALSA: hda/realtek: Add mute LED quirk for HP Laptop 15-fd2xxxPreston Lam
The HP Laptop 15-fd2xxx (PCI SSID 103c:8e43, Realtek ALC236) has a speaker mute LED on the F5 key and a microphone mute LED on the F8 key. Neither lights up, because the model has no quirk entry and only the generic HP vendor fallback (ALC269_FIXUP_HP_MUTE_LED) is applied. Probing the codec with hda-verb showed how the LEDs are wired: - mute LED: COEF index 0x07, bit 0, on NID 0x20 (set = LED on) - mic mute LED: codec GPIO0, active low (driven low = LED on) Driving GPIO1 and GPIO2 did not light the mute LED. This wiring is exactly what the existing ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO fixup implements (COEF 0x07 bit 0 for the mute LED, GPIO0 with inverted polarity for the micmute LED), so use it for this model. The sibling HP Laptop 15-fd0xxx (103c:8dd7) already uses the same fixup. Tested on this machine running Ubuntu 7.0.0-34-generic (SOF driver, the quirk built into snd-hda-codec-alc269 from Ubuntu's 7.0.0-34.34 source tree): the hda::mute and hda::micmute LEDs are created, follow the Master mute state and the Dmic0 capture switch respectively, and the F5 and F8 keys toggle them correctly. Muting the microphone also silences the capture stream. The LEDs also kept the correct state across an s2idle suspend/resume cycle (speaker muted in one run, microphone in another) and still responded to mute changes afterwards; long suspends were not tested. The desktop session was SwayFX (wlroots) with PipeWire, which only changes the mute state through the normal mixer controls; no other desktop was tried. Not tested on a mainline kernel tree directly; the change is only the quirk table entry. AI assistance: this patch, the hardware analysis behind it (probing the codec with hda-verb and choosing the existing fixup) and this commit message were written by Claude Code (Anthropic, model claude-sonnet-5-5). The submitter ran the privileged commands and reboots and reported the LED behavior; Claude Code ran the tests and read the kernel logs. Assisted-by: Claude:claude-sonnet-5-5 Signed-off-by: Preston Lam <plamlam99@gmail.com> Link: https://patch.msgid.link/20260928231621.1672704-1-plamlam99@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
11 daysASoC: amd: acp-config: Add ACP70 DMI quirk for ASUS UM5406GAZhang Heng
Add ASUS Zenbook S14 UM5406GA (Strix Point, ACP 7.0) to acp70_acpi_flag_override_table so that the broken BIOS acp-audio-config-flag is ignored and the default SoundWire enumeration path is used. Without this, no ASoC machine driver matches and internal speakers/mic fail to probe. Reported-by: Jannick Tobler <business@jtobler.net> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222009 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260928083925.266471-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown <broonie@kernel.org>
11 daysALSA: hda/realtek: Add mute LED quirks for HP Pavilion 15-eh3174nw and HP ↵Bartosz Brom
Laptop 15-dw1xxx The HP Pavilion 15-eh3174nw with an ALC287 codec requires the ALC287_FIXUP_HP_GPIO_LED fixup for its mute LED to work correctly. Add subsystem ID 0x103c:0x8bc7 to the quirk table to apply the existing fixup. Tested on an HP Pavilion 15-eh3174nw; the mute LED now follows the speaker mute state. The HP Laptop 15-dw1xxx with an ALC236 codec requires the ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO fixup for its mute LED to work correctly. Add subsystem ID 0x103c:0x85f1 to the quirk table to apply the existing fixup. Tested on an HP Laptop 15-dw1xxx; the mute LED now follows the speaker mute state. Signed-off-by: Bartosz Brom <bartosz.brom06@gmail.com> Link: https://patch.msgid.link/20260928134335.1875-1-bartosz.brom06@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysASoC: Intel: Add quirk to block match table for Lenovo Yoga Slim 7Charles Keepax
A variant of the Lenovo Yoga Slim 7 exists on Lunar Lake that doesn't have a physical jack socket. Cirrus codecs still use match tables on LNL but the match table makes no distinction between a system with or without a jack. This leads to the system failing probe as the jack in the topology file is not matched by a DAI link as the machine driver is constructed. Add a new quirk to block using match tables for specific devices, and rely on function topologies which can handle this difference seamlessly. This is slightly preferred over moving everything to function topologies due to the lower chance of causing regressions on other systems. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260928105610.242687-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
12 daysALSA: hda/realtek: Add mute LED quirk for HP Victus 15-fb2xxxKrish Gulati
The HP Victus 15-fb2xxx (PCI SSID 103c:8c2f) with the ALC245 codec does not turn on the mute LED when audio is muted. Add a quirk entry to enable it. Reported-by: erph.briones27@gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=221946 Signed-off-by: Krish Gulati <krishgulati7@gmail.com> Tested-by: Raphael Briones <erph.briones27@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260921131728.8999-1-krishgulati7@gmail.com
12 daysALSA: hda/realtek: Add quirk for Acer Nitro AN515-45Zhang Heng
The Acer Nitro AN515-45 requires ALC2XX_FIXUP_HEADSET_MIC to make the headset microphone work properly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221925 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260921124450.639601-2-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: hda/realtek: Add quirk for Lenovo ThinkBook G8+Zhang Heng
Fix Bass Speaker volume control on Lenovo ThinkBook G8+ by adding quirk 17aa:38dc with ALC285_FIXUP_SPEAKER2_TO_DAC1. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221799 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260921124450.639601-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: hda/realtek - Add headset mode for Dell Pro QC1255Kailang Yang
It lost its headset microphone functionality, and this patch will restore it. Fixes: 97272a5704bf ("ALSA: hda/realtek - Fixed Headphone noise issue for Dell QCM1255") Signed-off-by: Kailang Yang <kailang@realtek.com> Link: https://lore.kernel.org/3c251e40a2944ae4ae479e4c2e4e63a4@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: hda/tegra: Re-enable SDO workaround for Tegra194Aaron Kling
This workaround was originally added for Tegra194, but no longer gets applied for it. Commit 615d43540043 ("ALSA: hda/tegra: fix tegra-hda on tegra30 soc") changed the guard to tegra30-hda, which worked because all affected archs had the fallback compatible. However, commit 7f0ea5acfc19 ("arm64: tegra: Use correct compatible string for Tegra194 HDA") removed the fallback compatible for Tegra194, causing this to break. Fixes: 7f0ea5acfc19 ("arm64: tegra: Use correct compatible string for Tegra194 HDA") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Link: https://patch.msgid.link/20260926-tegra194-hda-sdo-v1-1-f7a636a07a58@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysASoC: qcom: lpass-cpu: use DAI table index for playback constraintsZimeng Li
The DAI ID is a hardware port ID and is not necessarily the index of the corresponding entry in variant->dai_driver. When configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01, the probe code currently uses dai_id to index variant->dai_driver. This is incorrect for platforms where DAI IDs are sparse. For example, the IPQ806x MI2S DAI has ID 4 while it is the only entry in the DAI driver table. If that DAI is configured for QUAD01 and probe reaches this branch, the code writes beyond that single entry via dai_driver[4] instead of updating the DAI being processed. Use the loop index i when updating the current DAI's playback channel constraints, while retaining dai_id for indexing the hardware-port specific playback SD-line mode array. This fixes the incorrect DAI table access for platforms where the DAI ID does not match its position in the driver table. Fixes: c223f41c1a52 ("ASoC: qcom: Add four speaker support on MI2S secondary") Cc: stable@vger.kernel.org Signed-off-by: Zimeng Li <me@lizi.moe> Assisted-by: LLM-assisted source analysis Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260927010911.51980-1-me@lizi.moe Signed-off-by: Mark Brown <broonie@kernel.org>
12 daysALSA: caiaq: unregister the input device when probe failsNguyen Ngoc Thang
setup_card() registers the input device, whose name and phys point into struct snd_usb_caiaqdev, and then goes on to snd_card_register() and snd_usb_caiaq_control_init(). If either fails, snd_probe() calls snd_card_free(), which frees the device state but leaves the input device registered: card_free() only clears the pointer, and the input device is unregistered from snd_disconnect() alone. Reading its "uevent" attribute afterwards dereferences freed memory: BUG: KASAN: slab-use-after-free in string+0x4a9/0x4f0 Read of size 1 at addr ffff8880208f5043 by task caiaq/4967 add_uevent_var+0x183/0x3a0 input_dev_uevent+0x162/0x900 dev_uevent+0x2f1/0x870 uevent_show+0x1ca/0x3a0 ... Unregister the input device on the probe error path, as snd_disconnect() does. snd_usb_caiaq_input_disconnect() is a no-op when no input device was registered. Reproduced with a raw-gadget Audio Kontrol 1 and a temporary hack that makes snd_usb_caiaq_control_init() fail. Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Cc: stable@vger.kernel.org Reported-by: syzbot+2a123f6269da57ffefaa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2a123f6269da57ffefaa Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com> Link: https://patch.msgid.link/20260925170717.22462-1-ngocthang2710.1999@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: usb-audio: Add mixer mapping for MSI MAG B850M MORTAR WIFITomasz Bojanowski
The USB audio device 0db0:cc78 (Realtek ALC4080) on the MSI MAG B850M MORTAR WIFI motherboard exposes all playback controls as "PCM", which makes it hard to tell the outputs apart. Its mixer layout matches the one of the MSI MPG X570S Carbon Max Wifi (units 29, 30 and 32), so reuse msi_mpg_x570s_carbon_max_wifi_alc4080_map for this device too. With the mapping applied, the controls show up as "Speaker", "Front Headphone" and "IEC958". Tested with a patched snd-usb-audio module on a 7.2.7 kernel. Signed-off-by: Tomasz Bojanowski <tomasz@bojanowski.me> Link: https://patch.msgid.link/20260923184957.6687-1-tomasz@bojanowski.me Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: hda/realtek: Fix silent speaker on Higole F9BYu-Hsiang Tseng
The Higole F9B is an Alder Lake-N mini PC with a 7" touchscreen and an ALC269VC codec (subsystem ID 0x10ec111e). Its DMI strings are all "Default string", so the SSID is the only way to identify it. The internal speaker is silent out of the box. The generic parser assigns DAC 0x03 to the speaker pin 0x14 and DAC 0x02 to the headphone pin 0x15, but the speaker only reproduces what DAC 0x02 plays, whatever its connection selection says. Checked one path at a time, only the gain of DAC 0x02 and the mute of pin 0x14 change what comes out of the speaker. User space only knows the path it was told the speaker uses, so selecting the speaker turns the path that actually reaches it all the way down. Route both 0x14 and 0x15 through mixer 0x0c (DAC 0x02), which is what ALC290_FIXUP_MONO_SPEAKERS already does. Tested on the device: the speaker plays. Cc: <stable@vger.kernel.org> Assisted-by: LLM Signed-off-by: Yu-Hsiang Tseng <asas1asas200@gmail.com> Link: https://patch.msgid.link/20260923141344.1543158-1-asas1asas200@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: hda/realtek: Fix square wave output on ASUS Strix G615LRZhang Heng
ASUS ROG Strix G16 G615LR (PCI SSID 1043:3f20) outputs a loud full-scale square wave from internal speakers since the TAS2781 amplifier driver started loading. The quirk was using ALC287_FIXUP_TXNW2781_I2C which chains to the ThinkPad headset jack fixup, but this is an ASUS device that should use ALC287_FIXUP_TXNW2781_I2C_ASUS which chains to ALC294_FIXUP_ASUS_SPK for proper EAPD and pin configuration. Fixes: f7cede182c96 ("ALSA: hda/realtek: Add Asus quirk for TAS amplifiers") Cc: stable@vger.kernel.org Cc: Baojun Xu <baojun.xu@ti.com> Cc: Antheas Kapenekakis <lkml@antheas.dev> Reported-by: Aleksei Arsenev <alesharik4@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=222045 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260923121640.272509-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: hda/realtek: Add quirk for HP ENVY 13-aq1xxxTarun Noonemunthala
The HP ENVY Laptop 13-aq1xxx (PCI SSID 103c:86ad) uses an ALC285 codec with two speaker pairs: front (pin 0x14) and bottom (pin 0x17). The BIOS leaves pin 0x14 as [N/A] ("not connected"), so the generic parser never enables the front pair and only the bottom speakers are audible. The vendor driver (RTKVHD64.sys) programs that pin with the value 0x90170150 and runs the HP amplifier initialization, which is already implemented in the driver as ALC285_FIXUP_HP_GPIO_AMP_INIT. Add a board fixup that applies the pin configuration for 0x14 and chains to the existing amplifier init fixup. The pin value was recovered from the vendor driver's own configuration data. The patch and this changelog were prepared with an AI coding assistant (see the Assisted-by tag below); the change was reviewed and tested by the submitter on the affected machine. Tested on an HP ENVY 13-aq1xxx by rebuilding snd-hda-codec-alc269 from the Fedora 7.1.10 source and loading it: the codec now reports "line_outs=2 (0x14/0x17)", pin 0x14 comes up as an output (Pin-ctls 0x40) with its amplifier unmuted, and both speaker pairs play. Assisted-by: OpenCode:deepseek-v4.1-flash checkpatch Signed-off-by: Tarun Noonemunthala <ntarun2000@gmail.com> Link: https://patch.msgid.link/20260923094014.58867-1-ntarun2000@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: usb-audio: Add quirk flag for ASUS SupremeFX Hi-FiRoman Bolotov
The ASUS SupremeFX Hi-Fi (0b05:1826, 0b05:1827) does not survive USB autosuspend. After a suspend/resume cycle the firmware degrades: HID probes begin to fail and the descriptors it returns become corrupted, until the device stops responding entirely and needs a physical power cycle to recover. Add QUIRK_FLAG_DISABLE_AUTOSUSPEND for both product IDs. Verified on 7.2.6 through the quirk_flags module parameter, with no code change, and with the local udev rules that had been forcing power/control commented out, so the parameter was the only mechanism in play. Both IDs were passed as 0b05:1827:disable_autosuspend;0b05:1826:disable_autosuspend The device then stayed awake across 2.5 hours (runtime_suspended_time remained 0), survived a system suspend/resume cycle, and continued to work afterwards with no failed probes and no power cycle needed. Signed-off-by: Roman Bolotov <hadros@ikeepitoblique.com> Link: https://patch.msgid.link/20260923064527.434441-1-hadros@ikeepitoblique.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: hda/realtek: Add quirk for Lenovo ThinkBook 16p Gen 3 ARH (21EK)KIM MinWoo
The ThinkBook 16p Gen 3 ARH (SSID 17aa:3871) has a TI TAS2563 amplifier device on I2C, exposed by ACPI as INT8866, the same arrangement as the Yoga 7 14ARB7 (SSID 17aa:3870). Without a quirk, the codec falls back to the vendor-wide Lenovo quirk (ALC269_FIXUP_LENOVO_XPAD_ACPI), the amplifier is never bound, and the internal speakers stay silent while the headphone output works. Reuse the Yoga 7 14ARB7 fixup, which binds the INT8866 device as a side codec. ALC287_FIXUP_TAS2781_I2C does not work on this machine because it looks for a TIAS2781 device. Assisted-by: LLM Signed-off-by: KIM MinWoo <phrimm136@gmail.com> Link: https://patch.msgid.link/20260923013756.106033-1-phrimm136@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-ec1xxxLuis Banha
The mute LED on the HP Pavilion Gaming Laptop 15-ec1xxx (103c:87b2) does not work automatically. Add the ALC285_FIXUP_HP_MUTE_LED quirk to fix this behavior. Signed-off-by: Luis Banha <luisbanha26@gmail.com> Link: https://patch.msgid.link/20260921230105.16844-1-luisbanha26@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: hda/realtek: Limit internal mic boost on HP Pavilion 15 (103c:2164)Hernan Ganzo
The HP Pavilion 15 with the ALC3227 codec (SSID 103c:2164) exposes the full four-step internal mic boost on pin 0x12: nsteps=3 with stepsize=0x2f, that is 0, 12, 24 and 36 dB. Combined with the ADC capture gain of +30 dB the analogue cascade reaches 66 dB, and the internal microphone clips on the ambient noise of a quiet room; the upper two steps are unusable at any useful input level. This is the defect class ALC269_FIXUP_LIMIT_INT_MIC_BOOST exists for. The machine matches no SSID quirk and falls through to the pin table, which selects ALC269_FIXUP_HP_MUTE_LED_MIC1 through a pin signature shared with several other HP models. Add an SSID entry instead, using ALC269_FIXUP_LIMIT_INT_MIC_BOOST_MUTE_LED: the existing fixup that applies alc269_fixup_limit_int_mic_boost() and chains to the same mute LED fixup, as already done for 103c:218b. The boost becomes 0 or 12 dB and the LED handling is unchanged. Tested on the affected machine by selecting the same fixup through the model string (snd-hda-intel.model), which bypasses the SSID and pin tables, with the driver confirming the selection: snd_hda_codec_alc269 hdaudioC1D0: ALC3227: picked fixup limit-mic-boost (model specified) With that, Internal Mic Boost reports Limits 0 - 1 (0 or 12 dB) instead of 0 - 3 (0 to 36 dB), so alc269_fixup_limit_int_mic_boost() clamps this codec's internal mic pin as intended. Note that /proc/asound/card1/codec#0 keeps printing the unclamped hardware caps (nsteps=0x03): that file reads codec parameters uncached by design, while the fixup overrides the driver's cached parameter that the control is built from. This does not by itself make the default capture volume sane -- the remaining 12 dB on top of the +30 dB ADC gain is still hotter than this machine's usable operating point. It removes the two unusable steps from the hardware range, which is what a quirk of this class can do. Signed-off-by: Hernan Ganzo <gp@sneemgp.com> Link: https://patch.msgid.link/20260921205538.41192-1-gp@sneemgp.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: usb-audio: Add native DSD quirk for HiBy FC4Achilles Zhang
The HiBy FC4 with USB ID 32bb:0004 advertises its native DSD stream as UAC2 RAW_DATA with a 4-byte, 32-bit subslot. Without a quirk snd-usb-audio leaves this alternate setting as SNDRV_PCM_FORMAT_SPECIAL, so userspace cannot select a native DSD format. Mark the device with QUIRK_FLAG_DSD_RAW so the existing generic raw DSD handling exposes the stream as DSD_U32_BE. Tested on an FC4 at DSD256. With the quirk the playback alternate setting changes from SPECIAL to DSD_U32_BE and reports DOP=0, bitrev=0; native DSD256 playback works correctly. Signed-off-by: Achilles Zhang <bnqzzdf@gmail.com> Link: https://patch.msgid.link/20260921024344.391912-1-bnqzzdf@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: hda/realtek: Drop Yoga Pro 9 16IAH10 PCI SSID quirkMatt Barr
The PCI SSID quirk added for the Lenovo Yoga Pro 9 16IAH10 (PCI SSID 17aa:3846, codec SSID 17aa:3920) also matches every other machine that shares PCI SSID 17aa:3846. snd_hda_pick_fixup() tries all PCI SSID entries before it falls back to the codec SSID, so those machines now get ALC287_FIXUP_YOGA9_SPEAKER2_TO_DAC1 and never reach their own codec-SSID quirk. The Lenovo Legion Pro 7 16IRX8H (product 82WQ) is one such machine: PCI SSID 17aa:3846, codec SSID 17aa:3884. Before this quirk it picked ALC287_FIXUP_TAS2781_I2C via the 17aa:3884 codec SSID fallback and bound its TAS2781 amplifier. With it, the codec never binds the amplifier and the internal speakers are silent: snd_hda_codec_alc269 hdaudioC0D0: ALC287: picked fixup for PCI SSID 17aa:3846 versus, on a kernel without the quirk: snd_hda_codec_alc269 hdaudioC0D0: ALC287: picked fixup for codec SSID 17aa:3884 snd_hda_codec_alc269 hdaudioC0D0: bound i2c-TIAS2781:00 (ops tas2781_hda_comp_ops ...) Drop the PCI SSID entry. The Yoga Pro 9 16IAH10 has the same amplifier as the Yoga S990-16 (codec SSID 17aa:3920), so it still gets a fixup through the codec SSID fallback, using the existing 17aa:3920 entry. Switch that entry from ALC287_FIXUP_TXNW2781_I2C to ALC287_FIXUP_YOGA9_SPEAKER2_TO_DAC1, which applies the DAC routing fix and then chains to ALC287_FIXUP_TXNW2781_I2C, so the amplifier setup is unchanged. Fixes: 41d60cbfde10 ("ALSA: hda/realtek: Fix bass speaker DAC routing for Lenovo Yoga Pro 9 16IAH10") Link: https://bugzilla.kernel.org/show_bug.cgi?id=220540 Suggested-by: Zhang Heng <zhangheng@kylinos.cn> Signed-off-by: Matt Barr <matthewjaybarr@gmail.com> Link: https://patch.msgid.link/20260921214812.22139-1-matthewjaybarr@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: line6: reject oversized playback packetsXiang Mei
Each playback URB is handed a slice of out.buffer that is exactly LINE6_ISO_PACKETS * max_packet_size_out bytes, sized from the OUT endpoint, but the number of bytes written into that slice is never compared against it. submit_audio_out_urb() takes the frame count from prev_fsize, which audio_in_callback() derived from the *IN* endpoint's received packet length, and rescales it with the playback frame size; when prev_fsize is still zero it synthesizes a length from the sample rate instead. On a device declaring a large IN wMaxPacketSize and a small OUT wMaxPacketSize, the resulting memcpy(), or the memset() when the playback stream is idle, runs past its slice and, as the reproducer below shows, beyond the allocation. usb_submit_urb() is not a backstop. max_packet_size_out comes from usb_maxpacket(), which returns only the low 11 bits of wMaxPacketSize, while USB core validates a high-speed isochronous length against that base scaled by usb_endpoint_maxp_mult(). A length of up to three times the allocated slice is therefore accepted, and even a rejected URB is only rejected after the write. Reject a packet that does not fit the slice the driver allocated for it. Clamping it instead would silently shorten the capture-derived rate feedback and desynchronize the two streams. BUG: KASAN: slab-out-of-bounds in submit_audio_out_urb (sound/usb/line6/playback.c:229) Write of size 1024 at addr ffff888100bbd400 by task kworker/1:2/5002 Workqueue: events line6_startup_work Call Trace: __asan_memcpy (mm/kasan/shadow.c:106) submit_audio_out_urb (sound/usb/line6/playback.c:229) line6_submit_audio_out_all_urbs (sound/usb/line6/playback.c:291) line6_stream_start (sound/usb/line6/pcm.c:194) line6_pcm_acquire (sound/usb/line6/pcm.c:337) line6_startup_work (sound/usb/line6/driver.c:728) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address belongs to the object at ffff888100bbd400 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes inside of allocated 256-byte region [ffff888100bbd400, ffff888100bbd500) Cc: stable@vger.kernel.org Fixes: 7a0f55aeeb8f ("ALSA: line6: Support assymetrical in/out configurations") Reported-by: <co+be8fa7ea6f77fdce@bugs.sh> Assisted-by: LLM Signed-off-by: Xiang Mei <xmei5@asu.edu> Link: https://patch.msgid.link/20260918234014.1318325-1-xmei5@asu.edu Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 daysALSA: ua101: reject mismatched capture/playback packet sizesXiang Mei
detect_usb_format() cross-checks bSubframeSize, bBitResolution and tSamFreq between the capture and playback interfaces, but never relates the two endpoints' wMaxPacketSize and bNrChannels. Each playback URB gets a buffer of ua->playback.max_packet_bytes, while the number of bytes written into it is derived from the capture stream: capture_urb_complete() computes frames from the received capture packet and capture.frame_bytes, and start_usb_playback() and playback_work() multiply that by playback.frame_bytes. A device declaring a large capture wMaxPacketSize with few capture channels and a small playback wMaxPacketSize with many playback channels therefore memset()s and memcpy()s past the end of the playback buffer, in open() of the PCM node the driver registers during probe. usb_submit_urb() rejects the over-long iso_frame_desc[0].length with -EMSGSIZE, but only after the write. Reject such descriptors at probe time. Genuine UA-101/UA-1000 hardware declares proportional packet sizes and is unaffected. BUG: KASAN: slab-out-of-bounds in start_usb_playback (sound/usb/misc/ua101.c:586) Write of size 2048 at addr ffff8881098f3c00 by task exploit/5021 Call Trace: __asan_memset (mm/kasan/shadow.c:84) start_usb_playback (sound/usb/misc/ua101.c:586) playback_pcm_open (sound/usb/misc/ua101.c:679) snd_pcm_open_substream (sound/core/pcm_native.c:2829) snd_pcm_open (sound/core/pcm_native.c:2865 sound/core/pcm_native.c:2932) snd_pcm_playback_open (sound/core/pcm_native.c:2891) snd_open (sound/core/sound.c:166) chrdev_open (fs/char_dev.c:411) do_dentry_open (fs/open.c:996) vfs_open (fs/open.c:1101) path_openat (fs/namei.c:4837 fs/namei.c:5000) do_file_open (fs/namei.c:5029) do_sys_openat2 (fs/open.c:1417) __x64_sys_openat (fs/open.c:1423 fs/open.c:1439 fs/open.c:1434) do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address belongs to the object at ffff8881098f3c00 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 0 bytes inside of allocated 168-byte region [ffff8881098f3c00, ffff8881098f3ca8) Cc: stable@vger.kernel.org Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support") Reported-by: <co+24304d323d28f156@bugs.sh> Assisted-by: LLM Signed-off-by: Xiang Mei <xmei5@asu.edu> Link: https://patch.msgid.link/20260918225753.1278505-1-xmei5@asu.edu Signed-off-by: Takashi Iwai <tiwai@suse.de>