From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Sasha Levin <sashal@kernel.org>,
Tzung-Bi Shih <tzungbi@google.com>,
alsa-devel@alsa-project.org, Mark Brown <broonie@kernel.org>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Subject: [alsa-devel] [PATCH AUTOSEL 5.4 007/187] ASoC: max98090: fix possible race conditions
Date: Fri, 27 Dec 2019 12:37:55 -0500 [thread overview]
Message-ID: <20191227174055.4923-7-sashal@kernel.org> (raw)
In-Reply-To: <20191227174055.4923-1-sashal@kernel.org>
From: Tzung-Bi Shih <tzungbi@google.com>
[ Upstream commit 45dfbf56975994822cce00b7475732a49f8aefed ]
max98090_interrupt() and max98090_pll_work() run in 2 different threads.
There are 2 possible races:
Note: M98090_REG_DEVICE_STATUS = 0x01.
Note: ULK == 0, PLL is locked; ULK == 1, PLL is unlocked.
max98090_interrupt max98090_pll_work
----------------------------------------------
schedule max98090_pll_work
restart max98090 codec
receive ULK INT
assert ULK == 0
schedule max98090_pll_work (1).
In the case (1), the PLL is locked but max98090_interrupt unnecessarily
schedules another max98090_pll_work.
max98090_interrupt max98090_pll_work max98090 codec
----------------------------------------------------------------------
ULK = 1
receive ULK INT
read 0x01
ULK = 0 (clear on read)
schedule max98090_pll_work
restart max98090 codec
ULK = 1
receive ULK INT
read 0x01
ULK = 0 (clear on read)
read 0x01
assert ULK == 0 (2).
In the case (2), both max98090_interrupt and max98090_pll_work read
the same clear-on-read register. max98090_pll_work would falsely
thought PLL is locked.
Note: the case (2) race is introduced by the previous commit ("ASoC:
max98090: exit workaround earlier if PLL is locked") to check the status
and exit the loop earlier in max98090_pll_work.
There are 2 possible solution options:
A. turn off ULK interrupt before scheduling max98090_pll_work; and turn
on again before exiting max98090_pll_work.
B. remove the second thread of execution.
Option A cannot fix the case (2) race because it still has 2 threads
access the same clear-on-read register simultaneously. Although we
could suppose the register is volatile and read the status via I2C could
be much slower than the hardware raises the bits.
Option B introduces a maximum 10~12 msec penalty delay in the interrupt
handler. However, it could only punish the jack detection by extra
10~12 msec.
Adopts option B which is the better solution overall.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20191122073114.219945-4-tzungbi@google.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/codecs/max98090.c | 8 ++------
sound/soc/codecs/max98090.h | 1 -
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index f531e5a11bdd..e46b6ada13b1 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -2103,10 +2103,8 @@ static void max98090_pll_det_disable_work(struct work_struct *work)
M98090_IULK_MASK, 0);
}
-static void max98090_pll_work(struct work_struct *work)
+static void max98090_pll_work(struct max98090_priv *max98090)
{
- struct max98090_priv *max98090 =
- container_of(work, struct max98090_priv, pll_work);
struct snd_soc_component *component = max98090->component;
unsigned int pll;
int i;
@@ -2275,7 +2273,7 @@ static irqreturn_t max98090_interrupt(int irq, void *data)
if (active & M98090_ULK_MASK) {
dev_dbg(component->dev, "M98090_ULK_MASK\n");
- schedule_work(&max98090->pll_work);
+ max98090_pll_work(max98090);
}
if (active & M98090_JDET_MASK) {
@@ -2438,7 +2436,6 @@ static int max98090_probe(struct snd_soc_component *component)
max98090_pll_det_enable_work);
INIT_WORK(&max98090->pll_det_disable_work,
max98090_pll_det_disable_work);
- INIT_WORK(&max98090->pll_work, max98090_pll_work);
/* Enable jack detection */
snd_soc_component_write(component, M98090_REG_JACK_DETECT,
@@ -2491,7 +2488,6 @@ static void max98090_remove(struct snd_soc_component *component)
cancel_delayed_work_sync(&max98090->jack_work);
cancel_delayed_work_sync(&max98090->pll_det_enable_work);
cancel_work_sync(&max98090->pll_det_disable_work);
- cancel_work_sync(&max98090->pll_work);
max98090->component = NULL;
}
diff --git a/sound/soc/codecs/max98090.h b/sound/soc/codecs/max98090.h
index 57965cd678b4..a197114b0dad 100644
--- a/sound/soc/codecs/max98090.h
+++ b/sound/soc/codecs/max98090.h
@@ -1530,7 +1530,6 @@ struct max98090_priv {
struct delayed_work jack_work;
struct delayed_work pll_det_enable_work;
struct work_struct pll_det_disable_work;
- struct work_struct pll_work;
struct snd_soc_jack *jack;
unsigned int dai_fmt;
int tdm_slots;
--
2.20.1
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2019-12-27 17:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-27 17:37 [alsa-devel] [PATCH AUTOSEL 5.4 001/187] ASoC: rt5682: fix i2c arbitration lost issue Sasha Levin
2019-12-27 17:37 ` [alsa-devel] [PATCH AUTOSEL 5.4 005/187] ASoC: max98090: remove msleep in PLL unlocked workaround Sasha Levin
2019-12-27 22:43 ` Mark Brown
2019-12-27 17:37 ` [alsa-devel] [PATCH AUTOSEL 5.4 006/187] ASoC: max98090: exit workaround earlier if PLL is locked Sasha Levin
2019-12-27 22:44 ` Mark Brown
2020-01-05 15:30 ` Sasha Levin
2019-12-27 17:37 ` Sasha Levin [this message]
2019-12-27 17:38 ` [alsa-devel] [PATCH AUTOSEL 5.4 023/187] ASoC: Intel: bytcr_rt5640: Update quirk for Teclast X89 Sasha Levin
2019-12-27 17:38 ` [alsa-devel] [PATCH AUTOSEL 5.4 060/187] ASoC: topology: Check return value for snd_soc_add_dai_link() Sasha Levin
2019-12-27 17:38 ` [alsa-devel] [PATCH AUTOSEL 5.4 061/187] ASoC: topology: Check return value for soc_tplg_pcm_create() Sasha Levin
2019-12-27 17:38 ` [alsa-devel] [PATCH AUTOSEL 5.4 062/187] ASoC: SOF: loader: snd_sof_fw_parse_ext_data log warning on unknown header Sasha Levin
2019-12-27 17:38 ` [alsa-devel] [PATCH AUTOSEL 5.4 063/187] ASoC: SOF: Intel: split cht and byt debug window sizes Sasha Levin
2019-12-27 17:39 ` [alsa-devel] [PATCH AUTOSEL 5.4 123/187] ASoC: wm8962: fix lambda value Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191227174055.4923-7-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=stable@vger.kernel.org \
--cc=tzungbi@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox