- Alsa-devel - mailman.alsa-project.org

[PATCH v2] ALSA: usb-mixer: us16x08: validate meter packet indices
by Shipei Qu 17 Dec '25

17 Dec '25

Hi, resending with a properly formatted diff (the previous email had a malformed patch header). The change itself is the same: while fuzzing a USB gadget that emulates a Tascam US-16x08 we found that get_meter_levels_from_urb() in mixer_us16x08.c uses a channel index taken directly from the 64-byte meter packet to index meter_level[], comp_level[] and master_level[] without any bounds checking. A malformed packet can therefore cause out-of-bounds writes in the snd_us16x08_meter_store. A malicious USB audio device (or USB gadget implementation) that pretends to be a US-16x08-compatible interface can trigger this by sending crafted meter packets. We have a small USB gadget-based PoC for this behaviour and can share it if that would be helpful. This driver is used by common distributions (e.g. Ubuntu) when a US-16x08 or compatible USB audio device is present. The same pattern is present in current mainline kernels. This issue was first reported via security(a)kernel.org. The kernel security team explained that, in the upstream threat model, USB endpoints are expected to be trusted (i.e. only trusted devices should be bound to drivers), so they consider this a normal bug rather than a security vulnerability, and asked us to send a fix to the development lists. The patch below adds simple range checks before updating these arrays. Reported-by: DARKNAVY (@DarkNavyOrg) <vr(a)darknavy.com> Signed-off-by: Shipei Qu <qu(a)darknavy.com> --- sound/usb/mixer_us16x08.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/sound/usb/mixer_us16x08.c b/sound/usb/mixer_us16x08.c index 1c5712c31..f9df40730 100644 --- a/sound/usb/mixer_us16x08.c +++ b/sound/usb/mixer_us16x08.c @@ -655,17 +655,25 @@ static void get_meter_levels_from_urb(int s, u8 *meter_urb) { int val = MUC2(meter_urb, s) + (MUC3(meter_urb, s) << 8); + int ch = MUB2(meter_urb, s) - 1; + + if (ch < 0) + return; if (MUA0(meter_urb, s) == 0x61 && MUA1(meter_urb, s) == 0x02 && MUA2(meter_urb, s) == 0x04 && MUB0(meter_urb, s) == 0x62) { - if (MUC0(meter_urb, s) == 0x72) - store->meter_level[MUB2(meter_urb, s) - 1] = val; - if (MUC0(meter_urb, s) == 0xb2) - store->comp_level[MUB2(meter_urb, s) - 1] = val; + if (ch < SND_US16X08_MAX_CHANNELS) { + if (MUC0(meter_urb, s) == 0x72) + store->meter_level[ch] = val; + if (MUC0(meter_urb, s) == 0xb2) + store->comp_level[ch] = val; + } } if (MUA0(meter_urb, s) == 0x61 && MUA1(meter_urb, s) == 0x02 && - MUA2(meter_urb, s) == 0x02 && MUB0(meter_urb, s) == 0x62) - store->master_level[MUB2(meter_urb, s) - 1] = val; + MUA2(meter_urb, s) == 0x02 && MUB0(meter_urb, s) == 0x62) { + if (ch < ARRAY_SIZE(store->master_level)) + store->master_level[ch] = val; + } } /* Function to retrieve current meter values from the device. -- 2.45.1

2 2

[PATCH v1] ASoC: amd: acp: Audio is not resuming after s0ix
by Raghavendra Prasad Mallela 17 Dec '25

17 Dec '25

From: Hemalatha Pinnamreddy <hemalatha.pinnamreddy2(a)amd.com> Audio fails to resume after system exits suspend mode due to accessing incorrect ring buffer address during resume. This patch resolves issue by selecting correct address based on the ACP version. Signed-off-by: Hemalatha Pinnamreddy <hemalatha.pinnamreddy2(a)amd.com> Signed-off-by: Raghavendra Prasad Mallela <raghavendraprasad.mallela(a)amd.com> --- sound/soc/amd/acp/acp-legacy-common.c | 32 +++++++++++++++++++++------ 1 file changed, 25 insertions(+), 7 deletions(-) diff --git a/sound/soc/amd/acp/acp-legacy-common.c b/sound/soc/amd/acp/acp-legacy-common.c index 3078f459e005..da80c761d657 100644 --- a/sound/soc/amd/acp/acp-legacy-common.c +++ b/sound/soc/amd/acp/acp-legacy-common.c @@ -208,7 +208,7 @@ static int set_acp_i2s_dma_fifo(struct snd_pcm_substream *substream, struct acp_resource *rsrc = chip->rsrc; struct acp_stream *stream = substream->runtime->private_data; u32 reg_dma_size, reg_fifo_size, reg_fifo_addr; - u32 phy_addr, acp_fifo_addr, ext_int_ctrl; + u32 phy_addr = 0, acp_fifo_addr, ext_int_ctrl; unsigned int dir = substream->stream; switch (dai->driver->id) { @@ -219,7 +219,10 @@ static int set_acp_i2s_dma_fifo(struct snd_pcm_substream *substream, SP_PB_FIFO_ADDR_OFFSET; reg_fifo_addr = ACP_I2S_TX_FIFOADDR(chip); reg_fifo_size = ACP_I2S_TX_FIFOSIZE(chip); - phy_addr = I2S_SP_TX_MEM_WINDOW_START + stream->reg_offset; + if (chip->acp_rev >= ACP70_PCI_ID) + phy_addr = ACP7x_I2S_SP_TX_MEM_WINDOW_START; + else + phy_addr = I2S_SP_TX_MEM_WINDOW_START + stream->reg_offset; writel(phy_addr, chip->base + ACP_I2S_TX_RINGBUFADDR(chip)); } else { reg_dma_size = ACP_I2S_RX_DMA_SIZE(chip); @@ -227,7 +230,10 @@ static int set_acp_i2s_dma_fifo(struct snd_pcm_substream *substream, SP_CAPT_FIFO_ADDR_OFFSET; reg_fifo_addr = ACP_I2S_RX_FIFOADDR(chip); reg_fifo_size = ACP_I2S_RX_FIFOSIZE(chip); - phy_addr = I2S_SP_RX_MEM_WINDOW_START + stream->reg_offset; + if (chip->acp_rev >= ACP70_PCI_ID) + phy_addr = ACP7x_I2S_SP_RX_MEM_WINDOW_START; + else + phy_addr = I2S_SP_RX_MEM_WINDOW_START + stream->reg_offset; writel(phy_addr, chip->base + ACP_I2S_RX_RINGBUFADDR(chip)); } break; @@ -238,7 +244,10 @@ static int set_acp_i2s_dma_fifo(struct snd_pcm_substream *substream, BT_PB_FIFO_ADDR_OFFSET; reg_fifo_addr = ACP_BT_TX_FIFOADDR(chip); reg_fifo_size = ACP_BT_TX_FIFOSIZE(chip); - phy_addr = I2S_BT_TX_MEM_WINDOW_START + stream->reg_offset; + if (chip->acp_rev >= ACP70_PCI_ID) + phy_addr = ACP7x_I2S_BT_TX_MEM_WINDOW_START; + else + phy_addr = I2S_BT_TX_MEM_WINDOW_START + stream->reg_offset; writel(phy_addr, chip->base + ACP_BT_TX_RINGBUFADDR(chip)); } else { reg_dma_size = ACP_BT_RX_DMA_SIZE(chip); @@ -246,7 +255,10 @@ static int set_acp_i2s_dma_fifo(struct snd_pcm_substream *substream, BT_CAPT_FIFO_ADDR_OFFSET; reg_fifo_addr = ACP_BT_RX_FIFOADDR(chip); reg_fifo_size = ACP_BT_RX_FIFOSIZE(chip); - phy_addr = I2S_BT_TX_MEM_WINDOW_START + stream->reg_offset; + if (chip->acp_rev >= ACP70_PCI_ID) + phy_addr = ACP7x_I2S_BT_RX_MEM_WINDOW_START; + else + phy_addr = I2S_BT_RX_MEM_WINDOW_START + stream->reg_offset; writel(phy_addr, chip->base + ACP_BT_RX_RINGBUFADDR(chip)); } break; @@ -257,7 +269,10 @@ static int set_acp_i2s_dma_fifo(struct snd_pcm_substream *substream, HS_PB_FIFO_ADDR_OFFSET; reg_fifo_addr = ACP_HS_TX_FIFOADDR; reg_fifo_size = ACP_HS_TX_FIFOSIZE; - phy_addr = I2S_HS_TX_MEM_WINDOW_START + stream->reg_offset; + if (chip->acp_rev >= ACP70_PCI_ID) + phy_addr = ACP7x_I2S_HS_TX_MEM_WINDOW_START; + else + phy_addr = I2S_HS_TX_MEM_WINDOW_START + stream->reg_offset; writel(phy_addr, chip->base + ACP_HS_TX_RINGBUFADDR); } else { reg_dma_size = ACP_HS_RX_DMA_SIZE; @@ -265,7 +280,10 @@ static int set_acp_i2s_dma_fifo(struct snd_pcm_substream *substream, HS_CAPT_FIFO_ADDR_OFFSET; reg_fifo_addr = ACP_HS_RX_FIFOADDR; reg_fifo_size = ACP_HS_RX_FIFOSIZE; - phy_addr = I2S_HS_RX_MEM_WINDOW_START + stream->reg_offset; + if (chip->acp_rev >= ACP70_PCI_ID) + phy_addr = ACP7x_I2S_HS_RX_MEM_WINDOW_START; + else + phy_addr = I2S_HS_RX_MEM_WINDOW_START + stream->reg_offset; writel(phy_addr, chip->base + ACP_HS_RX_RINGBUFADDR); } break; -- 2.17.1

5 4

[PATCH 1/3] ALSA: usb-audio: Update for native DSD support quirks
by Jussi Laako 17 Dec '25

17 Dec '25

Maintenance patch for native DSD support. Add set of missing device and vendor quirks; TEAC, Esoteric, Luxman and Musical Fidelity. Signed-off-by: Jussi Laako <jussi(a)sonarnerd.net> --- sound/usb/quirks.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index 61bd61ffb1b2..94a8fdc9c6d3 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -2230,6 +2230,12 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = { DEVICE_FLG(0x0644, 0x806b, /* TEAC UD-701 */ QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY | QUIRK_FLAG_IFACE_DELAY), + DEVICE_FLG(0x0644, 0x807d, /* TEAC UD-507 */ + QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY | + QUIRK_FLAG_IFACE_DELAY), + DEVICE_FLG(0x0644, 0x806c, /* Esoteric XD */ + QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY | + QUIRK_FLAG_IFACE_DELAY), DEVICE_FLG(0x06f8, 0xb000, /* Hercules DJ Console (Windows Edition) */ QUIRK_FLAG_IGNORE_CTL_ERROR), DEVICE_FLG(0x06f8, 0xd002, /* Hercules DJ Console (Macintosh Edition) */ @@ -2388,6 +2394,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = { QUIRK_FLAG_CTL_MSG_DELAY_1M), DEVICE_FLG(0x30be, 0x0101, /* Schiit Hel */ QUIRK_FLAG_IGNORE_CTL_ERROR), + DEVICE_FLG(0x3255, 0x0000, /* Luxman D-10X */ + QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY), DEVICE_FLG(0x339b, 0x3a07, /* Synaptics HONOR USB-C HEADSET */ QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE), DEVICE_FLG(0x413c, 0xa506, /* Dell AE515 sound bar */ @@ -2431,6 +2439,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = { QUIRK_FLAG_DSD_RAW), VENDOR_FLG(0x2622, /* IAG Limited devices */ QUIRK_FLAG_DSD_RAW), + VENDOR_FLG(0x2772, /* Musical Fidelity devices */ + QUIRK_FLAG_DSD_RAW), VENDOR_FLG(0x278b, /* Rotel? */ QUIRK_FLAG_DSD_RAW), VENDOR_FLG(0x292b, /* Gustard/Ess based devices */ -- 2.43.0

3 4

Behringer UMC404HD Line A/B volume too low when used in "Pro Audio" mode
by GitHub issues - edited 16 Dec '25

16 Dec '25

alsa-project/alsa-ucm-conf issue #662 was edited from mrbumpy409: The Behringer UMC404HD shows five volume faders in alsamixer: * **Line A** and **UMC404HD 192k Output Front**: These faders are linked (changing one changes the other) and control the level of **L & R MAIN OUT** and **PLAYBACK OUTPUT A 1/L & 2/R** on the back of the unit. * **Line B** and **UMC404HD 192k Output Back**: These faders are linked and control the level of **PLAYBACK OUTPUT B 3/L & 4/R**. * **UMC404HD 192k Output 1**: The primary volume control for the unit. How these sliders are used by Pipewire depends on the mode selected for the Behringer: * **Default**: Two output devices are presented to the user: - **UMC404HD 192k Line A**: Controls the "Line A" volume in alsamixer. - **UMC404HD 192k Line B**: Controls the "Line B" volume in alsamixer. - The "UMC404HD 192k Output 1" slider in alsamixer appears to be unused. * **Direct UMC404HD 192k**: One output device is presented to the user: - **Direct UMC404HD 192k**: Doesn't seem to be manipulating any of the hardware output levels in alsamixer. - The "Line A" and "Line B" channels are not available via Pipewire in this mode. * **Pro Audio**: One output device is presented to the user: - **UMC404HD 192k Pro**: Controls the "UMC404HD 192k Output 1" output level in alsamixer. - The "Line A" and "Line B" channels are not available via Pipewire in this mode. I would imagine most people are using a Behringer UMC404HD for recording purposes, and therefore would likely be using it in "Pro Audio" mode (or at least they should be if they care about latency). Since a recent update (Fedora 43 KDE), the levels of the "Line A" and "Line B" channels (and their linked pairs) are being set by default to **41**, which results in audio that is far too quiet when using the line outputs (headphone output is unaffected). Furthermore, these low levels throw off the balance between the computer's output and the UMC404HD's live input monitoring. "Line A" and "Line B" channels should both be at **100** by default to match the Windows driver (and previous ALSA version?) and provide correct balance with the live monitoring feature. Currently, I have to run alsamixer on every boot to adjust "Line A" and "Line B" to **100**. Am I right to report this to ALSA, or is this something Pipewire should be handling? Pipewire doesn't appear to touch the "Line A" or "Line B" levels at all when in "Pro Audio" mode, so I'd assume this is ALSA's doing, but I don't really know. ### My System * **OS:** Fedora Linux 43 Plasma Desktop Edition (Plasma Desktop 6.5.4, KDE Frameworks 6.21.0, Qt 6.10.1) * **Linux Kernel:** 6.17.11-300.fc43.x86_64 (64-bit) Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/662 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Behringer UMC404HD Line A/B volume too low when used in "Pro Audio" mode
by GitHub issues - opened 16 Dec '25

16 Dec '25

alsa-project/alsa-ucm-conf issue #662 was opened from mrbumpy409: The Behringer UMC404HD shows five volume faders in alsamixer: * **Line A** and **UMC404HD 192k Output Front**: These faders are linked (changing one changes the other) and control the level of **L & R MAIN OUT** and **PLAYBACK OUTPUT A 1/L & 2/R** on the back of the unit. * **Line B** and **UMC404HD 192k Output Back**: These faders are linked and control the level of **PLAYBACK OUTPUT B 3/L & 4/R**. * **UMC404HD 192k Output 1**: The primary volume control for the unit. How these sliders are used by Pipewire depends on the mode selected for the Behringer: * **Default**: Two output devices are presented to the user: - **UMC404HD 192k Line A**: Controls the "Line A" volume in alsamixer. - **UMC404HD 192k Line B**: Controls the "Line B" volume in alsamixer. - The "UMC404HD 192k Output 1" slider in alsamixer appears to be unused. * **Direct UMC404HD 192k**: One output device is presented to the user: - **Direct UMC404HD 192k**: Doesn't seem to be manipulating any of the hardware output levels in alsamixer. - The "Line A" and "Line B" channels are not available via Pipewire in this mode. * **Pro Audio**: One output device is presented to the user: - **UMC404HD 192k Pro**: Controls the "UMC404HD 192k Output 1" output level in alsamixer. - The "Line A" and "Line B" channels are not available via Pipewire in this mode. I would imagine most people are using a Behringer UMC404HD for recording purposes, and therefore would likely be using it in "Pro Audio" mode (or at least they should be if they care about latency). Since a recent update (Fedora 43 KDE), the levels of the "Line A" and "Line B" channels (and their linked pairs) are being set by default to **41**, which results in audio that is far too quiet when using the line outputs (headphone output is unaffected). Furthermore, these low levels throw off the balance between the computer's output and the UMC404HD's live input monitoring. "Line A" and "Line B" channels should both be at **100** by default to match the Windows driver (and previous ALSA version?) and provide correct balance with the live monitoring feature. Currently, I have to run alsamixer on every boot to adjust "Line A" and "Line B" to **100**. Am I right to report this to ALSA, or is this something Pipewire should be handling? Pipewire doesn't appear to touch the "Line A" or "Line B" levels at all when in "Pro Audio" mode, so I'd assume this is ALSA's doing, but I don't really know. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/662 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

alsa-lib 1.2.15: only fallback stereo available (bisected)
by GitHub issues - opened 16 Dec '25

16 Dec '25

alsa-project/alsa-lib issue #491 was opened from Just4GH: With alsa-lib 1.2.15 only stereo is available. ``` git bisect bad Bisecting: 0 revisions left to test after this (roughly 0 steps) [ eda76146c5653ff1d5bc4b4c53f7a2d5ccc17da2 ] conf: fix load_for_all_cards() - do not merge the card specific contents ``` Reverting eda76146c5653ff1d5bc4b4c53f7a2d5ccc17da2 allows the usual profiles to load and 5.1 output. ``` $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC1150 Analog [ALC1150 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 1: ALC1150 Digital [ALC1150 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 ``` Issue URL : https://github.com/alsa-project/alsa-lib/issues/491 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

aplay: add missing break before the default case
by GitHub pull_request - opened 16 Dec '25

16 Dec '25

alsa-project/alsa-utils pull request #315 was opened from bardliao: Add the break before the default case back. Otherwise, all cases will fall into the default/error case. Fixes: e78583ab7cde ("aplay: reorganize format handling in begin_wave()") Request URL : https://github.com/alsa-project/alsa-utils/pull/315 Patch URL : https://github.com/alsa-project/alsa-utils/pull/315.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

mixer: fix cache coherency issue in multi-application scenario
by GitHub pull_request - edited 16 Dec '25

16 Dec '25

alsa-project/alsa-lib pull request #490 was edited from DevreeseJorik: Remove conditional hardware writes in set_volume_ops and set_switch_ops to ensure hardware state is always updated. This fixes an issue where setting controls to the same value repeatedly does nothing, even if the hardware state has changed due to actions from other applications. --- Given this code has been in alsa-lib for 20 years, I assume there is a good reason for it, or perhaps a workaround exists that I could not find. The issue we faced is that after an initial write, if the same value is written again, but in the meantime a different application altered the hardware state, the new change will not occur, yet no error code is provided. Also, reading the current state returns the current application's state, rather than the actual hardware state. Is alsa-lib not designed with multi-application uses in mind? Request URL : https://github.com/alsa-project/alsa-lib/pull/490 Patch URL : https://github.com/alsa-project/alsa-lib/pull/490.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

mixer: fix cache coherency issue in multi-application scenario
by GitHub pull_request - opened 16 Dec '25

16 Dec '25

alsa-project/alsa-lib pull request #490 was opened from DevreeseJorik: Remove conditional hardware writes in set_volume_ops and set_switch_ops to ensure hardware state is always updated. This fixes an issue where setting controls to the same value repeatedly does nothing, even if the hardware state has changed due to actions from other applications. Request URL : https://github.com/alsa-project/alsa-lib/pull/490 Patch URL : https://github.com/alsa-project/alsa-lib/pull/490.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH v10 0/3] ASoC: rt5575: Add the codec driver for the ALC5575
by Oder Chiou 16 Dec '25

16 Dec '25

Hi all, This patch series adds support for the Realtek ALC5575 audio codec. Changes in v10: - Patch 1/3: - export of_find_spi_controller_by_node() - Patch 2/3: - remove realtek,rt5575-use-spi - add spi-parent for firmware-loading - Patch 3/3: - use of_find_spi_controller_by_node() to get the SPI controller and add the spi device for firmware-loading Changes in v9: - Patch 1/2: - modify the comment - change the compatible name to "realtek,rt5575-use-spi" - Patch 2/2: - remove the standalone rt5575_spi_driver module and integrate its functionality into the I2C driver - move the SPI firmware-loading function to rt5575-spi.c - use the match data to distinguish between w/wo flash - minor fixes - Link to v9: https://lore.kernel.org/all/20251211110130.2925541-1-oder_chiou@realtek.com/ Changes in v8: - Patch 1/2: - remove the variable rt5575_spi_ready - use the multiple compatible names to distinguish between w/wo flash - Patch 2/2: - add compatible enum "realtek,rt5575-with-spi" - Link to v8: https://lore.kernel.org/all/20251201105926.1714341-1-oder_chiou@realtek.com/ Changes in v7: - Patch 1/2: - add a caption for the tristates - remove the redundant enum of the SPI command - add the error log in the request firmware failure - change the function name rt5575_spi_fw_loaded to rt5575_fw_load_by_spi - minor fixes - Patch 2/2: - modify commit message - Link to v7: https://lore.kernel.org/all/20251121084112.743518-1-oder_chiou@realtek.com/ Changes in v6: - Patch 1/2: - modify commit message - add select SND_SOC_RT5575 to config SND_SOC_RT5575_SPI in the Kconfig - revise the boiler plate in the head of the file - sort the include files - use a structure to transfer the spi data - use the poll() related function instead the for-loop - revise the UUID to the private ID - minor fixes - Patch 2/2: - modify description - Link to v6: https://lore.kernel.org/all/20251031073245.3629060-1-oder_chiou@realtek.com/ Changes in v2 to v5: - Patch 1/2: - move the firmware to the subdirectory - remove the empty functions - remove the cache_type in the regmap_config - add the error log in the run firmware failure - Patch 2/2: - nothing - Link to v5: https://lore.kernel.org/all/20251015103404.3075684-1-oder_chiou@realtek.com/ Oder Chiou (3): spi: export of_find_spi_controller_by_node() ASoC: dt-bindings: realtek,rt5575: add support for ALC5575 ASoC: rt5575: Add the codec driver for the ALC5575 .../bindings/sound/realtek,rt5575.yaml | 61 +++ drivers/spi/spi.c | 3 +- include/linux/spi/spi.h | 11 + sound/soc/codecs/Kconfig | 10 + sound/soc/codecs/Makefile | 3 + sound/soc/codecs/rt5575-spi.c | 119 ++++++ sound/soc/codecs/rt5575-spi.h | 26 ++ sound/soc/codecs/rt5575.c | 359 ++++++++++++++++++ sound/soc/codecs/rt5575.h | 54 +++ 9 files changed, 645 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/sound/realtek,rt5575.yaml create mode 100644 sound/soc/codecs/rt5575-spi.c create mode 100644 sound/soc/codecs/rt5575-spi.h create mode 100644 sound/soc/codecs/rt5575.c create mode 100644 sound/soc/codecs/rt5575.h -- 2.52.0

1 3