On 6/29/2015 8:32 AM, Mark Brown wrote:
On Mon, Jun 29, 2015 at 07:35:20AM -0700, Arjan van de Ven wrote:
lockdep assumes that there is a known lock hierarchy, at least known to the developer.
seems like for regmap there isn't
It's not that there's no heirachy of locks, it's that lockdep is unable to understand what's going on since it's making simplifying assumptions that just aren't true. If I remember the problem correctly it's grouping all locks allocated in the same place into one class which doesn't work at all for scenarios where you've got a generic interface providing services to many devices which may be stacked on top of each other.
but the stacking *IS* a lock hierarchy.
it just seems that the hierarchy is implied rather than explicit.
(I would be interested to know how you avoid ABBA deadlocks btw, can you have 2 devices, one with a hierarchy one way, and another with the hierarchy the other way?)
I'm not sure I fully understand what you mean here, sorry - do you mean in terms of classes or individual devices? The relationships between devices are all device and system defined, individual regmaps should be treated as separate classes. From this perspective it's basically eqivalent to asking how the mutex code avoids misuse of mutexes.
well what I meant is inividual devices/ranges
like device A is on devmap A but then ends up using devmap B underneath (e.g. the lock nesting case)
what prevents there from being a device B that is on devmap B but that uses devmap A underneath