- 16 Jan, 2020 1 commit
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v5.5-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.5 This is mostly driver specific fixes, plus an error handling fix in the core. There is a rather large diffstat for the stm32 SAI driver, this is a very large but mostly mechanical update which wraps every register access in the driver to allow a fix to the locking which avoids circular locks, the active change is much smaller and more reasonably sized.
-
- 15 Jan, 2020 1 commit
-
-
Takashi Iwai authored
snd_seq_info_timer_read() reads the information of the timer assigned for each queue, but it's done in a racy way which may lead to UAF as spotted by syzkaller. This patch applies the missing q->timer_mutex lock while accessing the timer object as well as a slight code change to adapt the standard coding style. Reported-by: syzbot+2b2ef983f973e5c40943@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200115203733.26530-1-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
- 14 Jan, 2020 1 commit
-
-
Johan Hovold authored
The altsetting sanity check in set_sync_ep_implicit_fb_quirk() was checking for there to be at least one altsetting but then went on to access the second one, which may not exist. This could lead to random slab data being used to initialise the sync endpoint in snd_usb_add_endpoint(). Fixes: c75a8a7a ("ALSA: snd-usb: add support for implicit feedback") Fixes: ca10a7eb ("ALSA: usb-audio: FT C400 sync playback EP to capture EP") Fixes: 5e35dc03 ("ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204") Fixes: 17f08b0d ("ALSA: usb-audio: add implicit fb quirk for Axe-Fx II") Fixes: 103e9625 ("ALSA: usb-audio: simplify set_sync_ep_implicit_fb_quirk") Cc: stable <stable@vger.kernel.org> # 3.5 Signed-off-by:
Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20200114083953.1106-1-johan@kernel.orgSigned-off-by:
-
- 13 Jan, 2020 10 commits
-
-
Stephan Gerhold authored
For some reason, attempting to route audio through QDSP6 on MSM8916 causes the RX interpolation path to get "stuck" after playing audio a few times. In this situation, the analog codec part is still working, but the RX path in the digital codec stops working, so you only hear the analog parts powering up. After a reboot everything works again. So far I was not able to reproduce the problem when using lpass-cpu. The downstream kernel driver avoids this by resetting the RX interpolation path after use. In mainline we do something similar for the TX decimator (LPASS_CDC_CLK_TX_RESET_B1_CTL), but the interpolator reset (LPASS_CDC_CLK_RX_RESET_CTL) got lost when the msm8916-wcd driver was split into analog and digital. Fix this problem by adding the reset to msm8916_wcd_digital_enable_interpolator(). Fixes: 150db8c5 ("ASoC: codecs: Add msm8916-wcd digital codec") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200105102753.83108-1-stephan@gerhold.netSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Stephan Gerhold authored
MIC BIAS Internal1 is broken at the moment because we always enable the internal rbias resistor to the TX2 line (connected to the headset microphone), rather than enabling the resistor connected to TX1. Move the RBIAS code to pm8916_wcd_analog_enable_micbias_int1/2() to fix this. Fixes: 585e881e ("ASoC: codecs: Add msm8916-wcd analog codec") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Yu-Hsuan Hsu authored
Add ACPI entry for cros_ec_codec. Signed-off-by:
Yu-Hsuan Hsu <yuhsuan@chromium.org> Link: https://lore.kernel.org/r/20200112054900.236576-1-yuhsuan@chromium.orgSigned-off-by:
-
Arnaud Pouliquen authored
Change mutex and spinlock management to avoid sleep in atomic issue. Signed-off-by:
Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200113100400.30472-1-arnaud.pouliquen@st.comSigned-off-by:
-
Stephan Gerhold authored
MIC BIAS External1 sets pm8916_wcd_analog_enable_micbias_ext1() as event handler, which ends up in pm8916_wcd_analog_enable_micbias_ext(). But pm8916_wcd_analog_enable_micbias_ext() only handles the POST_PMU event, which is not specified in the event flags for MIC BIAS External1. This means that the code in the event handler is never actually run. Set SND_SOC_DAPM_POST_PMU as the only event for the handler to fix this. Fixes: 585e881e ("ASoC: codecs: Add msm8916-wcd analog codec") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Kai Vehmanen authored
In case system has multiple HDA codecs, and codec probe fails for at least one but not all codecs, driver will end up cancelling a non-initialized timer context upon driver removal. Call trace of typical case: [ 60.593646] WARNING: CPU: 1 PID: 1147 at kernel/workqueue.c:3032 __flush_work+0x18b/0x1a0 [...] [ 60.593670] __cancel_work_timer+0x11f/0x1a0 [ 60.593673] hdac_hda_dev_remove+0x25/0x30 [snd_soc_hdac_hda] [ 60.593674] device_release_driver_internal+0xe0/0x1c0 [ 60.593675] bus_remove_device+0xd6/0x140 [ 60.593677] device_del+0x175/0x3e0 [ 60.593679] ? widget_tree_free.isra.7+0x90/0xb0 [snd_hda_core] [ 60.593680] snd_hdac_device_unregister+0x34/0x50 [snd_hda_core] [ 60.593682] snd_hdac_ext_bus_device_remove+0x2a/0x60 [snd_hda_ext_core] [ 60.593684] hda_dsp_remove+0x26/0x100 [snd_sof_intel_hda_common] [ 60.593686] snd_sof_device_remove+0x84/0xa0 [snd_sof] [ 60.593687] sof_pci_remove+0x10/0x30 [snd_sof_pci] [ 60.593689] pci_device_remove+0x36/0xb0 Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110235751.3404-9-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
Kai Vehmanen authored
In case system has multiple HDA controllers, it can happen that same HDA codec driver is used for codecs of multiple controllers. In this case, SOF may fail to probe the HDA driver and SOF initialization fails. SOF HDA code currently relies that a call to request_module() will also run device matching logic to attach driver to the codec instance. However if driver for another HDA controller was already loaded and it already loaded the HDA codec driver, this breaks current logic in SOF. In this case the request_module() SOF does becomes a no-op and HDA Codec driver is not attached to the codec instance sitting on the HDA bus SOF is controlling. Typical scenario would be a system with both external and internal GPUs, with driver of the external GPU loaded first. Fix this by adding similar logic as is used in legacy HDA driver where an explicit device_attach() call is done after request_module(). Also add logic to propagate errors reported by device_attach() back to caller. This also works in the case where drivers are not built as modules. Signed-off-by:
-
Bard liao authored
We will reinit DSP in a loop when it fails to initialize the first time, as recommended. So, it is not an error before we finally give up. And reorder the trace to make it more readable. Signed-off-by:
Bard liao <yung-chuan.liao@linux.intel.com> Signed-off-by:
-
Takashi Sakamoto authored
At failure of attempt to detect protocol extension, ALSA dice driver should be fallback to limited functionality. However it's not. This commit fixes it. Cc: <stable@vger.kernel.org> # v4.18+ Fixes: 58579c05 ("ALSA: dice: use extended protocol to detect available stream formats") Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200113084630.14305-2-o-takashi@sakamocchi.jpSigned-off-by:
-
Takashi Sakamoto authored
ALSA firewire-tascam driver can bring corruption due to spin lock without restoration of IRQ flag in SoftIRQ context. This commit fixes the bug. Cc: Scott Bahling <sbahling@suse.com> Cc: <stable@vger.kernel.org> # v4.21 Fixes: d7167422 ("ALSA: firewire-tascam: queue events for change of control surface") Signed-off-by:
-
- 11 Jan, 2020 1 commit
-
-
Takashi Iwai authored
We've got quite a few bug reports showing the SOF driver being loaded unintentionally recently, and the reason seems to be that users didn't know the module option change: with the recent kernel, a new option dsp_driver=1 has to be passed to a new module snd-intel-dspcfg instead of snd_hda_intel.dmic_detect=0 option. That is, actually there are two tricky things here: - We changed the whole detection in another module and another option semantics. - The existing option for skipping the DSP probe was also renamed. For avoiding the confusion and giving user more hint, this patch reverts the renamed option dsp_driver back to dmic_detect for snd-hda-intel module, and show the warning about the module option change when the non-default value is passed. Fixes: 82d9d54a ("ALSA: hda: add Intel DSP configuration / probe code") Link: https://lore.kernel.org/r/20200109082000.26729-1-tiwai@suse.deSigned-off-by:
-
- 10 Jan, 2020 1 commit
-
-
Olivier Moysan authored
In stm32_afsdm_pcm_cb function, the transfer size is provided in bytes. However, samples are copied as 16 bits words from iio buffer. Divide by two the transfer size, to copy the right number of samples. Fixes: 1e7f6e1c ("ASoC: stm32: dfsdm: add 16 bits audio record support") Signed-off-by:
Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20200110131131.3191-1-olivier.moysan@st.comSigned-off-by:
-
- 09 Jan, 2020 1 commit
-
-
Olivier Moysan authored
In current driver, locks can be taken as follows: - Register access: take a lock on regmap config and then on clock. - Master clock provider: take a lock on clock and then on regmap config. This can lead to the circular locking summarized below. Remove peripheral clock management through regmap framework, and manage peripheral clock in driver instead. On register access, lock on clock is taken first, which allows to avoid possible locking issue. [ 6696.561513] ====================================================== [ 6696.567670] WARNING: possible circular locking dependency detected [ 6696.573842] 4.19.49 #866 Not tainted [ 6696.577397] ------------------------------------------------------ [ 6696.583566] pulseaudio/6439 is trying to acquire lock: [ 6696.588697] 87b0a25b (enable_lock){..-.}, at: clk_enable_lock+0x64/0x128 [ 6696.595377] [ 6696.595377] but task is already holding lock: [ 6696.601197] d858f825 (stm32_sai_sub:1342:(sai->regmap_config)->lock){....} ... [ 6696.812513] Possible unsafe locking scenario: [ 6696.812513] [ 6696.818418] CPU0 CPU1 [ 6696.822935] ---- ---- [ 6696.827451] lock(stm32_sai_sub:1342:(sai->regmap_config)->lock); [ 6696.833618] lock(enable_lock); [ 6696.839350] lock(stm32_sai_sub:1342: (sai->regmap_config)->lock); [ 6696.848035] lock(enable_lock); Fixes: 03e78a24 ("ASoC: stm32: sai: add h7 support") Signed-off-by:
-
- 08 Jan, 2020 3 commits
-
-
Kai Vehmanen authored
This reverts commit 42ec336f ("ALSA: hda: Disable regmap internal locking"). Without regmap locking, there is a race between snd_hda_codec_amp_init() and PM callbacks issuing regcache_sync(). This was caught by following kernel warning trace: <4> [358.080081] WARNING: CPU: 2 PID: 4157 at drivers/base/regmap/regcache.c:498 regcache_cache_only+0xf5/0x130 [...] <4> [358.080148] Call Trace: <4> [358.080158] snd_hda_codec_amp_init+0x4e/0x100 [snd_hda_codec] <4> [358.080169] snd_hda_codec_amp_init_stereo+0x40/0x80 [snd_hda_codec] Suggested-by:
-
Kailang Yang authored
Add quirk to ALC285_FIXUP_SPEAKER2_TO_DAC1, which is the same fixup applied for X1 Carbon 7th gen in commit d2cd795c ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen"). Signed-off-by:
Kailang Yang <kailang@realtek.com> Reviewed-by:
Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Kailang Yang authored
Set EAPD control to verb control. Signed-off-by:
-
- 07 Jan, 2020 1 commit
-
-
Takashi Iwai authored
When an ASoC driver with pcm_destruct component ops is freed before the PCM object instantiation (e.g. deferring the probe), it hits an Oops at snd_soc_pcm_component_free() that calls the pcm_destruct ops unconditionally. Fix it by adding a NULL-check of rtd->pcm before calling callbacks. Fixes: c64bfc90 ("ASoC: soc-core: add new pcm_construct/pcm_destruct") Reported-by:
Matthias Brugger <matthias.bgg@gmail.com> Tested-by:
Ben Ho <ben.ho@mediatek.com> Signed-off-by:
-
- 06 Jan, 2020 3 commits
-
-
Hans de Goede authored
When a quirk for the Irbis NB41 netbook was added, to override the defaults for this device, I forgot to add/keep the BYT_CHT_ES8316_SSP0 part of the defaults, completely breaking audio on this netbook. This commit adds the BYT_CHT_ES8316_SSP0 flag to the Irbis NB41 netbook quirk, making audio work again. Cc: stable@vger.kernel.org Cc: russianneuromancer@ya.ru Fixes: aa2ba991 ("ASoC: Intel: bytcht_es8316: Add quirk for Irbis NB41 netbook") Reported-and-tested-by: russianneuromancer@ya.ru Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
Dmitry Osipenko authored
The rt5640->jack is NULL if jack is already disabled at the time of driver's module unloading. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20200106014707.11378-1-digetx@gmail.comSigned-off-by:
-
Takashi Iwai authored
Merge tag 'asoc-fix-v5.5-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.5 More fixes that have been collected, nothing super remarkable here - the few core fixes are mainly error handling related as are many of the driver fixes.
-
- 04 Jan, 2020 2 commits
-
-
Takashi Iwai authored
Bose Companion 5 (with USB ID 05a7:1020) doesn't seem supporting reading back the sample rate, so the existing quirk is needed. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206063 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200104110936.14288-1-tiwai@suse.deSigned-off-by:
-
Kailang Yang authored
Add ALCS1200A supported. It was similar as ALC900. Signed-off-by:
-
- 03 Jan, 2020 1 commit
-
-
Arnd Bergmann authored
On non-x86, the new driver results in a build failure: sound/soc/intel/boards/cml_rt1011_rt5682.c:14:10: fatal error: asm/cpu_device_id.h: No such file or directory The asm/cpu_device_id.h header is not actually needed here, so don't include it. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
-
- 30 Dec, 2019 1 commit
-
-
Chris Chiu authored
ASUS reported that there's an bass speaker in addition to internal speaker and it uses DAC 0x02. It was not enabled in the commit 436e2550 ("ALSA: hda/realtek - Enable internal speaker of ASUS UX431FLC") which only enables the amplifier and the front speaker. This commit enables the bass speaker on top of the aforementioned work to improve the acoustic experience. Fixes: 436e2550 ("ALSA: hda/realtek - Enable internal speaker of ASUS UX431FLC") Signed-off-by:
Chris Chiu <chiu@endlessm.com> Signed-off-by:
Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191230031118.95076-1-chiu@endlessm.comSigned-off-by:
-
- 29 Dec, 2019 1 commit
-
-
Takashi Iwai authored
Jia-Ju Bai reported a possible sleep-in-atomic scenario in the ice1724 driver with Infrasonic Quartet support code: namely, ice->set_rate callback gets called inside ice->reg_lock spinlock, while the callback in quartet.c holds ice->gpio_mutex. This patch fixes the invalid call: it simply moves the calls of ice->set_rate and ice->set_mclk callbacks outside the spinlock. Reported-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/5d43135e-73b9-a46a-2155-9e91d0dcdf83@gmail.com Link: https://lore.kernel.org/r/20191218192606.12866-1-tiwai@suse.deSigned-off-by:
-
- 27 Dec, 2019 1 commit
-
-
Kailang Yang authored
Dell has new platform which has dual speaker connecting. They want dual speaker which use same dac for output. Signed-off-by:
-
- 24 Dec, 2019 9 commits
-
-
Daniel Baluta authored
dsp_box is used to keep DSP initiated messages. The value of dsp_offset is set by the DSP with the first message, so we need a way to bootstrap it in order to get the first message. We do this by setting the correct default dsp_box offset which on i.MX8 is not zero. Very interesting is why it has worked until now. On i.MX8, DSP communicates with ARM core using a shared SDRAM memory area. Actually, there are two shared areas: * SDRAM0 - starting at 0x92400000, size 0x800000 * SDRAM1 - starting at 0x92C00000, size 0x800000 SDRAM0 keeps the data sections, starting with .rodata. By chance fw_ready structure was placed at the beginning of .rodata. dsp_box_base is defined as SDRAM0 + dsp_box_offset and it is placed at the beginning of SDRAM1 (dsp_box_offset should be 0x800000). But because it is zero initialized by default it points to SDRAM0 where by chance the fw_ready was placed in the SOF firmware. Anyhow, SOF commit 7466bee378dd811b ("clk: make freq arrays constant") fw_ready is no longer at the beginning of SDRAM0 and everything shows how lucky we were until now. Fix this by properly setting the default dsp_box offset. Fixes: 202acc56 ("ASoC: SOF: imx: Add i.MX8 HW support") Signed-off-by:Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by:
-
Dragos Tarcatu authored
remove_link() is currently calling snd_soc_remove_dai_link() after it has already freed the memory for the link name. But this is later read from snd_soc_get_pcm_runtime() causing a KASAN use-after-free warning. Reorder the cleanups to fix this issue. Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by:
Dragos Tarcatu <dragos_tarcatu@mentor.com> Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20191204210447.11701-4-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
Chuhong Yuan authored
The driver forgets to call pm_runtime_disable in probe failure and remove. Add the missed calls to fix it. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Acked-by:
Nicolin Chen <nicoleotsuka@gmail.com> Link: https://lore.kernel.org/r/20191203111303.12933-1-hslester96@gmail.comSigned-off-by:
-
Olivier Moysan authored
Changing input state in iec capture control is not safe, as the pin state may be changed concurrently by ASoC framework. Remove pin state handling in iec capture control. Note: This introduces a restriction on capture control, when pin sleep state is defined in device tree. In this case channel status can be captured only when an audio stream capture is active. Fixes: f68c2a68 ("ASoC: stm32: spdifrx: add power management") Signed-off-by:
-
Olivier Moysan authored
When snd_pcm_stop() is called in interrupt routine, substream context may have already been released. Add protection on substream context. Fixes: 03e4d5d5 ("ASoC: stm32: Add SPDIFRX support") Signed-off-by:
-
Olivier Moysan authored
In current spdifrx driver locks may be requested as follows: - request lock on iec capture control, when starting synchronization. - request lock in interrupt context, when spdifrx stop is called from IRQ handler. Take lock with IRQs disabled, to avoid the possible deadlock. Lockdep report: [ 74.278059] ================================ [ 74.282306] WARNING: inconsistent lock state [ 74.290120] -------------------------------- ... [ 74.314373] CPU0 [ 74.314377] ---- [ 74.314381] lock(&(&spdifrx->lock)->rlock); [ 74.314396] <Interrupt> [ 74.314400] lock(&(&spdifrx->lock)->rlock); Fixes: 03e4d5d5 ("ASoC: stm32: Add SPDIFRX support") Signed-off-by:
-
Takashi Iwai authored
The error path of soc_new_pcm_runtime() invokes soc_free_pcm_runtime() that may cause a few problems. First off, it calls list_del() for rtd->list that may not be initialized. Similarly, snd_soc_pcm_component_free() traverses over the component list that may not be initialized, either. Such access to the uninitialized list head would lead to either a BUG_ON() or a memory corruption. This patch fixes the access to uninitialized list heads by initializing the list heads properly at the beginning before those error paths. Signed-off-by:
-
Daniel Baluta authored
When converting a normal link to a DPCM link we need to set dpcm_playback / dpcm_capture otherwise playback/capture streams will not be created resulting in errors like this: [ 36.039111] sai1-wm8960-hifi: ASoC: no backend playback stream Fixes: a655de80 ("ASoC: core: Allow topology to override machine driver FE DAI link config") Signed-off-by:
-
Colin Ian King authored
The memory allocation failure check for priv->pd_dev is incorrectly pointer checking priv instead of priv->pd_dev. Fix this. Addresses-Coverity: ("Logically dead code") Fixes: 202acc56 ("ASoC: SOF: imx: Add i.MX8 HW support") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
- 23 Dec, 2019 1 commit
-
-
Takashi Iwai authored
Klaus Ethgen reported occasional high CPU usages in his system that seem caused by HD-audio driver. The perf output revealed that it's in the unsolicited event handling in the workqueue, and the problem seems triggered by some communication stall between the controller and the codec at the runtime or system resume. Actually a similar phenomenon was seen in the past for other Intel platforms, and we already applied the workaround to enforce sync-write for CORB/RIRB verbs for Skylake and newer chipsets (commit 2756d914 "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"). Fortunately, the same workaround is applicable to the old chipset, and the experiment showed the positive effect. Based on the experiment result, this patch enables the sync-write workaround for all Intel chipsets. The only reason I hesitated to apply this workaround was about the possibly slightly higher CPU usage. But if the lack of sync causes a much severer problem even for quite old chip, we should think this would be necessary for all Intel chips. Reported-by:
Klaus Ethgen <Klaus@ethgen.ch> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191223171833.GA17053@chua Link: https://lore.kernel.org/r/20191223221816.32572-1-tiwai@suse.deSigned-off-by:
-
- 21 Dec, 2019 1 commit
-
-
Alex Deucher authored
You can't use PCI_BASE_CLASS with pci_get_class(). This happens to work by luck on devices with PCI_CLASS_DISPLAY_VGA, but misses PCI_CLASS_DISPLAY_OTHER. Add a check for those as well. Fixes: 586bc4aa ("ALSA: hda/hdmi - fix vgaswitcheroo detection for AMD") Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20191221001702.1338587-1-alexander.deucher@amd.comSigned-off-by:
-
