Re: [PATCH 2/2] ASoC: DAPM - Make sure DAPM widget IO ops hold the component mutex.

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1253 bytes --]

On Wed, Mar 07, 2012 at 11:13:25AM +0000, Liam Girdwood wrote:
> On Wed, 2012-03-07 at 10:54 +0000, Mark Brown wrote:

> > Yes, we are but it's a simple comparison with integer so not the end of
> > the world.  I'd much rather have the check in the locking code so it's
> > clear what's expected instead of split between one of the call sites and
> > the locking function where it might easily get missed if someone adds a
> > new user.

> Ah, I'm thinking with a different perspective here ;-)

> My reasoning is that the widget lock will guarantee the component lock.
> With the regmap test we don't guarantee a component lock and subsequent
> new widget lock users may depend on this lock.

I don't understand what you mean by "component lock" here.  Do you mean
CODEC/platform lock or something else?  In any case it's stuff like the
above assumption which makes me want to be explicit here - either we
should take the lock in all paths or we always skip the lock in regmap
paths.  Either is fine for me, I'd just rather keep it straight in my
head.

Actually given the number of indirections here (there's similar "is it a
platform" stuff for the I/O too) we probably want to create some base
class object before we start adding more stuff anyway.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]