| Message ID | 1392655903-24537-2-git-send-email-ckeepax@opensource.wolfsonmicro.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | c4204960e9d0ba99459dbf1db918f99a45e7a62a |
| Delegated to: | Mark Brown |
| Headers | show |
HI Charles, On Mon, Feb 17, 2014 at 04:51:29PM +0000, Charles Keepax wrote: > snd_soc_dapm_sync takes the dapm_mutex internally, but we currently take > it externally as well. This patch fixes this. Hmm, from the first glance this needs to go into current release, however it seems that it has been broken by a73fb2df01866b772a48fab93401fe3edbe0b38d 2 years ago so nobody cares... Looking at the series I am not sure that this is right direction. You actually do want unlocked versions of snd_soc_dapm_* functions so that callers can take dapm mutex and then perform sequence of operations. The currect callers that were taking the mutex should probbaly be changed so that they do not drop it until they called unlocked version of snd_soc_dapm_sync(). Thanks.
On Mon, Feb 17, 2014 at 11:20:26AM -0800, Dmitry Torokhov wrote: > On Mon, Feb 17, 2014 at 04:51:29PM +0000, Charles Keepax wrote: > > snd_soc_dapm_sync takes the dapm_mutex internally, but we currently take > > it externally as well. This patch fixes this. > Hmm, from the first glance this needs to go into current release, > however it seems that it has been broken by > a73fb2df01866b772a48fab93401fe3edbe0b38d 2 years ago so nobody cares... Please include plain text versions of commit message descriptions, in this case you're referring to "ASoC: dapm: Use DAPM mutex for DAPM ops instead of codec mutex". I expect nobody noticed in part because a lot of use has been out of tree on older kernels and in part because the issue is a race - there's a good chance things will work just fine without the locking. > Looking at the series I am not sure that this is right direction. You > actually do want unlocked versions of snd_soc_dapm_* functions so that > callers can take dapm mutex and then perform sequence of operations. The > currect callers that were taking the mutex should probbaly be changed so > that they do not drop it until they called unlocked version of > snd_soc_dapm_sync(). That's all more work than is in scope for a bug fix though.
On Mon, Feb 17, 2014 at 11:20:26AM -0800, Dmitry Torokhov wrote: > HI Charles, > > On Mon, Feb 17, 2014 at 04:51:29PM +0000, Charles Keepax wrote: > > snd_soc_dapm_sync takes the dapm_mutex internally, but we currently take > > it externally as well. This patch fixes this. > > Hmm, from the first glance this needs to go into current release, > however it seems that it has been broken by > a73fb2df01866b772a48fab93401fe3edbe0b38d 2 years ago so nobody cares... > > Looking at the series I am not sure that this is right direction. You > actually do want unlocked versions of snd_soc_dapm_* functions so that > callers can take dapm mutex and then perform sequence of operations. The > currect callers that were taking the mutex should probbaly be changed so > that they do not drop it until they called unlocked version of > snd_soc_dapm_sync(). Having looked over this again I would prefer to go with the current fix. It means the fix can be sent to the stable trees and the haptics driver has no requirement for multiple pin updates to be done atomically, so there is not a huge amount to be gained from bundling things under an external lock. Thanks, Charles
diff --git a/drivers/input/misc/arizona-haptics.c b/drivers/input/misc/arizona-haptics.c index 7a04f54..e7e12a5 100644 --- a/drivers/input/misc/arizona-haptics.c +++ b/drivers/input/misc/arizona-haptics.c @@ -77,16 +77,14 @@ static void arizona_haptics_work(struct work_struct *work) return; } + mutex_unlock(dapm_mutex); + ret = snd_soc_dapm_sync(arizona->dapm); if (ret != 0) { dev_err(arizona->dev, "Failed to sync DAPM: %d\n", ret); - mutex_unlock(dapm_mutex); return; } - - mutex_unlock(dapm_mutex); - } else { /* This disable sequence will be a noop if already enabled */ mutex_lock_nested(dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME); @@ -99,16 +97,15 @@ static void arizona_haptics_work(struct work_struct *work) return; } + mutex_unlock(dapm_mutex); + ret = snd_soc_dapm_sync(arizona->dapm); if (ret != 0) { dev_err(arizona->dev, "Failed to sync DAPM: %d\n", ret); - mutex_unlock(dapm_mutex); return; } - mutex_unlock(dapm_mutex); - ret = regmap_update_bits(arizona->regmap, ARIZONA_HAPTICS_CONTROL_1, ARIZONA_HAP_CTRL_MASK,
snd_soc_dapm_sync takes the dapm_mutex internally, but we currently take it externally as well. This patch fixes this. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> --- drivers/input/misc/arizona-haptics.c | 11 ++++------- 1 files changed, 4 insertions(+), 7 deletions(-)