summaryrefslogtreecommitdiff
path: root/sound
AgeCommit message (Collapse)AuthorFilesLines
2022-04-08ASoC: codecs: rx-macro: fix accessing array out of bounds for enum typeSrinivas Kandagatla1-4/+4
[ Upstream commit bcfe5f76cc4051ea3f9eb5d2c8ea621641f290a5 ] Accessing enums using integer would result in array out of bounds access on platforms like aarch64 where sizeof(long) is 8 compared to enum size which is 4 bytes. Fixes: 4f692926f562 ("ASoC: codecs: lpass-rx-macro: add dapm widgets and route") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220222183212.11580-3-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08ASoC: codecs: rx-macro: fix accessing compander for auxSrinivas Kandagatla1-0/+4
[ Upstream commit 42c709c4e1ce4c136891530646c9abd5dff3524f ] AUX interpolator does not have compander, so check before accessing compander data for this. Without this checkan array of out bounds access will be made in comp_enabled[] array. Fixes: 4f692926f562 ("ASoC: codecs: lpass-rx-macro: add dapm widgets and route") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220222183212.11580-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08ASoC: simple-card-utils: Set sysclk on all componentsRobert Hancock1-0/+15
[ Upstream commit ce2f7b8d4290c22e462e465d1da38a1c113ae66a ] If an mclk-fs value was provided in the device tree configuration, the calculated MCLK was fed into the downstream codec DAI and CPU DAI, however set_sysclk was not being called on the platform device. Some platform devices such as the Xilinx Audio Formatter need to know the MCLK as well. Call snd_soc_component_set_sysclk on each component in the stream to set the proper sysclk value in addition to the existing call of snd_soc_dai_set_sysclk on the codec DAI and CPU DAI. This may end up resulting in redundant calls if one of the snd_soc_dai_set_sysclk calls ends up calling snd_soc_component_set_sysclk itself, but that isn't expected to cause any significant harm. Fixes: f48dcbb6d47d ("ASoC: simple-card-utils: share asoc_simple_hw_param()") Signed-off-by: Robert Hancock <robert.hancock@calian.com> Reviewed-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20220120195832.1742271-5-robert.hancock@calian.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08ASoC: xilinx: xlnx_formatter_pcm: Handle sysclk settingRobert Hancock1-0/+25
[ Upstream commit 1c5091fbe7e0d0804158200b7feac5123f7b4fbd ] This driver did not set the MM2S Fs Multiplier Register to the proper value for playback streams. This needs to be set to the sample rate to MCLK multiplier, or random stream underflows can occur on the downstream I2S transmitter. Store the sysclk value provided via the set_sysclk callback and use that in conjunction with the sample rate in the hw_params callback to calculate the proper value to set for this register. Fixes: 6f6c3c36f091 ("ASoC: xlnx: add pcm formatter platform driver") Signed-off-by: Robert Hancock <robert.hancock@calian.com> Link: https://lore.kernel.org/r/20220120195832.1742271-2-robert.hancock@calian.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08ASoC: codecs: Check for error pointer after calling devm_regmap_init_mmioJiasheng Jiang3-0/+6
[ Upstream commit aa505ecccf2ae7546e0e262d574e18a9241f3005 ] Since the potential failure of the devm_regmap_init_mmio(), it will return error pointer and be assigned to the regmap. Then the error pointer will be dereferenced. For example rx->regmap will be used in rx_macro_mclk_enable(). Therefore, it should be better to check it. Fixes: af3d54b99764 ("ASoC: codecs: lpass-rx-macro: add support for lpass rx macro") Fixes: c39667ddcfc5 ("ASoC: codecs: lpass-tx-macro: add support for lpass tx macro") Fixes: 809bcbcecebf ("ASoC: codecs: lpass-wsa-macro: Add support to WSA Macro") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Link: https://lore.kernel.org/r/20220121171031.2826198-1-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08ASoC: sh: rz-ssi: Drop calling rz_ssi_pio_recv() recursivelyLad Prabhakar1-33/+35
[ Upstream commit 6570f991582e32b7992601d0497c61962a2c5dcc ] Instead of recursively calling rz_ssi_pio_recv() use a while loop to read the samples from RX fifo. This also fixes an issue where the return value of rz_ssi_pio_recv() was ignored when called recursively. Fixes: 03e786bd4341 ("ASoC: sh: Add RZ/G2L SSIF-2 driver") Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20220110094711.8574-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08ASoC: SOF: Intel: Fix NULL ptr dereference when ENOMEMAmmar Faizi1-5/+6
commit b7fb0ae09009d076964afe4c1a2bde1ee2bd88a9 upstream. Do not call snd_dma_free_pages() when snd_dma_alloc_pages() returns -ENOMEM because it leads to a NULL pointer dereference bug. The dmesg says: [ T1387] sof-audio-pci-intel-tgl 0000:00:1f.3: error: memory alloc failed: -12 [ T1387] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ T1387] #PF: supervisor read access in kernel mode [ T1387] #PF: error_code(0x0000) - not-present page [ T1387] PGD 0 P4D 0 [ T1387] Oops: 0000 [#1] PREEMPT SMP NOPTI [ T1387] CPU: 6 PID: 1387 Comm: alsa-sink-HDA A Tainted: G W 5.17.0-rc4-superb-owl-00055-g80d47f5de5e3 [ T1387] Hardware name: HP HP Laptop 14s-dq2xxx/87FD, BIOS F.15 09/15/2021 [ T1387] RIP: 0010:dma_free_noncontiguous+0x37/0x80 [ T1387] Code: [... snip ...] [ T1387] RSP: 0000:ffffc90002b87770 EFLAGS: 00010246 [ T1387] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ T1387] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888101db30d0 [ T1387] RBP: 00000000fffffff4 R08: 0000000000000000 R09: 0000000000000000 [ T1387] R10: 0000000000000000 R11: ffffc90002b874d0 R12: 0000000000000001 [ T1387] R13: 0000000000058000 R14: ffff888105260c68 R15: ffff888105260828 [ T1387] FS: 00007f42e2ffd640(0000) GS:ffff888466b80000(0000) knlGS:0000000000000000 [ T1387] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ T1387] CR2: 0000000000000000 CR3: 000000014acf0003 CR4: 0000000000770ee0 [ T1387] PKRU: 55555554 [ T1387] Call Trace: [ T1387] <TASK> [ T1387] cl_stream_prepare+0x10a/0x120 [snd_sof_intel_hda_common 146addf995b9279ae7f509621078cccbe4f875e1] [... snip ...] [ T1387] </TASK> Cc: Daniel Baluta <daniel.baluta@nxp.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Keyon Jie <yang.jie@linux.intel.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Rander Wang <rander.wang@intel.com> Cc: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.com> Cc: sound-open-firmware@alsa-project.org Cc: alsa-devel@alsa-project.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # v5.2+ Fixes: d16046ffa6de040bf580a64d5f4d0aa18258a854 ("ASoC: SOF: Intel: Add Intel specific HDA firmware loader") Link: https://lore.kernel.org/lkml/20220224145124.15985-1-ammarfaizi2@gnuweeb.org/ # v1 Link: https://lore.kernel.org/lkml/20220224180850.34592-1-ammarfaizi2@gnuweeb.org/ # v2 Link: https://lore.kernel.org/lkml/20220224182818.40301-1-ammarfaizi2@gnuweeb.org/ # v3 Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org> Link: https://lore.kernel.org/r/20220224185836.44907-1-ammarfaizi2@gnuweeb.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08ALSA: hda/realtek: Fix audio regression on Mi Notebook Pro 2020Kai-Heng Feng1-2/+2
commit f30741cded62f87bb4b1cc58bc627f076abcaba8 upstream. Commit 5aec98913095 ("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: 5aec98913095 ("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.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lockTakashi Iwai3-11/+38
commit bc55cfd5718c7c23e5524582e9fa70b4d10f2433 upstream. 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 b248371628aa). 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: dca947d4d26d ("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.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08ALSA: hda: Avoid unsol event during RPM suspendingMohan Kumar1-1/+7
commit 6ddc2f749621d5d45ca03edc9f0616bcda136d29 upstream. 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.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08ALSA: cs4236: fix an incorrect NULL check on list iteratorXiaomeng Tong1-3/+5
commit 0112f822f8a6d8039c94e0bc9b264d7ffc5d4704 upstream. 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: c2b73d1458014 ("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.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: pci: fix reading of swapped values from pcmreg in AC97 codecGiacomo Guiduzzi1-2/+2
commit 17aaf0193392cb3451bf0ac75ba396ec4cbded6e upstream. 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.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: cmipci: Restore aux vol on suspend/resumeJonathan Teh1-2/+1
commit c14231cc04337c2c2a937db084af342ce704dbde upstream. Save and restore CM_REG_AUX_VOL instead of register 0x24 twice on suspend/resume. Tested on CMI8738LX. Fixes: cb60e5f5b2b1 ("[ALSA] cmipci - Add PM support") Signed-off-by: Jonathan Teh <jonathan.teh@outlook.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/DBAPR04MB7366CB3EA9C8521C35C56E8B920E9@DBAPR04MB7366.eurprd04.prod.outlook.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: usb-audio: Add mute TLV for playback volumes on RODE NT-USBLars-Peter Clausen1-3/+4
commit 0f306cca42fe879694fb5e2382748c43dc9e0196 upstream. For the RODE NT-USB the lowest Playback mixer volume setting mutes the audio output. But it is not reported as such causing e.g. PulseAudio to accidentally mute the device when selecting a low volume. Fix this by applying the existing quirk for this kind of issue when the device is detected. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220311201400.235892-1-lars@metafoo.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: pcm: Add stream lock during PCM reset ioctl operationsTakashi Iwai1-0/+4
commit 1f68915b2efd0d6bfd6e124aa63c94b3c69f127c upstream. 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.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: pcm: Fix races among concurrent prealloc proc writesTakashi Iwai1-4/+7
commit 69534c48ba8ce552ce383b3dfdb271ffe51820c3 upstream. 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: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220322170720.3529-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: pcm: Fix races among concurrent prepare and hw_params/hw_free callsTakashi Iwai1-14/+18
commit 3c3201f8c7bb77eb53b08a3ca8d9a4ddc500b4c0 upstream. 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: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220322170720.3529-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: pcm: Fix races among concurrent read/write and buffer changesTakashi Iwai1-0/+4
commit dca947d4d26dbf925a64a6cfb2ddbc035e831a3d upstream. 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: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220322170720.3529-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: pcm: Fix races among concurrent hw_params and hw_free callsTakashi Iwai2-22/+41
commit 92ee3c60ec9fe64404dc035e7c41277d74aa26cb upstream. 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: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220322170720.3529-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: hda/realtek: Add quirk for ASUS GA402Jason Zheng1-0/+1
commit b7557267c233b55d8e8d7ba4c68cf944fe2ec02c upstream. ASUS GA402 requires a workaround to manage the routing of its 4 speakers like the other ASUS models. Add a corresponding quirk entry to fix it. Signed-off-by: Jason Zheng <jasonzheng2004@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220313092216.29858-1-jasonzheng2004@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: hda/realtek - Fix headset mic problem for a HP machine with alc671huangwenhui1-0/+1
commit 882bd07f564f97fca6e42ce6ce627ce24ce1ef5a upstream. On a HP 288 Pro G8, the front mic could not be detected.In order to get it working, the pin configuration needs to be set correctly, and the ALC671_FIXUP_HP_HEADSET_MIC2 fixup needs to be applied. Signed-off-by: huangwenhui <huangwenhuia@uniontech.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220311093836.20754-1-huangwenhuia@uniontech.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: hda/realtek: Add quirk for Clevo NP50PNJTim Crawford1-0/+1
commit 9cb727506704b5323998047789fc871e64a6aa14 upstream. Fixes headset detection on Clevo NP50PNJ. Signed-off-by: Tim Crawford <tcrawford@system76.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220307193229.5141-1-tcrawford@system76.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: hda/realtek: Add quirk for Clevo NP70PNJTim Crawford1-0/+1
commit 0c20fce13e6e111463e3a15ce3cf6713fe518388 upstream. Fixes headset detection on Clevo NP70PNJ. Signed-off-by: Tim Crawford <tcrawford@system76.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220304170840.3351-1-tcrawford@system76.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: usb-audio: add mapping for new Corsair Virtuoso SEReza Jahanbakhshi1-0/+10
commit cd94df1795418056a19ff4cb44eadfc18ac99a57 upstream. New device id for Corsair Virtuoso SE RGB Wireless that currently is not in the mixer_map. This entry in the mixer_map is necessary in order to label its mixer appropriately and allow userspace to pick the correct volume controls. For instance, my own Corsair Virtuoso SE RGB Wireless headset has this new ID and consequently, the sidetone and volume are not working correctly without this change. > sudo lsusb -v | grep -i corsair Bus 007 Device 011: ID 1b1c:0a40 Corsair CORSAIR VIRTUOSO SE Wireless Gam idVendor 0x1b1c Corsair iManufacturer 1 Corsair iProduct 2 CORSAIR VIRTUOSO SE Wireless Gaming Headset Signed-off-by: Reza Jahanbakhshi <reza.jahanbakhshi@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220304212303.195949-1-reza.jahanbakhshi@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ALSA: oss: Fix PCM OSS buffer allocation overflowTakashi Iwai2-5/+12
commit efb6402c3c4a7c26d97c92d70186424097b6e366 upstream. We've got syzbot reports hitting INT_MAX overflow at vmalloc() allocation that is called from snd_pcm_plug_alloc(). Although we apply the restrictions to input parameters, it's based only on the hw_params of the underlying PCM device. Since the PCM OSS layer allocates a temporary buffer for the data conversion, the size may become unexpectedly large when more channels or higher rates is given; in the reported case, it went over INT_MAX, hence it hits WARN_ON(). This patch is an attempt to avoid such an overflow and an allocation for too large buffers. First off, it adds the limit of 1MB as the upper bound for period bytes. This must be large enough for all use cases, and we really don't want to handle a larger temporary buffer than this size. The size check is performed at two places, where the original period bytes is calculated and where the plugin buffer size is calculated. In addition, the driver uses array_size() and array3_size() for multiplications to catch overflows for the converted period size and buffer bytes. Reported-by: syzbot+72732c532ac1454eeee9@syzkaller.appspotmail.com Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/00000000000085b1b305da5a66f3@google.com Link: https://lore.kernel.org/r/20220318082036.29699-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ASoC: sti: Fix deadlock via snd_pcm_stop_xrun() callTakashi Iwai2-4/+4
commit 455c5653f50e10b4f460ef24e99f0044fbe3401c upstream. This is essentially a revert of the commit dc865fb9e7c2 ("ASoC: sti: Use snd_pcm_stop_xrun() helper"), which converted the manual snd_pcm_stop() calls with snd_pcm_stop_xrun(). The commit above introduced a deadlock as snd_pcm_stop_xrun() itself takes the PCM stream lock while the caller already holds it. Since the conversion was done only for consistency reason and the open-call with snd_pcm_stop() to the XRUN state is a correct usage, let's revert the commit back as the fix. Fixes: dc865fb9e7c2 ("ASoC: sti: Use snd_pcm_stop_xrun() helper") Reported-by: Daniel Palmer <daniel@0x0f.com> Cc: Arnaud POULIQUEN <arnaud.pouliquen@st.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220315091319.3351522-1-daniel@0x0f.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20220315164158.19804-1-tiwai@suse.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-08ASoC: cs4265: Fix the duplicated control nameFabio Estevam1-2/+1
commit c5487b9cdea5c1ede38a7ec94db0fc59963c8e86 upstream. Currently, the following error messages are seen during boot: asoc-simple-card sound: control 2:0:0:SPDIF Switch:0 is already present cs4265 1-004f: ASoC: failed to add widget SPDIF dapm kcontrol SPDIF Switch: -16 Quoting Mark Brown: "The driver is just plain buggy, it defines both a regular SPIDF Switch control and a SND_SOC_DAPM_SWITCH() called SPDIF both of which will create an identically named control, it can never have loaded without error. One or both of those has to be renamed or they need to be merged into one thing." Fix the duplicated control name by combining the two SPDIF controls here and move the register bits onto the DAPM widget and have DAPM control them. Fixes: f853d6b3ba34 ("ASoC: cs4265: Add a S/PDIF enable switch") Signed-off-by: Fabio Estevam <festevam@denx.de> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220215120514.1760628-1-festevam@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-08ASoC: ops: Shift tested values in snd_soc_put_volsw() by +minMarek Vasut1-2/+2
commit 9bdd10d57a8807dba0003af0325191f3cec0f11c upstream. While the $val/$val2 values passed in from userspace are always >= 0 integers, the limits of the control can be signed integers and the $min can be non-zero and less than zero. To correctly validate $val/$val2 against platform_max, add the $min offset to val first. Fixes: 817f7c9335ec0 ("ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220215130645.164025-1-marex@denx.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-08ALSA: intel_hdmi: Fix reference to PCM buffer addressZhen Ni1-1/+1
commit 0aa6b294b312d9710804679abd2c0c8ca52cc2bc upstream. PCM buffers might be allocated dynamically when the buffer preallocation failed or a larger buffer is requested, and it's not guaranteed that substream->dma_buffer points to the actually used buffer. The driver needs to refer to substream->runtime->dma_addr instead for the buffer address. Signed-off-by: Zhen Ni <nizhen@uniontech.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220302074241.30469-1-nizhen@uniontech.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-08ASoC: rt5682: do not block workqueue if card is unboundKai Vehmanen1-5/+7
[ Upstream commit 4c33de0673ced9c7c37b3bbd9bfe0fda72340b2a ] The current rt5682_jack_detect_handler() assumes the component and card will always show up and implements an infinite usleep loop waiting for them to show up. This does not hold true if a codec interrupt (or other event) occurs when the card is unbound. The codec driver's remove or shutdown functions cannot cancel the workqueue due to the wait loop. As a result, code can either end up blocking the workqueue, or hit a kernel oops when the card is freed. Fix the issue by rescheduling the jack detect handler in case the card is not ready. In case card never shows up, the shutdown/remove/suspend calls can now cancel the detect task. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20220207153000.3452802-3-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-08ASoC: rt5668: do not block workqueue if card is unboundKai Vehmanen1-5/+7
[ Upstream commit a6d78661dc903d90a327892bbc34268f3a5f4b9c ] The current rt5668_jack_detect_handler() assumes the component and card will always show up and implements an infinite usleep loop waiting for them to show up. This does not hold true if a codec interrupt (or other event) occurs when the card is unbound. The codec driver's remove or shutdown functions cannot cancel the workqueue due to the wait loop. As a result, code can either end up blocking the workqueue, or hit a kernel oops when the card is freed. Fix the issue by rescheduling the jack detect handler in case the card is not ready. In case card never shows up, the shutdown/remove/suspend calls can now cancel the detect task. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20220207153000.3452802-2-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-23ASoC: qcom: Actually clear DMA interrupt register for HDMIStephen Boyd1-4/+4
commit c8d251f51ee61df06ee0e419348d8c9160bbfb86 upstream. In commit da0363f7bfd3 ("ASoC: qcom: Fix for DMA interrupt clear reg overwriting") we changed regmap_write() to regmap_update_bits() so that we can avoid overwriting bits that we didn't intend to modify. Unfortunately this change breaks the case where a register is writable but not readable, which is exactly how the HDMI irq clear register is designed (grep around LPASS_HDMITX_APP_IRQCLEAR_REG to see how it's write only). That's because regmap_update_bits() tries to read the register from the hardware and if it isn't readable it looks in the regmap cache to see what was written there last time to compare against what we want to write there. Eventually, we're unable to modify this register at all because the bits that we're trying to set are already set in the cache. This is doubly bad for the irq clear register because you have to write the bit to clear an interrupt. Given the irq is level triggered, we see an interrupt storm upon plugging in an HDMI cable and starting audio playback. The irq storm is so great that performance degrades significantly, leading to CPU soft lockups. Fix it by using regmap_write_bits() so that we really do write the bits in the clear register that we want to. This brings the number of irqs handled by lpass_dma_interrupt_handler() down from ~150k/sec to ~10/sec. Fixes: da0363f7bfd3 ("ASoC: qcom: Fix for DMA interrupt clear reg overwriting") Cc: Srinivasa Rao Mandadapu <srivasam@codeaurora.org> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220209232520.4017634-1-swboyd@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23ASoC: tas2770: Insert post reset delayMartin Povišer1-1/+6
commit 307f31452078792aab94a729fce33200c6e42dc4 upstream. Per TAS2770 datasheet there must be a 1 ms delay from reset to first command. So insert delays into the driver where appropriate. Fixes: 1a476abc723e ("tas2770: add tas2770 smart PA kernel driver") Signed-off-by: Martin Povišer <povik+lin@cutebit.org> Link: https://lore.kernel.org/r/20220204095301.5554-1-povik+lin@cutebit.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23ASoC: ops: Fix stereo change notifications in snd_soc_put_xr_sx()Mark Brown1-1/+4
commit 2b7c46369f09c358164d31d17e5695185403185e upstream. When writing out a stereo control we discard the change notification from the first channel, meaning that events are only generated based on changes to the second channel. Ensure that we report a change if either channel has changed. Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220201155629.120510-5-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_sx()Mark Brown1-0/+7
commit 7f3d90a3519680dfa23e750f80bfdefc0f5eda4a upstream. When writing out a stereo control we discard the change notification from the first channel, meaning that events are only generated based on changes to the second channel. Ensure that we report a change if either channel has changed. Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220201155629.120510-3-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_range()Mark Brown1-5/+10
commit 650204ded3703b5817bd4b6a77fa47d333c4f902 upstream. When writing out a stereo control we discard the change notification from the first channel, meaning that events are only generated based on changes to the second channel. Ensure that we report a change if either channel has changed. Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220201155629.120510-4-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw()Mark Brown1-4/+10
commit 564778d7b1ea465f9487eedeece7527a033549c5 upstream. When writing out a stereo control we discard the change notification from the first channel, meaning that events are only generated based on changes to the second channel. Ensure that we report a change if either channel has changed. Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220201155629.120510-2-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23ALSA: hda: Fix missing codec probe on Shenker Dock 15Takashi Iwai1-0/+1
commit dd8e5b161d7fb9cefa1f1d6e35a39b9e1563c8d3 upstream. By some unknown reason, BIOS on Shenker Dock 15 doesn't set up the codec mask properly for the onboard audio. Let's set the forced codec mask to enable the codec discovery. Reported-by: dmummenschanz@web.de Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/trinity-f018660b-95c9-442b-a2a8-c92a56eb07ed-1644345967148@3c-app-webde-bap22 Link: https://lore.kernel.org/r/20220214100020.8870-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23ALSA: hda: Fix regression on forced probe mask optionTakashi Iwai1-2/+2
commit 6317f7449348a897483a2b4841f7a9190745c81b upstream. The forced probe mask via probe_mask 0x100 bit doesn't work any longer as expected since the bus init code was moved and it's clearing the codec_mask value that was set beforehand. This patch fixes the long-time regression by moving the check_probe_mask() call. Fixes: a41d122449be ("ALSA: hda - Embed bus into controller object") Reported-by: dmummenschanz@web.de Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/trinity-f018660b-95c9-442b-a2a8-c92a56eb07ed-1644345967148@3c-app-webde-bap22 Link: https://lore.kernel.org/r/20220214100020.8870-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23ALSA: hda/realtek: Fix deadlock by COEF mutexTakashi Iwai1-15/+24
commit 2a845837e3d0ddaed493b4c5c4643d7f0542804d upstream. The recently introduced coef_mutex for Realtek codec seems causing a deadlock when the relevant code is invoked from the power-off state; then the HD-audio core tries to power-up internally, and this kicks off the codec runtime PM code that tries to take the same coef_mutex. In order to avoid the deadlock, do the temporary power up/down around the coef_mutex acquisition and release. This assures that the power-up sequence runs before the mutex, hence no re-entrance will happen. Fixes: b837a9f5ab3b ("ALSA: hda: realtek: Fix race at concurrent COEF updates") Reported-and-tested-by: Julian Wollrath <jwollrath@web.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220214132838.4db10fca@schienar Link: https://lore.kernel.org/r/20220214130410.21230-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23ALSA: hda/realtek: Add quirk for Legion Y9000X 2019Yu Huang1-0/+1
commit c07f2c7b45413a9e50ba78630fda04ecfa17b4f2 upstream. Legion Y9000X 2019 has the same speaker with Y9000X 2020, but with a different quirk address. Add one quirk entry to make the speaker work on Y9000X 2019 too. Signed-off-by: Yu Huang <diwang90@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220212160835.165065-1-diwang90@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-23ALSA: usb-audio: revert to IMPLICIT_FB_FIXED_DEV for M-Audio FastTrack UltraMatteo Martelli1-2/+2
commit 19d20c7a29bf2e46ff1ab8e8c4fcd2da8a4f38e2 upstream. Commit 83b7dcbc51c930fc2079ab6c6fc9d719768321f1 introduced a generic implicit feedback parser, which fails to execute for M-Audio FastTrack Ultra sound cards. The issue is with the ENDPOINT_SYNCTYPE check in add_generic_implicit_fb() where the SYNCTYPE is ADAPTIVE instead of ASYNC. The reason is that the sync type of the FastTrack output endpoints are set to adaptive in the quirks table since commit 65f04443c96dbda11b8fff21d6390e082846aa3c. Fixes: 83b7dcbc51c9 ("ALSA: usb-audio: Add generic implicit fb parsing") Signed-off-by: Matteo Martelli <matteomartelli3@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220211224913.20683-2-matteomartelli3@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-08ASoC: codecs: wcd938x: fix return value of mixer put functionSrinivas Kandagatla1-3/+3
commit bd2347fd67d8da0fa76296507cc556da0a233bcb upstream. wcd938x_ear_pa_put_gain, wcd938x_set_swr_port and wcd938x_set_compander currently returns zero eventhough it changes the value. Fix this, so that change notifications are sent correctly. Fixes: e8ba1e05bdc01 ("ASoC: codecs: wcd938x: add basic controls") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220126113549.8853-4-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-08ASoC: codecs: lpass-rx-macro: fix sidetone register offsetsSrinivas Kandagatla1-4/+4
commit fca041a3ab70a099a6d5519ecb689b6279bd04f3 upstream. For some reason we ended up with incorrect register offfset calcuations for sidetone. regmap clearly throw errors when accessing these incorrect registers as these do not belong to any read/write ranges. so fix them to point to correct register offsets. Fixes: f3ce6f3c9a99 ("ASoC: codecs: lpass-rx-macro: add iir widgets") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220126113549.8853-3-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-08ASoC: codecs: wcd938x: fix incorrect used of portidSrinivas Kandagatla1-11/+14
commit c5c1546a654f613e291a7c5d6f3660fc1eb6d0c7 upstream. Mixer controls have the channel id in mixer->reg, which is not same as port id. port id should be derived from chan_info array. So fix this. Without this, its possible that we could corrupt struct wcd938x_sdw_priv by accessing port_map array out of range with channel id instead of port id. Fixes: e8ba1e05bdc0 ("ASoC: codecs: wcd938x: add basic controls") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220126113549.8853-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-08ASoC: max9759: fix underflow in speaker_gain_control_put()Dan Carpenter1-1/+2
commit 4c907bcd9dcd233da6707059d777ab389dcbd964 upstream. Check for negative values of "priv->gain" to prevent an out of bounds access. The concern is that these might come from the user via: -> snd_ctl_elem_write_user() -> snd_ctl_elem_write() -> kctl->put() Fixes: fa8d915172b8 ("ASoC: max9759: Add Amplifier Driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220119123101.GA9509@kili Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-08ASoC: cpcap: Check for NULL pointer after calling of_get_child_by_nameJiasheng Jiang1-0/+2
commit f7a6021aaf02088870559f82fc13c58cda7fea1a upstream. If the device does not exist, of_get_child_by_name() will return NULL pointer. And devm_snd_soc_register_component() does not check it. Also, I have noticed that cpcap_codec_driver has not been used yet. Therefore, it should be better to check it in order to avoid the future dereference of the NULL pointer. Fixes: f6cdf2d3445d ("ASoC: cpcap: new codec") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Link: https://lore.kernel.org/r/20220111025048.524134-1-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-08ASoC: simple-card: fix probe failure on platform componentRobert Hancock1-1/+25
commit a64067f4cecaaa4deed8e33d3266bc0bcc189142 upstream. A previous change to simple-card resulted in asoc_simple_parse_dai attempting to retrieve the dai_name for platform components, which are unlikely to have a valid DAI name. This caused simple-card to fail to probe when using the xlnx_formatter_pcm as the platform component, since it does not register any DAI components. Since the dai_name is not used for platform components, just skip trying to retrieve it for those. Fixes: f107294c6422 ("ASoC: simple-card: support snd_soc_dai_link_component style for cpu") Signed-off-by: Robert Hancock <robert.hancock@calian.com> Link: https://lore.kernel.org/r/20220107214711.1100162-6-robert.hancock@calian.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-08ASoC: xilinx: xlnx_formatter_pcm: Make buffer bytes multiple of period bytesRobert Hancock1-3/+24
commit e958b5884725dac86d36c1e7afe5a55f31feb0b2 upstream. This patch is based on one in the Xilinx kernel tree, "ASoc: xlnx: Make buffer bytes multiple of period bytes" by Devarsh Thakkar. The same issue exists in the mainline version of the driver. The original patch description is as follows: "The Xilinx Audio Formatter IP has a constraint on period bytes to be multiple of 64. This leads to driver changing the period size to suitable frames such that period bytes are multiple of 64. Now since period bytes and period size are updated but not the buffer bytes, this may make the buffer bytes unaligned and not multiple of period bytes. When this happens we hear popping noise as while DMA is being done the buffer bytes are not enough to complete DMA access for last period of frame within the application buffer boundary. To avoid this, align buffer bytes too as multiple of 64, and set another constraint to always enforce number of periods as integer. Now since, there is already a rule in alsa core to enforce Buffer size = Number of Periods * Period Size this automatically aligns buffer bytes as multiple of period bytes." Fixes: 6f6c3c36f091 ("ASoC: xlnx: add pcm formatter platform driver") Cc: Devarsh Thakkar <devarsh.thakkar@xilinx.com> Signed-off-by: Robert Hancock <robert.hancock@calian.com> Link: https://lore.kernel.org/r/20220107214711.1100162-2-robert.hancock@calian.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-08ASoC: fsl: Add missing error handling in pcm030_fabric_probeMiaoqian Lin1-3/+8
commit fb25621da5702c104ce0a48de5b174ced09e5b4e upstream. Add the missing platform_device_put() and platform_device_del() before return from pcm030_fabric_probe in the error handling case. Fixes: c912fa913446 ("ASoC: fsl: register the wm9712-codec") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20220127131336.30214-1-linmq006@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-15 00:48:24 +0300