Introduce own lock to silence lockdep warning. lockdep validator
makes wrong decision when two similar (&map->mutex) locks were taken
recursively, even those are different mutexes in a two different
drivers. After that patch, functionality remains same, but mutex names
are different. That is a temporary hack, proper solution is make
regmap aware of locked nested locking rules.
=============================================
[ INFO: possible recursive locking detected ]
3.18.0-rc4+ #4 Tainted: G O
---------------------------------------------
kdvb-ad-0-fe-0/2814 is trying to acquire lock:
(&map->mutex){+.+.+.}, at: [<ffffffff814ec90f>] regmap_lock_mutex+0x2f/0x40
but task is already holding lock:
(&map->mutex){+.+.+.}, at: [<ffffffff814ec90f>] regmap_lock_mutex+0x2f/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&map->mutex);
lock(&map->mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by kdvb-ad-0-fe-0/2814:
#0: (&map->mutex){+.+.+.}, at: [<ffffffff814ec90f>] regmap_lock_mutex+0x2f/0x40
git.openpandora.org / pandora-kernel.git / commitdiff