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

[PATCH] Revert "ALSA: hda: Add support for Loongson 7A1000 controller"
by Tiezhu Yang 25 Aug '20

25 Aug '20

This reverts commit 61eee4a7fc40 ("ALSA: hda: Add support for Loongson 7A1000 controller"). With this patch, there exists the following error on the Loongson LS7A platform: [ 216.639938] rcu: INFO: rcu_preempt self-detected stall on CPU [ 216.645685] rcu: 0-....: (1 GPs behind) idle=d5a/1/0x4000000000000004 softirq=562/563 fqs=16476 [ 216.654565] (t=53772 jiffies g=-463 q=11976) [ 216.658923] NMI backtrace for cpu 0 [ 216.662417] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted 5.8.0+ #3 [ 216.668587] Hardware name: , BIOS [ 216.672174] Workqueue: events azx_probe_work [snd_hda_intel] [ 216.677829] Stack : 0000000000000000 0000000000000000 ffffffff95004ce0 d786f9efa2288403 [ 216.685848] d786f9efa2288403 0000000000000000 98000001102638c8 ffffffff80cee270 [ 216.693866] 0000000000000000 0000000000000000 0000000000000000 00000000000002b4 [ 216.701883] 206b726f775f6562 0000000000000001 0000000000000000 ffffffff80f30000 [ 216.709902] ffffffff80f30000 ffffffff80d90000 0000000000000000 0000000000000000 [ 216.717919] 0000000000000000 0000000000000000 0000000000000000 ffffffff80d90000 [ 216.725937] ffffffff80d90000 0000000000000007 ffffffff806aff18 0000000000000000 [ 216.733955] ffffffff80f00000 9800000110cc4000 98000001102638c0 ffffffff80d9db80 [ 216.741974] ffffffff8065a740 0000000000000000 0000000000000000 0000000000000000 [ 216.749991] 000073746e657665 0000000000000000 ffffffff80211a64 d786f9efa2288403 [ 216.758009] ... [ 216.760464] Call Trace: [ 216.762920] [<ffffffff80211a64>] show_stack+0x9c/0x130 [ 216.768058] [<ffffffff8065a740>] dump_stack+0xb0/0xf0 [ 216.773110] [<ffffffff80665774>] nmi_cpu_backtrace+0x134/0x140 [ 216.778939] [<ffffffff80665910>] nmi_trigger_cpumask_backtrace+0x190/0x200 [ 216.785805] [<ffffffff802b1abc>] rcu_dump_cpu_stacks+0x12c/0x190 [ 216.791806] [<ffffffff802b08cc>] rcu_sched_clock_irq+0xa2c/0xfc8 [ 216.797808] [<ffffffff802b91d4>] update_process_times+0x2c/0xb8 [ 216.803724] [<ffffffff802cad80>] tick_sched_timer+0x40/0xb8 [ 216.809293] [<ffffffff802ba5f0>] __hrtimer_run_queues+0x118/0x1d0 [ 216.815380] [<ffffffff802bab74>] hrtimer_interrupt+0x12c/0x2d8 [ 216.821208] [<ffffffff8021547c>] c0_compare_interrupt+0x74/0xa0 [ 216.827124] [<ffffffff80296bd0>] __handle_irq_event_percpu+0xa8/0x198 [ 216.833558] [<ffffffff80296cf0>] handle_irq_event_percpu+0x30/0x90 [ 216.839732] [<ffffffff8029d958>] handle_percpu_irq+0x88/0xb8 [ 216.845388] [<ffffffff80296124>] generic_handle_irq+0x44/0x60 [ 216.851131] [<ffffffff80b3cfd0>] do_IRQ+0x18/0x28 [ 216.855838] [<ffffffff8067ace4>] plat_irq_dispatch+0x64/0x100 [ 216.861579] [<ffffffff80209a20>] handle_int+0x140/0x14c [ 216.866802] [<ffffffff802402e8>] irq_exit+0xf8/0x100 This is because AZX_DRIVER_GENERIC can not work well for Loongson LS7A HDA controller, it needs some workarounds which are not merged into the upstream kernel, so it should revert this patch now. There will be a better solution that has been tested carefully to support Loongson LS7A HDA controller. Fixes: 61eee4a7fc40 ("ALSA: hda: Add support for Loongson 7A1000 controller") Cc: <stable(a)vger.kernel.org> # 5.9-rc1+ Signed-off-by: Tiezhu Yang <yangtiezhu(a)loongson.cn> --- sound/pci/hda/hda_intel.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index e34a4d5..0f86e37 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2745,8 +2745,6 @@ static const struct pci_device_id azx_ids[] = { .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_HDMI }, /* Zhaoxin */ { PCI_DEVICE(0x1d17, 0x3288), .driver_data = AZX_DRIVER_ZHAOXIN }, - /* Loongson */ - { PCI_DEVICE(0x0014, 0x7a07), .driver_data = AZX_DRIVER_GENERIC }, { 0, } }; MODULE_DEVICE_TABLE(pci, azx_ids); -- 2.1.0

2 2

[PATCH 0/2] Tegra HDA specific fixes
by Mohan Kumar 25 Aug '20

25 Aug '20

This series has the fix for - 2 Channel swapping issue for Tegra - WAKEEN programming to detect wake events. Mohan Kumar (2): ALSA: hda: Fix 2 channel swapping for Tegra ALSA: hda/tegra: Program WAKEEN register for Tegra sound/pci/hda/hda_tegra.c | 7 +++++++ sound/pci/hda/patch_hdmi.c | 5 +++++ 2 files changed, 12 insertions(+) -- 2.17.1

3 5

[PATCH] ALSA: ca0106: fix error code handling
by Tong Zhang 25 Aug '20

25 Aug '20

snd_ca0106_spi_write() returns 1 on error, snd_ca0106_pcm_power_dac() is returning the error code directly, and the caller is expecting an negative error code Signed-off-by: Tong Zhang <ztong0001(a)gmail.com> --- sound/pci/ca0106/ca0106_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/pci/ca0106/ca0106_main.c b/sound/pci/ca0106/ca0106_main.c index 70d775ff967e..c189f70c82cb 100644 --- a/sound/pci/ca0106/ca0106_main.c +++ b/sound/pci/ca0106/ca0106_main.c @@ -537,7 +537,8 @@ static int snd_ca0106_pcm_power_dac(struct snd_ca0106 *chip, int channel_id, else /* Power down */ chip->spi_dac_reg[reg] |= bit; - return snd_ca0106_spi_write(chip, chip->spi_dac_reg[reg]); + if (snd_ca0106_spi_write(chip, chip->spi_dac_reg[reg]) != 0) + return -ENXIO; } return 0; } -- 2.25.1

2 1

Re: [PATCH] dt-bindings: Whitespace clean-ups in schema files
by Wolfram Sang 25 Aug '20

25 Aug '20

On Wed, Aug 12, 2020 at 02:36:18PM -0600, Rob Herring wrote: > Clean-up incorrect indentation, extra spaces, long lines, and missing > EOF newline in schema files. Most of the clean-ups are for list > indentation which should always be 2 spaces more than the preceding > keyword. > > Found with yamllint (which I plan to integrate into the checks). > > Cc: linux-arm-kernel(a)lists.infradead.org > Cc: linux-clk(a)vger.kernel.org > Cc: dri-devel(a)lists.freedesktop.org > Cc: linux-spi(a)vger.kernel.org > Cc: linux-gpio(a)vger.kernel.org > Cc: linux-remoteproc(a)vger.kernel.org > Cc: linux-hwmon(a)vger.kernel.org > Cc: linux-i2c(a)vger.kernel.org > Cc: linux-fbdev(a)vger.kernel.org > Cc: linux-iio(a)vger.kernel.org > Cc: linux-input(a)vger.kernel.org > Cc: linux-pm(a)vger.kernel.org > Cc: linux-media(a)vger.kernel.org > Cc: alsa-devel(a)alsa-project.org > Cc: linux-mmc(a)vger.kernel.org > Cc: linux-mtd(a)lists.infradead.org > Cc: netdev(a)vger.kernel.org > Cc: linux-rtc(a)vger.kernel.org > Cc: linux-serial(a)vger.kernel.org > Cc: linux-usb(a)vger.kernel.org > Signed-off-by: Rob Herring <robh(a)kernel.org> I trust you guys in figuring out the details, so for touching I2C: Acked-by: Wolfram Sang <wsa(a)kernel.org>

1 0

pcm|dmaengine|imx-sdma race condition on i.MX6
by Richard Leitner 25 Aug '20

25 Aug '20

Hi, we've found a race condition with the PCM on the i.MX6 which results in an -EIO for the SNDRV_PCM_IOCTL_READI_FRAMES ioctl after an -EPIPE (XRUN). A possible reproduction may look like the following reduced call graph during a PCM capture: us -> ioctl(SNDRV_PCM_IOCTL_READI_FRAMES) - wait_for_avail() - schedule_timeout() -> snd_pcm_update_hw_ptr0() - snd_pcm_update_state: EPIPE (XRUN) - sdma_disable_channel_async() # get's scheduled away due to sleep us <- ioctl(SNDRV_PCM_IOCTL_READI_FRAMES) returns -EPIPE us -> ioctl(SNDRV_PCM_IOCTL_PREPARE) # as reaction to the EPIPE (XRUN) us -> ioctl(SNDRV_PCM_IOCTL_READI_FRAMES) # next try to capture frames - sdma_prep_dma_cyclic() - sdma_load_context() # not loaded as context_loaded is 1 - wait_for_avail() - schedule_timeout() # now the sdma_channel_terminate_work() comes back and sets # context_loaded = false and frees in vchan_dma_desc_free_list(). us <- ioctl returns -EIO (capture write error (DMA or IRQ trouble?)) What we have found out, based on our understanding: The dmaengine docu states that a dmaengine_terminate_async() must be followed by a dmaengine_synchronize(). However, in the pcm_dmaengine.c, only dmaengine_terminate_async() is called (for performance reasons and because it might be called from an interrupt handler). In our tests, we saw that the user-space immediately calls ioctl(SNDRV_PCM_IOCTL_PREPARE) as a handler for the happened xrun (previous ioctl(SNDRV_PCM_IOCTL_READI_FRAMES) returns with -EPIPE). In our case (imx-sdma.c), the terminate really happens asynchronously with a worker thread which is not awaited/synchronized by the ioctl(SNDRV_PCM_IOCTL_PREPARE) call. Since the syscall immediately enters an atomic context (snd_pcm_stream_lock_irq()), we are not able to flush the work of the termination worker from within the DMA context. This leads to an unterminated DMA getting re-initialized and then terminated. On the i.MX6 platform the problem is (if I got it correctly) that the sdma_channel_terminate_work() called after the -EPIPE gets scheduled away (for the 1-2ms sleep [1]). During that time the userspace already sends in the ioctl(SNDRV_PCM_IOCTL_PREPARE) and ioctl(SNDRV_PCM_IOCTL_READI_FRAMES). As none of them are anyhow synchronized to the terminate_worker the vchan_dma_desc_free_list() [2] and "sdmac->context_loaded = false;" [3] are executed during the wait_for_avail() [4] of the ioctl(SNDRV_PCM_IOCTL_READI_FRAMES). To make sure we identified the problem correctly we've tested to add a "dmaengine_synchronize()" before the snd_pcm_prepare() in [5]. This fixed the race condition in all our tests. (Before we were able to reproduce it in 100% of the test runs). Based on our understanding, there are two different points to ensure the termination: Either ensure that the termination is finished within the previous SNDRV_PCM_IOCTL_READI_FRAMES call (inside the DMA context) or finishing it in the SNDRV_PCM_IOCTL_PREPARE call (and all other applicable ioclts) before entering the atomic context (from the PCM context). We initially thought about implementing the first approach, basically splitting up the dma_device terminate_all operation into a sync (busy-wait) and a async one. This would align the operations with the DMAengine interface and would enable a sync termination variant from atomic contexts. However, we saw that the dma_free_attrs() function has a WARN_ON on irqs disabled, which would be the case for the sync variant. Side note: We found this issue on the current v5.4.y LTS branch, but it also affects v5.8.y. Any feedback or pointers how we may fix the problem are warmly welcome! If anything is unclear please just ask :-) regards; Richard Leitner Benjamin Bara [1]https://elixir.bootlin.com/linux/v5.8/source/drivers/dma/imx-sdma.c#L1066 [2]https://elixir.bootlin.com/linux/v5.8/source/drivers/dma/imx-sdma.c#L1071 [3]https://elixir.bootlin.com/linux/v5.8/source/drivers/dma/imx-sdma.c#L1072 [4]https://elixir.bootlin.com/linux/v5.8/source/sound/core/pcm_lib.c#L1825 [5]https://elixir.bootlin.com/linux/v5.8/source/sound/core/pcm_native.c#L3226

5 16

[PATCH 00/14] ASoC: Intel: machine driver updates for 5.10
by Pierre-Louis Bossart 24 Aug '20

24 Aug '20

This series updates the tables used to select SoundWire configurations for CometLake and TigerLake, and adds support for SDCA (SoundWire Device Class for Audio) codecs in the common machine driver. These codec drivers are still being tested on early silicon/boards and will be contributed at a later time. For TigerLake Chromebooks a new DMI quirk is added, as well as a means to override the topology names. A pm_runtime fix is also provided to deal with playback/capture dependencies with an amplifier w/ feedback. I also included a minor codec correction for the TGL amplifier. Bard Liao (5): ASoC: Intel: modify SoundWire version id in acpi match table ASoC: Intel: sof_sdw: check SoundWire version when matching codec ASoC: Intel: sof_sdw: rename id as part_id ASoC: Intel: sof_sdw: add rt711 rt1316 rt714 SDCA codec support. ASoC: Intel: sof_sdw: clean-up inclusion of header files Pierre-Louis Bossart (5): ASoC: Intel: soc-acpi: cnl: add support for rt5682 on SoundWire link2 ASoC: Intel: sof-soundwire: add support for rt5682 on link2 ASoC: Intel: soc-acpi: mirror CML and TGL configurations ASoC: Intel: soc-acpi: add support for SDCA boards ASoC: codecs: max98373-sdw: add missing test on resume Rander Wang (2): ASoC: Intel: tgl_max98373: fix a runtime pm issue in multi-thread case ASoC: Intel: sof_sdw: Add support for product Ripto Sathyanarayana Nujella (2): ASoC: Intel: sof_rt5682: override quirk data for tgl_max98373_rt5682 ASoC: SOF: Add topology filename override based on dmi data match sound/soc/codecs/max98373-sdw.c | 3 + sound/soc/intel/boards/Kconfig | 3 + sound/soc/intel/boards/Makefile | 7 +- sound/soc/intel/boards/sof_maxim_common.c | 7 +- sound/soc/intel/boards/sof_rt5682.c | 13 ++ sound/soc/intel/boards/sof_sdw.c | 98 +++++++--- sound/soc/intel/boards/sof_sdw_common.h | 22 ++- sound/soc/intel/boards/sof_sdw_dmic.c | 1 + sound/soc/intel/boards/sof_sdw_max98373.c | 2 + sound/soc/intel/boards/sof_sdw_rt1308.c | 2 + sound/soc/intel/boards/sof_sdw_rt1316.c | 113 ++++++++++++ sound/soc/intel/boards/sof_sdw_rt5682.c | 2 + sound/soc/intel/boards/sof_sdw_rt700.c | 2 + sound/soc/intel/boards/sof_sdw_rt711.c | 2 + sound/soc/intel/boards/sof_sdw_rt711_sdca.c | 174 ++++++++++++++++++ sound/soc/intel/boards/sof_sdw_rt715_sdca.c | 42 +++++ .../intel/common/soc-acpi-intel-cml-match.c | 79 +++++++- .../intel/common/soc-acpi-intel-cnl-match.c | 33 +++- .../intel/common/soc-acpi-intel-icl-match.c | 10 +- .../intel/common/soc-acpi-intel-tgl-match.c | 165 ++++++++++++++++- sound/soc/sof/intel/hda.c | 8 +- sound/soc/sof/sof-pci-dev.c | 24 +++ 22 files changed, 764 insertions(+), 48 deletions(-) create mode 100644 sound/soc/intel/boards/sof_sdw_rt1316.c create mode 100644 sound/soc/intel/boards/sof_sdw_rt711_sdca.c create mode 100644 sound/soc/intel/boards/sof_sdw_rt715_sdca.c base-commit: fcea8b023a5f06ea0180ae65b01520b0414ee325 -- 2.25.1

2 21

[PATCH AUTOSEL 4.19 11/21] ASoC: wm8994: Avoid attempts to read unreadable registers
by Sasha Levin 24 Aug '20

24 Aug '20

From: Sylwester Nawrocki <s.nawrocki(a)samsung.com> [ Upstream commit f082bb59b72039a2326ec1a44496899fb8aa6d0e ] The driver supports WM1811, WM8994, WM8958 devices but according to documentation and the regmap definitions the WM8958_DSP2_* registers are only available on WM8958. In current code these registers are being accessed as if they were available on all the three chips. When starting playback on WM1811 CODEC multiple errors like: "wm8994-codec wm8994-codec: ASoC: error at soc_component_read_no_lock on wm8994-codec: -5" can be seen, which is caused by attempts to read an unavailable WM8958_DSP2_PROGRAM register. The issue has been uncovered by recent commit "e2329ee ASoC: soc-component: add soc_component_err()". This patch adds a check in wm8958_aif_ev() callback so the DSP2 handling is only done for WM8958. Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> Acked-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> Link: https://lore.kernel.org/r/20200731173834.23832-1-s.nawrocki@samsung.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/codecs/wm8958-dsp2.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/soc/codecs/wm8958-dsp2.c b/sound/soc/codecs/wm8958-dsp2.c index 108e8bf42a346..f0a409504a13b 100644 --- a/sound/soc/codecs/wm8958-dsp2.c +++ b/sound/soc/codecs/wm8958-dsp2.c @@ -419,8 +419,12 @@ int wm8958_aif_ev(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event) { struct snd_soc_component *component = snd_soc_dapm_to_component(w->dapm); + struct wm8994 *control = dev_get_drvdata(component->dev->parent); int i; + if (control->type != WM8958) + return 0; + switch (event) { case SND_SOC_DAPM_POST_PMU: case SND_SOC_DAPM_PRE_PMU: -- 2.25.1

1 0

[PATCH AUTOSEL 5.4 22/38] ASoC: wm8994: Avoid attempts to read unreadable registers
by Sasha Levin 24 Aug '20

24 Aug '20

From: Sylwester Nawrocki <s.nawrocki(a)samsung.com> [ Upstream commit f082bb59b72039a2326ec1a44496899fb8aa6d0e ] The driver supports WM1811, WM8994, WM8958 devices but according to documentation and the regmap definitions the WM8958_DSP2_* registers are only available on WM8958. In current code these registers are being accessed as if they were available on all the three chips. When starting playback on WM1811 CODEC multiple errors like: "wm8994-codec wm8994-codec: ASoC: error at soc_component_read_no_lock on wm8994-codec: -5" can be seen, which is caused by attempts to read an unavailable WM8958_DSP2_PROGRAM register. The issue has been uncovered by recent commit "e2329ee ASoC: soc-component: add soc_component_err()". This patch adds a check in wm8958_aif_ev() callback so the DSP2 handling is only done for WM8958. Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> Acked-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> Link: https://lore.kernel.org/r/20200731173834.23832-1-s.nawrocki@samsung.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/codecs/wm8958-dsp2.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/soc/codecs/wm8958-dsp2.c b/sound/soc/codecs/wm8958-dsp2.c index 18535b326680a..04f23477039a5 100644 --- a/sound/soc/codecs/wm8958-dsp2.c +++ b/sound/soc/codecs/wm8958-dsp2.c @@ -416,8 +416,12 @@ int wm8958_aif_ev(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event) { struct snd_soc_component *component = snd_soc_dapm_to_component(w->dapm); + struct wm8994 *control = dev_get_drvdata(component->dev->parent); int i; + if (control->type != WM8958) + return 0; + switch (event) { case SND_SOC_DAPM_POST_PMU: case SND_SOC_DAPM_PRE_PMU: -- 2.25.1

1 0

[PATCH AUTOSEL 5.4 20/38] ALSA: hda/realtek: Add model alc298-samsung-headphone
by Sasha Levin 24 Aug '20

24 Aug '20

From: Mike Pozulp <pozulp.kernel(a)gmail.com> [ Upstream commit 23dc958689449be85e39351a8c809c3d344b155b ] The very quiet and distorted headphone output bug that afflicted my Samsung Notebook 9 is appearing in many other Samsung laptops. Expose the quirk which fixed my laptop as a model so other users can try it. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207423 Signed-off-by: Mike Pozulp <pozulp.kernel(a)gmail.com> Link: https://lore.kernel.org/r/20200817043219.458889-1-pozulp.kernel@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 88629906f314c..e230909af980c 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7926,6 +7926,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = { {.id = ALC299_FIXUP_PREDATOR_SPK, .name = "predator-spk"}, {.id = ALC298_FIXUP_HUAWEI_MBX_STEREO, .name = "huawei-mbx-stereo"}, {.id = ALC256_FIXUP_MEDION_HEADSET_NO_PRESENCE, .name = "alc256-medion-headset"}, + {.id = ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, .name = "alc298-samsung-headphone"}, {} }; #define ALC225_STANDARD_PINS \ -- 2.25.1

1 0

[PATCH AUTOSEL 5.7 31/54] ALSA: usb-audio: ignore broken processing/extension unit
by Sasha Levin 24 Aug '20

24 Aug '20

From: Tom Yan <tom.ty89(a)gmail.com> [ Upstream commit d8d0db7bb358ef65d60726a61bfcd08eccff0bc0 ] Some devices have broken extension unit where getting current value doesn't work. Attempt that once when creating mixer control for it. If it fails, just ignore it, so that it won't cripple the device entirely (and/or make the error floods). Signed-off-by: Tom Yan <tom.ty89(a)gmail.com> Link: https://lore.kernel.org/r/5f3abc52.1c69fb81.9cf2.fe91@mx.google.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/usb/mixer.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index eab0fd4fd7c33..e0b7174c10430 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -2367,7 +2367,7 @@ static int build_audio_procunit(struct mixer_build *state, int unitid, int num_ins; struct usb_mixer_elem_info *cval; struct snd_kcontrol *kctl; - int i, err, nameid, type, len; + int i, err, nameid, type, len, val; const struct procunit_info *info; const struct procunit_value_info *valinfo; const struct usbmix_name_map *map; @@ -2470,6 +2470,12 @@ static int build_audio_procunit(struct mixer_build *state, int unitid, break; } + err = get_cur_ctl_value(cval, cval->control << 8, &val); + if (err < 0) { + usb_mixer_elem_info_free(cval); + return -EINVAL; + } + kctl = snd_ctl_new1(&mixer_procunit_ctl, cval); if (!kctl) { usb_mixer_elem_info_free(cval); -- 2.25.1

1 0