kernel/linux.git/sound, branch v5.15.112

ASoC: soc-pcm.c: call __soc_pcm_close() in soc_pcm_close()

2023-05-17T09:50:27+00:00

commit 6bbabd28805f36baf6d0f3eb082db032a638f612 upstream. commit b7898396f4bbe16 ("ASoC: soc-pcm: Fix and cleanup DPCM locking") added __soc_pcm_close() for non-lock version of soc_pcm_close(). But soc_pcm_close() is not using it. It is no problem, but confusable. static int __soc_pcm_close(...) { => return soc_pcm_clean(rtd, substream, 0); } static int soc_pcm_close(...) { ... snd_soc_dpcm_mutex_lock(rtd); => soc_pcm_clean(rtd, substream, 0); snd_soc_dpcm_mutex_unlock(rtd); return 0; } This patch use it. Fixes: b7898396f4bbe16 ("ASoC: soc-pcm: Fix and cleanup DPCM locking") Cc: Takashi Iwai Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87czctgg3w.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: DPCM: Don't pick up BE without substream

2023-05-17T09:50:26+00:00

commit 754590651ccbbcc74a7c20907be4bb15d642bde3 upstream. When DPCM tries to add valid BE connections at dpcm_add_paths(), it doesn't check whether the picked BE actually supports for the given stream direction. Due to that, when an asymmetric BE stream is present, it picks up wrongly and this may result in a NULL dereference at a later point where the code assumes the existence of a corresponding BE substream. This patch adds the check for the presence of the substream for the target BE for avoiding the problem above. Note that we have already some fix for non-existing BE substream at commit 6246f283d5e0 ("ASoC: dpcm: skip missing substream while applying symmetry"). But the code path we've hit recently is rather happening before the previous fix. So this patch tries to fix at picking up a BE instead of parsing BE lists. Fixes: bbf7d3b1c4f4 ("ASoC: soc-pcm: align BE 'atomicity' with that of the FE") Reported-by: Alex Natalsson Cc: Pierre-Louis Bossart Cc: Péter Ujfalusi Link: https://lore.kernel.org/r/CADs9LoPZH_D+eJ9qjTxSLE5jGyhKsjMN7g2NighZ16biVxsyKw@mail.gmail.com Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20220801170510.26582-1-tiwai@suse.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: soc-pcm: Move debugfs removal out of spinlock

2023-05-17T09:50:26+00:00

commit 9f620684c1ef5a002b6622ecc7b5818e81252f48 upstream. The recent fix for DPCM locking also covered the loop in dpcm_be_disconnect() with the FE stream lock. This caused an unexpected side effect, thought: calling debugfs_remove_recursive() in the spinlock may lead to lockdep splats as the code there assumes the SOFTIRQ-safe context. For avoiding the problem, this patch changes the disconnection procedure to two phases: at first, the matching entries are removed from the linked list, then the resources are freed outside the lock. Fixes: b7898396f4bb ("ASoC: soc-pcm: Fix and cleanup DPCM locking") Reported-and-tested-by: Marek Szyprowski Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20220119155249.26754-3-tiwai@suse.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: soc-compress: Inherit atomicity from DAI link for Compress FE

2023-05-17T09:50:26+00:00

commit 37b58becc1cee4d591024f2056d7ffa99c6089e0 upstream. After commit bbf7d3b1c4f40 ("ASoC: soc-pcm: align BE 'atomicity' with that of the FE") BE and FE atomicity must match. In the case of Compress PCM there is a mismatch in atomicity between FE and BE and we get errors like this: [ 36.434566] sai1-wm8960-hifi: dpcm_be_connect: FE is atomic but BE is nonatomic, invalid configuration [ 36.444278] PCM Deep Buffer: ASoC: can't connect SAI1.OUT In order to fix this we must inherit the atomicity from DAI link associated with current PCM Compress FE. Fixes: bbf7d3b1c4f4 ("ASoC: soc-pcm: align BE 'atomicity' with that of the FE") Signed-off-by: Daniel Baluta Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230324124019.30826-1-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: soc-pcm: Fix DPCM lockdep warning due to nested stream locks

2023-05-17T09:50:26+00:00

commit 3c75c0ea5da749bd1efebd1387f2e5011b8c7d78 upstream. The recent change for DPCM locking caused spurious lockdep warnings. Actually the warnings are false-positive, as those are triggered due to the nested stream locks for FE and BE. Since both locks belong to the same lock class, lockdep sees it as if a deadlock. For fixing this, we need to take PCM stream locks for BE with the nested lock primitives. Since currently snd_pcm_stream_lock*() helper assumes only the top-level single locking, a new helper function snd_pcm_stream_lock_irqsave_nested() is defined for a single-depth nested lock, which is now used in the BE DAI trigger that is always performed inside a FE stream lock. Fixes: b2ae80663008 ("ASoC: soc-pcm: serialize BE triggers") Reported-and-tested-by: Hans de Goede Reported-and-tested-by: Marek Szyprowski Link: https://lore.kernel.org/r/73018f3c-9769-72ea-0325-b3f8e2381e30@redhat.com Link: https://lore.kernel.org/alsa-devel/9a0abddd-49e9-872d-2f00-a1697340f786@samsung.com Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20220119155249.26754-2-tiwai@suse.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ALSA: caiaq: input: Add error handling for unsupported input methods in `snd_usb_caiaq_input_init`

2023-05-17T09:50:19+00:00

[ Upstream commit 0d727e1856ef22dd9337199430258cb64cbbc658 ] Smatch complains that: snd_usb_caiaq_input_init() warn: missing error code 'ret' This patch adds a new case to handle the situation where the device does not support any input methods in the `snd_usb_caiaq_input_init` function. It returns an `-EINVAL` error code to indicate that no input methods are supported on the device. Fixes: 523f1dce3743 ("[ALSA] Add Native Instrument usb audio device support") Signed-off-by: Ruliang Lin Reviewed-by: Dongliang Mu Acked-by: Daniel Mack Link: https://lore.kernel.org/r/20230504065054.3309-1-u202112092@hust.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ASoC: soc-pcm: fix BE handling of PAUSE_RELEASE

2023-05-17T09:50:15+00:00

[ Upstream commit 3aa1e96a2b95e2ece198f8dd01e96818971b84df ] A BE connected to more than one FE, e.g. in a mixer case, can go through the following transitions. play FE1 -> BE state is START pause FE1 -> BE state is PAUSED play FE2 -> BE state is START stop FE2 -> BE state is STOP (see note [1] below) release FE1 -> BE state is START stop FE1 -> BE state is STOP play FE1 -> BE state is START pause FE1 -> BE state is PAUSED play FE2 -> BE state is START release FE1 -> BE state is START stop FE2 -> BE state is START stop FE1 -> BE state is STOP play FE1 -> BE state is START play FE2 -> BE state is START (no change) pause FE1 -> BE state is START (no change) pause FE2 -> BE state is PAUSED release FE1 -> BE state is START release FE2 -> BE state is START (no change) stop FE1 -> BE state is START (no change) stop FE2 -> BE state is STOP The existing code for PAUSE_RELEASE only allows for the case where the BE is paused, which clearly would not work in the sequences above. Extend the allowed states to restart the BE when PAUSE_RELEASE is received, and increase the refcount if the BE is already in START. [1] the existing logic does not move the BE state back to PAUSED when the FE2 is stopped. This patch does not change the logic; it would be painful to keep a history of changes on the FE side, the state machine is already rather complicated with transitions based on the last BE state and the trigger type. Reported-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20211207173745.15850-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: soc-pcm: test refcount before triggering

2023-05-17T09:50:15+00:00

[ Upstream commit 848aedfdc6ba25ad5652797db9266007773e44dd ] On start/pause_release/resume, when more than one FE is connected to the same BE, it's possible that the trigger is sent more than once. This is not desirable, we only want to trigger a BE once, which is straightforward to implement with a refcount. For stop/pause/suspend, the problem is more complicated: the check implemented in snd_soc_dpcm_can_be_free_stop() may fail due to a conceptual deadlock when we trigger the BE before the FE. In this case, the FE states have not yet changed, so there are corner cases where the TRIGGER_STOP is never sent - the dual case of start where multiple triggers might be sent. This patch suggests an unconditional trigger in all cases, without checking the FE states, using a refcount protected by the BE PCM stream lock. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20211207173745.15850-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: soc-pcm: serialize BE triggers

2023-05-17T09:50:15+00:00

[ Upstream commit b2ae80663008a7662febe7d13f14ea1b2eb0cd51 ] When more than one FE is connected to a BE, e.g. in a mixing use case, the BE can be triggered multiple times when the FE are opened/started concurrently. This race condition is problematic in the case of SoundWire BE dailinks, and this is not desirable in a general case. This patch relies on the existing BE PCM lock, which takes atomicity into account. The locking model assumes that all interactions start with the FE, so that there is no deadlock between FE and BE locks. Signed-off-by: Takashi Iwai [test, checkpatch fix and clarification of commit message by plbossart] Signed-off-by: Pierre-Louis Bossart Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20211207173745.15850-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: soc-pcm: Fix and cleanup DPCM locking

2023-05-17T09:50:15+00:00

[ Upstream commit b7898396f4bbe160f546d0c5e9fa17cca9a7d153 ] The existing locking for DPCM has several issues a) a confusing mix of card->mutex and card->pcm_mutex. b) a dpcm_lock spinlock added inconsistently and on paths that could be recursively taken. The use of irqsave/irqrestore was also overkill. The suggested model is: 1) The pcm_mutex is the top-most protection of BE links in the FE. The pcm_mutex is applied always on either the top PCM callbacks or the external call from DAPM, not taken in the internal functions. 2) the FE stream lock is taken in higher levels before invoking dpcm_be_dai_trigger() 3) when adding and deleting a BE, both the pcm_mutex and FE stream lock are taken. Signed-off-by: Takashi Iwai [clarification of commit message by plbossart] Signed-off-by: Pierre-Louis Bossart Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20211207173745.15850-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin