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

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

[PATCH AUTOSEL 5.7 30/54] 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 ca42445b649d4..b471892d84778 100644 --- a/sound/soc/codecs/wm8958-dsp2.c +++ b/sound/soc/codecs/wm8958-dsp2.c @@ -412,8 +412,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.7 28/54] 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 313eecfb91b44..e2bb0b6986182 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.8 36/63] 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

[PATCH AUTOSEL 5.8 35/63] 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 ca42445b649d4..b471892d84778 100644 --- a/sound/soc/codecs/wm8958-dsp2.c +++ b/sound/soc/codecs/wm8958-dsp2.c @@ -412,8 +412,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