[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1445998534-38246-1-git-send-email-koro.chen@mediatek.com>
Date: Wed, 28 Oct 2015 10:15:34 +0800
From: Koro Chen <koro.chen@...iatek.com>
To: <broonie@...nel.org>, <tiwai@...e.de>
CC: <srv_heupstream@...iatek.com>,
<linux-mediatek@...ts.infradead.org>, <s.hauer@...gutronix.de>,
<liam.r.girdwood@...ux.intel.com>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <alsa-devel@...a-project.org>,
Koro Chen <koro.chen@...iatek.com>
Subject: [PATCH] ASoC: dpcm: Make BE prepare possible in suspend state
During suspend/resume, there is a flow that if a driver does not support
SNDRV_PCM_INFO_RESUME, it will fail at snd_pcm_resume(), and user space
can then issue SNDRV_PCM_IOCTL_PREPARE to let audio continue to play.
However, in dpcm_be_dai_prepare() it only allows BEs to be prepared
in state SND_SOC_DPCM_STATE_HW_PARAMS or SND_SOC_DPCM_STATE_STOP.
The BE state will then stay in SND_SOC_DPCM_STATE_SUSPEND, consequently
dpcm_be_dai_shutdown() is skipped in the end of playback and
be_substream->runtime is not cleared while this runtime is actually freed
by snd_pcm_detach_substream(). If another suspend comes, a NULL pointer
dereference will happen in snd_pcm_suspend() when accessing
BE substream's runtime.
Signed-off-by: Koro Chen <koro.chen@...iatek.com>
---
sound/soc/soc-pcm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index 3173958..5c41a58 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -2117,7 +2117,8 @@ int dpcm_be_dai_prepare(struct snd_soc_pcm_runtime *fe, int stream)
continue;
if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) &&
- (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP))
+ (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP) &&
+ (be->dpcm[stream].state != SND_SOC_DPCM_STATE_SUSPEND))
continue;
dev_dbg(be->dev, "ASoC: prepare BE %s\n",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists