On Mon, Jun 29, 2015 at 04:34:11PM +0100, Mark Brown wrote:
> On Mon, Jun 29, 2015 at 04:18:11PM +0200, Lars-Peter Clausen wrote:
> > Leaves us pretty much with only two options. Either add a lock key pointer
> > to regmap_config which needs to be manually initialized. Or wrap all
> > regmap_init()
On Mon, Jun 29, 2015 at 08:36:01AM -0700, Arjan van de Ven wrote:
> 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:
> >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 ma
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 i
On Mon, Jun 29, 2015 at 04:18:11PM +0200, Lars-Peter Clausen wrote:
Please delete unneeded context from replies.
> Leaves us pretty much with only two options. Either add a lock key pointer
> to regmap_config which needs to be manually initialized. Or wrap all
> regmap_init() variants to create a
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 s
On 6/29/2015 7:22 AM, Mark Brown wrote:
On Mon, Jun 29, 2015 at 10:03:09PM +0800, Nicolas Boichat wrote:
regmap instances are kalloc'ed, so they cannot contain the
lock_class_key, which needs to be statically allocated (in .data).
Another option would be to preallocate a bunch of lock_class_key
On Mon, Jun 29, 2015 at 10:03:09PM +0800, Nicolas Boichat wrote:
> regmap instances are kalloc'ed, so they cannot contain the
> lock_class_key, which needs to be statically allocated (in .data).
> Another option would be to preallocate a bunch of lock_class_key in
> regmap.c, and pick from that, b
On Mon, Jun 29, 2015 at 02:59:57PM +0200, Lars-Peter Clausen wrote:
> Maybe we are just over-thinking this and should just add one key to each
> regmap instance. That solves the issue without requiring the any user
> interaction. The only downside is that it might impact the performance of
> lockd
On 06/29/2015 04:03 PM, Nicolas Boichat wrote:
On Mon, Jun 29, 2015 at 8:59 PM, Lars-Peter Clausen wrote:
On 06/29/2015 02:51 PM, Nicolas Boichat wrote:
On Fri, Jun 26, 2015 at 11:16 AM, Nicolas Boichat
wrote:
On Fri, Jun 26, 2015 at 12:08 AM, Mark Brown wrote:
[...]
As far as I can te
On Mon, Jun 29, 2015 at 8:59 PM, Lars-Peter Clausen wrote:
> On 06/29/2015 02:51 PM, Nicolas Boichat wrote:
>>
>> On Fri, Jun 26, 2015 at 11:16 AM, Nicolas Boichat
>> wrote:
>>>
>>>
>>> On Fri, Jun 26, 2015 at 12:08 AM, Mark Brown wrote:
>>> [...]
>>
>> As far as I can tell we're likely
On 06/29/2015 02:51 PM, Nicolas Boichat wrote:
On Fri, Jun 26, 2015 at 11:16 AM, Nicolas Boichat wrote:
On Fri, Jun 26, 2015 at 12:08 AM, Mark Brown wrote:
[...]
As far as I can tell we're likely to end up needing a key per regmap or
something similar.
Since the number of lockdep classes
On Fri, Jun 26, 2015 at 11:16 AM, Nicolas Boichat wrote:
>
> On Fri, Jun 26, 2015 at 12:08 AM, Mark Brown wrote:
> [...]
> >> >As far as I can tell we're likely to end up needing a key per regmap or
> >> >something similar.
> >
> >> Since the number of lockdep classes itself is also limited we sh
On 06/26/2015 04:34 AM, Nicolas Boichat wrote:
On Thu, Jun 25, 2015 at 11:59 PM, Lars-Peter Clausen wrote:
[...]
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 116655d..09aaaf5 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -135,6 +135,12 @@ typedef vo
On Fri, Jun 26, 2015 at 12:08 AM, Mark Brown wrote:
[...]
>> >As far as I can tell we're likely to end up needing a key per regmap or
>> >something similar.
>
>> Since the number of lockdep classes itself is also limited we should avoid
>> creating extra lockdep classes when we can. I think the ap
On Thu, Jun 25, 2015 at 11:59 PM, Lars-Peter Clausen wrote:
> [...]
>>
>> diff --git a/include/linux/regmap.h b/include/linux/regmap.h
>> index 116655d..09aaaf5 100644
>> --- a/include/linux/regmap.h
>> +++ b/include/linux/regmap.h
>> @@ -135,6 +135,12 @@ typedef void (*regmap_unlock)(void *);
>>
On Thu, Jun 25, 2015 at 05:47:41PM +0200, Lars-Peter Clausen wrote:
> On 06/25/2015 05:33 PM, Mark Brown wrote:
> >It depends on what you use as the key for the nested locking stuff. If
> >you assign a key per regmap (casting the pointer to an integer, using an
> >IDR or something). I don't know
[...]
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 116655d..09aaaf5 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -135,6 +135,12 @@ typedef void (*regmap_unlock)(void *);
* @lock_arg: this field is passed as the only argument of lock/unlock
*
On 06/25/2015 05:33 PM, Mark Brown wrote:
On Thu, Jun 25, 2015 at 05:03:00PM +0200, Lars-Peter Clausen wrote:
On 06/25/2015 03:21 PM, Arjan van de Ven wrote:
wouldn't it be better to use the mutex_lock_nested() and co to explicitly
express your hierarchy?
That would require that the hierar
On Thu, Jun 25, 2015 at 05:03:00PM +0200, Lars-Peter Clausen wrote:
> On 06/25/2015 03:21 PM, Arjan van de Ven wrote:
> >wouldn't it be better to use the mutex_lock_nested() and co to explicitly
> >express your hierarchy?
> That would require that the hierarchy is known in advance. The hierarchy
On Thu, Jun 25, 2015 at 05:35:03PM +0800, Nicolas Boichat wrote:
> I'm trying to revive Antti's patch [1], as we are hitting similar issue
> with rt5677 driver. I only updated the commit message and documentation,
> I kept both Signed-off-by and From lines, with a small note highlighting
> my chan
On 06/25/2015 03:21 PM, Arjan van de Ven wrote:
On 6/25/2015 2:35 AM, Nicolas Boichat wrote:
From: Antti Palosaari
Lockdep validator complains about recursive locking and deadlock
when two different regmap instances are called in a nested order.
That happens anytime a regmap read/write call ne
On Thu, Jun 25, 2015 at 06:21:43AM -0700, Arjan van de Ven wrote:
Please fix your mailer to word wrap within paragraphs.
> wouldn't it be better to use the mutex_lock_nested() and co to
> explicitly express your hierarchy?
That was one of my original suggestions - one of the problems with this
c
On 6/25/2015 2:35 AM, Nicolas Boichat wrote:
From: Antti Palosaari
Lockdep validator complains about recursive locking and deadlock
when two different regmap instances are called in a nested order.
That happens anytime a regmap read/write call needs to access
another regmap.
This is because, f
23 matches
Mail list logo
