All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Nicolas Boichat <drinkcat@chromium.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	Antti Palosaari <crope@iki.fi>, Ingo Molnar <mingo@redhat.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, Bard Liao <bardliao@realtek.com>,
	Oder Chiou <oder_chiou@realtek.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.de>,
	alsa-devel@alsa-project.org,
	Anatol Pomozov <anatol.pomozov@gmail.com>
Subject: Re: [RFC PATCH 1/2] regmap: add configurable lock class key for lockdep
Date: Mon, 29 Jun 2015 16:32:56 +0100	[thread overview]
Message-ID: <20150629153256.GF11162@sirena.org.uk> (raw)
In-Reply-To: <559157A8.2050206@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

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.

> (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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2015-06-29 15:33 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-25  9:35 [RFC PATCH 1/2] regmap: add configurable lock class key for lockdep Nicolas Boichat
2015-06-25  9:35 ` [RFC PATCH 2/2] ASoC: rt5677: Add lockdep class to silence lockdep warnings Nicolas Boichat
2015-06-25 13:21 ` [RFC PATCH 1/2] regmap: add configurable lock class key for lockdep Arjan van de Ven
2015-06-25 14:29   ` Mark Brown
2015-06-25 15:03   ` Lars-Peter Clausen
2015-06-25 15:03     ` Lars-Peter Clausen
2015-06-25 15:33     ` Mark Brown
2015-06-25 15:47       ` Lars-Peter Clausen
2015-06-25 15:47         ` Lars-Peter Clausen
2015-06-25 16:08         ` Mark Brown
2015-06-26  3:16           ` Nicolas Boichat
2015-06-26  3:16             ` Nicolas Boichat
2015-06-29 12:51             ` Nicolas Boichat
2015-06-29 12:59               ` Lars-Peter Clausen
2015-06-29 12:59                 ` Lars-Peter Clausen
2015-06-29 14:03                 ` Nicolas Boichat
2015-06-29 14:18                   ` Lars-Peter Clausen
2015-06-29 15:34                     ` Mark Brown
2015-06-30  4:56                       ` Nicolas Boichat
2015-06-30  4:56                         ` Nicolas Boichat
2015-06-30 11:02                         ` [alsa-devel] " Lars-Peter Clausen
2015-06-29 14:22                   ` Mark Brown
2015-06-29 14:35                     ` Arjan van de Ven
2015-06-29 15:32                       ` Mark Brown [this message]
2015-06-29 15:36                         ` Arjan van de Ven
2015-06-29 16:02                           ` Mark Brown
2015-06-29 14:19                 ` Mark Brown
2015-06-25 14:49 ` Mark Brown
2015-06-25 15:59 ` Lars-Peter Clausen
2015-06-26  2:34   ` Nicolas Boichat
2015-06-26  2:34     ` Nicolas Boichat
2015-06-26  8:31     ` Lars-Peter Clausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150629153256.GF11162@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=anatol.pomozov@gmail.com \
    --cc=arjan@linux.intel.com \
    --cc=bardliao@realtek.com \
    --cc=crope@iki.fi \
    --cc=drinkcat@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@osg.samsung.com \
    --cc=mingo@redhat.com \
    --cc=oder_chiou@realtek.com \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.