From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752298AbbF2Pde (ORCPT ); Mon, 29 Jun 2015 11:33:34 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:60706 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752879AbbF2PdZ (ORCPT ); Mon, 29 Jun 2015 11:33:25 -0400 Date: Mon, 29 Jun 2015 16:32:56 +0100 From: Mark Brown To: Arjan van de Ven Cc: Nicolas Boichat , Lars-Peter Clausen , Mauro Carvalho Chehab , Antti Palosaari , Ingo Molnar , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Bard Liao , Oder Chiou , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, Anatol Pomozov Message-ID: <20150629153256.GF11162@sirena.org.uk> References: <558C1824.8020204@metafoo.de> <20150625153325.GR14071@sirena.org.uk> <558C229D.4090409@metafoo.de> <20150625160817.GT14071@sirena.org.uk> <5591414D.6080802@metafoo.de> <20150629142215.GE11162@sirena.org.uk> <559157A8.2050206@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cpvLTH7QU4gwfq3S" Content-Disposition: inline In-Reply-To: <559157A8.2050206@linux.intel.com> X-Cookie: Stay together, drag each other down. User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [RFC PATCH 1/2] regmap: add configurable lock class key for lockdep X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --cpvLTH7QU4gwfq3S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. --cpvLTH7QU4gwfq3S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVkWUnAAoJECTWi3JdVIfQBbQH/1iuhp1iJAfXibBg9bDpxeoJ vKRp8IKAqfP9X0+icuRvZnad4IoEbZj/xdnsh8uKA1PzWzsr5hHyUf0BsDzKcGKu 8l2DdKxbr7KnYVlCP7WWZ3hHWdFPJOlZwjVd9EidMzWel3ci7YRrX8cQKKGPGjV7 E+hReDUeG/VNpAMNyfJ5DJPm6ZJMXTKc+is1DdWsWvraHoo3TEHPiEgYIXrCe4z8 R1t03Y8Hb9nJMkFe59zS4P4483Ttqyf7S+X/b/gMDM1xKFcEE0IIsMwnhq36uPT2 bTTw6xEMCuIx0lCATHKnngf/AkAPh7VEIPdbur/ZUBVUbcOFeEBIfciXDKMM3iA= =WvMf -----END PGP SIGNATURE----- --cpvLTH7QU4gwfq3S--