- 05 Apr, 2022 2 commits
-
-
Colin Ian King authored
The variable i is being assigned a value that is never read, it is being re-assigned in the following for-loop. The assignment is redundant and can be removed. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20220405135412.199251-1-colin.i.king@gmail.comSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Robin Murphy authored
iommu_get_domain_for_dev() is already perfectly happy to return NULL if the given device has no IOMMU. Drop the unnecessary check in favour of just handling that condition appropriately. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/9b506b4a4fe8a7f40aa8bad1aafc82426cf3dd92.1649165210.git.robin.murphy@arm.comSigned-off-by:
-
- 30 Mar, 2022 4 commits
-
-
Takashi Iwai authored
syzbot caught a potential deadlock between the PCM runtime->buffer_mutex and the mm->mmap_lock. It was brought by the recent fix to cover the racy read/write and other ioctls, and in that commit, I overlooked a (hopefully only) corner case that may take the revert lock, namely, the OSS mmap. The OSS mmap operation exceptionally allows to re-configure the parameters inside the OSS mmap syscall, where mm->mmap_mutex is already held. Meanwhile, the copy_from/to_user calls at read/write operations also take the mm->mmap_lock internally, hence it may lead to a AB/BA deadlock. A similar problem was already seen in the past and we fixed it with a refcount (in commit b2483716). The former fix covered only the call paths with OSS read/write and OSS ioctls, while we need to cover the concurrent access via both ALSA and OSS APIs now. This patch addresses the problem above by replacing the buffer_mutex lock in the read/write operations with a refcount similar as we've used for OSS. The new field, runtime->buffer_accessing, keeps the number of concurrent read/write operations. Unlike the former buffer_mutex protection, this protects only around the copy_from/to_user() calls; the other codes are basically protected by the PCM stream lock. The refcount can be a negative, meaning blocked by the ioctls. If a negative value is seen, the read/write aborts with -EBUSY. In the ioctl side, OTOH, they check this refcount, too, and set to a negative value for blocking unless it's already being accessed. Reported-by: syzbot+6e5c88838328e99c7e1c@syzkaller.appspotmail.com Fixes: dca947d4 ("ALSA: pcm: Fix races among concurrent read/write and buffer changes") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/000000000000381a0d05db622a81@google.com Link: https://lore.kernel.org/r/20220330120903.4738-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Merge tag 'asoc-fix-v5.18' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.18 A few fixes that came in during the merge window, all fairly routine.
-
Mohan Kumar authored
There is a corner case with unsol event handling during codec runtime suspending state. When the codec runtime suspend call initiated, the codec->in_pm atomic variable would be 0, currently the codec runtime suspend function calls snd_hdac_enter_pm() which will just increments the codec->in_pm atomic variable. Consider unsol event happened just after this step and before snd_hdac_leave_pm() in the codec runtime suspend function. The snd_hdac_power_up_pm() in the unsol event flow in hdmi_present_sense_via_verbs() function would just increment the codec->in_pm atomic variable without calling pm_runtime_get_sync function. As codec runtime suspend flow is already in progress and in parallel unsol event is also accessing the codec verbs, as soon as codec suspend flow completes and clocks are switched off before completing the unsol event handling as both functions doesn't wait for each other. This will result in below errors [ 589.428020] tegra-hda 3510000.hda: azx_get_response timeout, switching to polling mode: last cmd=0x505f2f57 [ 589.428344] tegra-hda 3510000.hda: spurious response 0x80000074:0x5, last cmd=0x505f2f57 [ 589.428547] tegra-hda 3510000.hda: spurious response 0x80000065:0x5, last cmd=0x505f2f57 To avoid this, the unsol event flow should not perform any codec verb related operations during RPM_SUSPENDING state. Signed-off-by:
Mohan Kumar <mkumard@nvidia.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220329155940.26331-1-mkumard@nvidia.comSigned-off-by:
-
Kai-Heng Feng authored
Commit 5aec9891 ("ALSA: hda/realtek - ALC236 headset MIC recording issue") is to solve recording issue met on AL236, by matching codec variant ALC269_TYPE_ALC257 and ALC269_TYPE_ALC256. This match can be too broad and Mi Notebook Pro 2020 is broken by the patch. Instead, use codec ID to be narrow down the scope, in order to make ALC256 unaffected. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215484 Fixes: 5aec9891 ("ALSA: hda/realtek - ALC236 headset MIC recording issue") Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20220330061335.1015533-1-kai.heng.feng@canonical.comSigned-off-by:
-
- 28 Mar, 2022 6 commits
-
-
Vitaly Rodionov authored
Add 5 new Dolphin Systems, same configuration as older systems. Signed-off-by:
Vitaly Rodionov <vitalyr@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220328115614.15761-7-vitalyr@opensource.cirrus.comSigned-off-by:
-
Stefan Binding authored
For ESD reasons, all variants should now set HSBIAS_SENSE_EN. Signed-off-by:
Stefan Binding <sbinding@opensource.cirrus.com> Signed-off-by:
-
Stefan Binding authored
Added 15 new laptops, with 2 variants: Warlock MLK and Warlock MLK with Dual Mic The only difference between the variants, is the the dual Mic variants use a stereo DMIC. These variants do no use reduce volume (Full Scale Volume) Signed-off-by:
-
Stefan Binding authored
All current variants (Bullseye/Warlock/Cyborg) should be using reduced volume (-6dB) for better speaker protection. Refactor to make more explicit the meaning and setting of Full Scale Volume setting to avoid future confusion. Signed-off-by:
-
Stefan Binding authored
To ensure consistency, the quirk table should be re-ordered in ascending order [ a typo fix in the patch description by tiwai ] Signed-off-by:
-
Stefan Binding authored
Warlock/Bullseye Laptops have a mono DMIC, Cyborg uses a stereo DMIC, and the configuration should reflect this. Signed-off-by:
-
- 27 Mar, 2022 2 commits
-
-
Xiaomeng Tong authored
The bug is here: err = snd_card_cs423x_pnp(dev, card->private_data, pdev, cdev); The list iterator value 'cdev' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, use a new variable 'iter' as the list iterator, while use the original variable 'cdev' as a dedicated pointer to point to the found element. And snd_card_cs423x_pnp() itself has NULL check for cdev. Cc: stable@vger.kernel.org Fixes: c2b73d14 ("ALSA: cs4236: cs4232 and cs4236 driver merge to solve PnP BIOS detection") Signed-off-by:
Xiaomeng Tong <xiam0nd.tong@gmail.com> Link: https://lore.kernel.org/r/20220327060822.4735-1-xiam0nd.tong@gmail.comSigned-off-by:
-
Kai-Heng Feng authored
Lenovo P360 is another platform equipped with ALC897, and it needs ALC897_FIXUP_HEADSET_MIC_PIN quirk to make its headset mic work. Signed-off-by:
-
- 25 Mar, 2022 1 commit
-
-
Zheng Bin authored
If SND_SOC_SOF_PCI_DEV is n, bulding fails: sound/soc/sof/intel/pci-tng.o:(.data+0x1c0): undefined reference to `sof_pci_probe' sound/soc/sof/intel/pci-tng.o:(.data+0x1c8): undefined reference to `sof_pci_remove' sound/soc/sof/intel/pci-tng.o:(.data+0x1e0): undefined reference to `sof_pci_shutdown' sound/soc/sof/intel/pci-tng.o:(.data+0x290): undefined reference to `sof_pci_pm' Make SND_SOC_SOF_MERRIFIELD select SND_SOC_SOF_PCI_DEV to fix this. Fixes: 8d4ba1be ("ASoC: SOF: pci: split PCI into different drivers") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zheng Bin <zhengbin13@huawei.com> Acked-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220323092501.145879-1-zhengbin13@huawei.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
- 24 Mar, 2022 1 commit
-
-
Kai-Heng Feng authored
Zbook Fury 17 G9 requires the same ALC285_FIXUP_HP_GPIO_LED quirk to make its audio LEDs work. So apply the quirk, and make it the last one since it's an LED quirk. Fixes: 07bcab93 ("ALSA: hda/realtek: Add support for HP Laptops") Signed-off-by:
-
- 23 Mar, 2022 1 commit
-
-
Meng Tang authored
SND_SOC_DAIFMT_DSP_A: PCM delay 1 bit mode, L data MSB after FRM LRC SND_SOC_DAIFMT_DSP_B: PCM no delay mode, L data MSB during FRM LRC Fixes: 081068fd (ASoC: rockchip: add support for i2s-tdm controller) Signed-off-by:
Meng Tang <tangmeng@uniontech.com> Link: https://lore.kernel.org/r/20220318100146.23991-1-tangmeng@uniontech.comSigned-off-by:
-
- 22 Mar, 2022 7 commits
-
-
Matt Kramer authored
This fixes the near-silence of the headphone jack on the ALC256-based Samsung Galaxy Book Flex Alpha (NP730QCJ). The magic verbs were found through trial and error, using known ALC298 hacks as inspiration. The fixup is auto-enabled only when the NP730QCJ is detected. It can be manually enabled using model=alc256-samsung-headphone. Signed-off-by:
Matt Kramer <mccleetus@gmail.com> Link: https://lore.kernel.org/r/3168355.aeNJFYEL58@linusSigned-off-by:
-
Giacomo Guiduzzi authored
Tests 72 and 78 for ALSA in kselftest fail due to reading inconsistent values from some devices on a VirtualBox Virtual Machine using the snd_intel8x0 driver for the AC'97 Audio Controller device. Taking for example test number 72, this is what the test reports: "Surround Playback Volume.0 expected 1 but read 0, is_volatile 0" "Surround Playback Volume.1 expected 0 but read 1, is_volatile 0" These errors repeat for each value from 0 to 31. Taking a look at these error messages it is possible to notice that the written values are read back swapped. When the write is performed, these values are initially stored in an array used to sanity-check them and write them in the pcmreg array. To write them, the two one-byte values are packed together in a two-byte variable through bitwise operations: the first value is shifted left by one byte and the second value is stored in the right byte through a bitwise OR. When reading the values back, right shifts are performed to retrieve the previously stored bytes. These shifts are executed in the wrong order, thus reporting the values swapped as shown above. This patch fixes this mistake by reversing the read operations' order. Signed-off-by:
Giacomo Guiduzzi <guiduzzi.giacomo@gmail.com> Signed-off-by:
Paolo Valente <paolo.valente@linaro.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220322200653.15862-1-guiduzzi.giacomo@gmail.comSigned-off-by:
-
Takashi Iwai authored
snd_pcm_reset() is a non-atomic operation, and it's allowed to run during the PCM stream running. It implies that the manipulation of hw_ptr and other parameters might be racy. This patch adds the PCM stream lock at appropriate places in snd_pcm_*_reset() actions for covering that. Cc: <stable@vger.kernel.org> Reviewed-by:
Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220322171325.4355-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
We have no protection against concurrent PCM buffer preallocation changes via proc files, and it may potentially lead to UAF or some weird problem. This patch applies the PCM open_mutex to the proc write operation for avoiding the racy proc writes and the PCM stream open (and further operations). Cc: <stable@vger.kernel.org> Reviewed-by:
-
Takashi Iwai authored
Like the previous fixes to hw_params and hw_free ioctl races, we need to paper over the concurrent prepare ioctl calls against hw_params and hw_free, too. This patch implements the locking with the existing runtime->buffer_mutex for prepare ioctls. Unlike the previous case for snd_pcm_hw_hw_params() and snd_pcm_hw_free(), snd_pcm_prepare() is performed to the linked streams, hence the lock can't be applied simply on the top. For tracking the lock in each linked substream, we modify snd_pcm_action_group() slightly and apply the buffer_mutex for the case stream_lock=false (formerly there was no lock applied) there. Cc: <stable@vger.kernel.org> Reviewed-by:
-
Takashi Iwai authored
In the current PCM design, the read/write syscalls (as well as the equivalent ioctls) are allowed before the PCM stream is running, that is, at PCM PREPARED state. Meanwhile, we also allow to re-issue hw_params and hw_free ioctl calls at the PREPARED state that may change or free the buffers, too. The problem is that there is no protection against those mix-ups. This patch applies the previously introduced runtime->buffer_mutex to the read/write operations so that the concurrent hw_params or hw_free call can no longer interfere during the operation. The mutex is unlocked before scheduling, so we don't take it too long. Cc: <stable@vger.kernel.org> Reviewed-by:
-
Takashi Iwai authored
Currently we have neither proper check nor protection against the concurrent calls of PCM hw_params and hw_free ioctls, which may result in a UAF. Since the existing PCM stream lock can't be used for protecting the whole ioctl operations, we need a new mutex to protect those racy calls. This patch introduced a new mutex, runtime->buffer_mutex, and applies it to both hw_params and hw_free ioctl code paths. Along with it, the both functions are slightly modified (the mmap_count check is moved into the state-check block) for code simplicity. Reported-by:
Hu Jiahui <kirin.say@gmail.com> Cc: <stable@vger.kernel.org> Reviewed-by:
-
- 21 Mar, 2022 4 commits
-
-
Takashi Iwai authored
Merge tag 'asoc-v5.18' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Updates for v5.18 Quite a quiet release for ASoC, lots of work on drivers and platforms but nothing too groundbreaking but not much on the core itself: - Start of moving SoF to support multiple IPC mechanisms. - Use of NHLT ACPI table to reduce the amount of quirking required for Intel systems. - Some building blocks for use in forthcoming Intel AVS driver for legacy Intel DSP firmwares. - Support for AMD PDM, Atmel PDMC, Awinic AW8738, i.MX cards with TLV320AIC31xx, Intel machines with CS35L41 and ESSX8336, Mediatek MT8181 wideband bluetooth, nVidia Tegra234, Qualcomm SC7280, Renesas RZ/V2L, Texas Instruments TAS585M
-
Takashi Iwai authored
Pull 5.18 development branch Signed-off-by: -
Meng Tang authored
Today, hp_jack_event and mic_jack_event always return 0. However, snd_soc_dapm_disable_pin and snd_soc_dapm_enable_pin may return a non-zero value, this will cause the user who calling hp_jack_event and mic_jack_event don't know whether the operation was really successfully. Signed-off-by:
Shengjiu Wang <shengjiu.wang@gmail.com> Reviewed-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/20220321065754.18307-1-tangmeng@uniontech.comSigned-off-by:
-
Jiaxin Yu authored
Fixes the following build errors when mt6358 is configured as module: >> ERROR: modpost: "mt6358_set_mtkaif_protocol" >> [sound/soc/mediatek/mt8186/mt8186-mt6366-rt1019-rt5682s.ko] undefined! >> ERROR: modpost: "mt6358_set_mtkaif_protocol" >> [sound/soc/mediatek/mt8186/mt8186-mt6366-da7219-max98357.ko] undefined! Fixes: 6a8d4198 ("ASoC: mediatek: mt6358: add codec driver") Signed-off-by:
Jiaxin Yu <jiaxin.yu@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220319120325.11882-1-jiaxin.yu@mediatek.comSigned-off-by:
-
- 18 Mar, 2022 12 commits
-
-
Mark Brown authored
Merge series from Ranjani Sridharan <ranjani.sridharan@linux.intel.com>: This series is a continuation to the SOF IPC abstraction work to support the new IPC version introduced in the SOF firmware. It makes the top-level control IO, PCM and PM code IPC-agnostic. Other than the first patch, the rest are purely for abstraction and include no changes in functionality.
-
Codrin Ciubotariu authored
The correct property is 'microchip,mic-pos', not 'mchp,mic-pos', so replace all occurences of 'mchp,mic-pos' with 'microchip,mic-pos'. Fix a multi-line comment format while we are at it. Fixes: 50291652 ("ASoC: atmel: mchp-pdmc: add PDMC driver") Signed-off-by:
Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Link: https://lore.kernel.org/r/20220318092609.130901-1-codrin.ciubotariu@microchip.comSigned-off-by:
-
Nicolin Chen authored
Shengjiu has been actively working on latest FSL platforms and keeping upstream effort as well, while I have been working on other subsystem lately and cannot guarantee audio patch review in the near term. So replacing with him in the maintainer list. Signed-off-by:
Nicolin Chen <nicoleotsuka@gmail.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Acked-by:
-
Ranjani Sridharan authored
This will help make the code for getting the mclk and bclk IPC specific. Add the implementation for IPC3 as well. Signed-off-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by:
Rander Wang <rander.wang@intel.com> Reviewed-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220317175044.1752400-20-ranjani.sridharan@linux.intel.comSigned-off-by:
-
Ranjani Sridharan authored
Introduce two new ops, set_up_all_pipelines and tear_down_all_pipelines in struct ipc_tplg_ops and define these for IPC3. Signed-off-by:
Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by:
-
Ranjani Sridharan authored
This will be used in IPC3-specific code. Signed-off-by:
-
Ranjani Sridharan authored
Define the dai_link_fixup PCM op for IPC3 and use it Signed-off-by:
-
Ranjani Sridharan authored
Add the trigger PCM op for IPC3 and use it. Signed-off-by:
-
Ranjani Sridharan authored
Add the hw_params op for IPC3 and use it. Signed-off-by:
-
Ranjani Sridharan authored
Add the IPC3 PCM ops, define the hw_free op and modify all users to use the op. Signed-off-by:
-
Ranjani Sridharan authored
It will be used in IPC-specific code. Signed-off-by:
-
Ranjani Sridharan authored
Introduce the IPC-specific PCM ops that will be used to abstract the PCM related IPC's. Signed-off-by:
-
