kernel/git/stable/linux.git/include/sound, branch linux-6.14.y

ALSA: pcm: Fix race of buffer access at PCM OSS layer

2025-05-29T09:14:02+00:00

commit 93a81ca0657758b607c3f4ba889ae806be9beb73 upstream. The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation. Reported-by: syzbot+32d4647f551007595173@syzkaller.appspotmail.com Closes: https://lore.kernel.org/68164d8e.050a0220.11da1b.0019.GAE@google.com Cc: Link: https://patch.msgid.link/20250516080817.20068-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ASoC: intel/sdw_utils: Add volume limit to cs35l56 speakers

2025-05-29T09:13:52+00:00

[ Upstream commit d5463e531c128ff1b141fdba2e13345cd50028a4 ] The volume control for cs35l56 speakers has a maximum gain of +12 dB. However, for many use cases, this can cause distorted audio, depending various factors, such as other signal-processing elements in the chain, for example if the audio passes through a gain control before reaching the amp or the signal path has been tuned for a particular maximum gain in the amp. In the case of systems which use the soc_sdw_* driver, audio will likely be distorted in all cases above 0 dB, therefore add a volume limit of 400, which is 0 dB maximum volume inside this driver. The volume limit should be applied to both soundwire and soundwire bridge configurations. Signed-off-by: Stefan Binding Link: https://patch.msgid.link/20250430103134.24579-3-sbinding@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ALSA: hda/realtek: Enable PC beep passthrough for HP EliteBook 855 G7

2025-05-29T09:12:59+00:00

[ Upstream commit aa85822c611aef7cd4dc17d27121d43e21bb82f0 ] PC speaker works well on this platform in BIOS and in Linux until sound card drivers are loaded. Then it stops working. There seems to be a beep generator node at 0x1a in this CODEC (ALC269_TYPE_ALC215) but it seems to be only connected to capture mixers at nodes 0x22 and 0x23. If I unmute the mixer input for 0x1a at node 0x23 and start recording from its "ALC285 Analog" capture device I can clearly hear beeps in that recording. So the beep generator is indeed working properly, however I wasn't able to figure out any way to connect it to speakers. However, the bits in the "Passthrough Control" register (0x36) seems to work at least partially: by zeroing "B" and "h" and setting "S" I can at least make the PIT PC speaker output appear either in this laptop speakers or headphones (depending on whether they are connected or not). There are some caveats, however: * If the CODEC gets runtime-suspended the beeps stop so it needs HDA beep device for keeping it awake during beeping. * If the beep generator node is generating any beep the PC beep passthrough seems to be temporarily inhibited, so the HDA beep device has to be prevented from using the actual beep generator node - but the beep device is still necessary due to the previous point. * In contrast with other platforms here beep amplification has to be disabled otherwise the beeps output are WAY louder than they were on pure BIOS setup. Unless someone (from Realtek probably) knows how to make the beep generator node output appear in speakers / headphones using PC beep passthrough seems to be the only way to make PC speaker beeping actually work on this platform. Signed-off-by: Maciej S. Szmigiero Acked-by: kailang@realtek.com Link: https://patch.msgid.link/7461f695b4daed80f2fc4b1463ead47f04f9ad05.1739741254.git.mail@maciej.szmigiero.name Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: ump: Fix a typo of snd_ump_stream_msg_device_info

2025-05-22T12:31:43+00:00

[ Upstream commit dd33993a9721ab1dae38bd37c9f665987d554239 ] s/devince/device/ It's used only internally, so no any behavior changes. Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing") Acked-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20250511141147.10246-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: ump: Fix buffer overflow at UMP SysEx message conversion

2025-05-09T07:55:59+00:00

[ Upstream commit 56f1f30e6795b890463d9b20b11e576adf5a2f77 ] The conversion function from MIDI 1.0 to UMP packet contains an internal buffer to keep the incoming MIDI bytes, and its size is 4, as it was supposed to be the max size for a MIDI1 UMP packet data. However, the implementation overlooked that SysEx is handled in a different format, and it can be up to 6 bytes, as found in do_convert_to_ump(). It leads eventually to a buffer overflow, and may corrupt the memory when a longer SysEx message is received. The fix is simply to extend the buffer size to 6 to fit with the SysEx UMP message. Fixes: 0b5288f5fe63 ("ALSA: ump: Add legacy raw MIDI support") Reported-by: Argusee Link: https://patch.msgid.link/20250429124845.25128-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ASoC: ops: Consistently treat platform_max as control value

2025-03-05T17:25:25+00:00

This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min"), and makes some additional related updates. There are two ways the platform_max could be interpreted; the maximum register value, or the maximum value the control can be set to. The patch moved from treating the value as a control value to a register one. When the patch was applied it was technically correct as snd_soc_limit_volume() also used the register interpretation. However, even then most of the other usages treated platform_max as a control value, and snd_soc_limit_volume() has since been updated to also do so in commit fb9ad24485087 ("ASoC: ops: add correct range check for limiting volume"). That patch however, missed updating snd_soc_put_volsw() back to the control interpretation, and fixing snd_soc_info_volsw_range(). The control interpretation makes more sense as limiting is typically done from the machine driver, so it is appropriate to use the customer facing representation rather than the internal codec representation. Update all the code to consistently use this interpretation of platform_max. Finally, also add some comments to the soc_mixer_control struct to hopefully avoid further patches switching between the two approaches. Fixes: fb9ad24485087 ("ASoC: ops: add correct range check for limiting volume") Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20250228151456.3703342-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown

ASoC: cs35l56: Prevent races when soft-resetting using SPI control

2025-02-25T15:06:58+00:00

When SPI is used for control, the driver must hold the SPI bus lock while issuing the sequence of writes to perform a soft reset. >From the time the driver writes the SYSTEM_RESET command until the driver does a write to terminate the reset, there must not be any activity on the SPI bus lines. If there is any SPI activity during the soft-reset, another soft-reset will be triggered. The state of the SPI chip select is irrelevant. A repeated soft-reset does not in itself cause any problems, and it is not an infinite loop. The problem is a race between these resets and the driver polling for boot completion. There is a time window between soft resets where the driver could read HALO_STATE as 2 (fully booted) while the chip is actually soft-resetting. Although this window is small, it is long enough that it is possible to hit it in normal operation. To prevent this race and ensure the chip really is fully booted, the driver calls spi_bus_lock() to prevent other activity while resetting. It then issues the SYSTEM_RESET mailbox command. After allowing sufficient time for reset to take effect, the driver issues a PING mailbox command, which will force completion of the full soft-reset sequence. The SPI bus lock can then be released. The mailbox is checked for any boot or wakeup response from the firmware, before the value in HALO_STATE will be trusted. This does not affect SoundWire or I2C control. Fixes: 8a731fd37f8b ("ASoC: cs35l56: Move utility functions to shared file") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20250225131843.113752-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown

Merge tag 'sound-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

2025-01-24T15:54:34+00:00

Pull sound updates from Takashi Iwai: "This was a relatively calm cycle, and most of changes are rather small device-specific fixes. Here are highlights: Core: - Further enhancements of ALSA rawmidi and sequencer APIs for MIDI 2.0 - compress-offload API extensions for ASRC support ASoC: - Allow clocking on each DAI in an audio graph card to be configured separately - Improved power management for Renesas RZ-SSI - KUnit testing for the Cirrus DSP framework - Memory to meory operation support for Freescale/NXP platforms - Support for pause operations in SOF - Support for Allwinner suinv F1C100s, Awinc AW88083, Realtek ALC5682I-VE HD- and USB-audio: - Add support for Focusrite Scarlett 4th Gen 16i16, 18i16, and 18i20 interfaces via new FCP driver - TAS2781 SPI HD-audio sub-codec support - Various device-specific quirks as usual" * tag 'sound-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (235 commits) ALSA: hda: tas2781-spi: Fix bogus error handling in tas2781_hda_spi_probe() ALSA: hda: tas2781-spi: Fix error code in tas2781_read_acpi() ALSA: hda: tas2781-spi: Delete some dead code ALSA: usb: fcp: Fix return code from poll ops ALSA: usb: fcp: Fix incorrect resp->opcode retrieval ALSA: usb: fcp: Fix meter_levels type to __le32 ALSA: hda/realtek: Enable Mute LED on HP Laptop 14s-fq1xxx ALSA: hda: tas2781-spi: Fix -Wsometimes-uninitialized in tasdevice_spi_switch_book() ALSA: ctxfi: Simplify dao_clear_{left,right}_input() functions ALSA: hda: tas2781-spi: select CRC32 instead of CRC32_SARWATE ALSA: usb: fcp: Fix hwdep read ops types ALSA: scarlett2: Add device_setup option to use FCP driver ALSA: FCP: Add Focusrite Control Protocol driver ALSA: hda/tas2781: Add tas2781 hda SPI driver ALSA: hda/realtek - Fixed headphone distorted sound on Acer Aspire A115-31 laptop ASoC: xilinx: xlnx_spdif: Simpify using devm_clk_get_enabled() ALSA: hda: Support for Ideapad hotkey mute LEDs ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83JX, 83MC and 83NM ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83LC ASoC: dapm: add support for preparing streams ...

Merge tag 'regmap-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

2025-01-22T16:57:52+00:00

Pull regmap updates from Mark Brown: "There's one big bit of work this time around, the addition of support for a greater range of MBQ access sizes to SoundWire devices together with support for deferred read/write. The MBQ register maps generally have variable register sizes, the variable regiseter size support allows them to be handled much more naturally within regmap with less open coding in drivers. The deferred read/write support avoids spurious errors when devices make use of a bus feature allowing them to indicate they're busy. These changes pull in a supporting SoundWire change, and there's an ASoC change building off the new code. The remainder of the changes are code cleanups" * tag 'regmap-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: sdw-mbq: Add support for SDCA deferred controls regmap: sdw-mbq: Add support for further MBQ register sizes ASoC: SDCA: Update list of entity_0 controls soundwire: SDCA: Add additional SDCA address macros regmap: regmap_multi_reg_read(): make register list const regmap: cache: rbtree: use krealloc_array() to replace krealloc() regmap: cache: mapple: use kmalloc_array() to replace kmalloc() regmap: place foo / 8 and foo % 8 closer to each other regmap: Use BITS_TO_BYTES() regmap: cache: Use BITS_TO_BYTES()

Merge tag 'asoc-v6.14' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

2025-01-20T15:15:07+00:00

ASoC: Updates for v6.14 This was quite a quiet release for what I imagine are holiday related reasons, the diffstat is dominated by some Cirrus Logic Kunit tests. There's the usual mix of small improvements and fixes, plus a few new drivers and features. The diffstat includes some DRM changes due to work on HDMI audio. - Allow clocking on each DAI in an audio graph card to be configured separately. - Improved power management for Renesas RZ-SSI. - KUnit testing for the Cirrus DSP framework. - Memory to meory operation support for Freescale/NXP platforms. - Support for pause operations in SOF. - Support for Allwinner suinv F1C100s, Awinc AW88083, Realtek ALC5682I-VE