lkml.org 
[lkml]   [2014]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 01/15] Input - arizona-haptics: Fix double lock of dapm_mutex
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.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2014-02-18 02:21    [W:0.491 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site