All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Rosin <peda@axentia.se>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Alexandre Courbot <gnurou@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Vignesh R <vigneshr@ti.com>, Yong Li <yong.b.li@intel.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-i2c <linux-i2c@vger.kernel.org>,
	linux-gpio <linux-gpio@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/4] gpio: fix an incorrect lockdep warning
Date: Sun, 18 Sep 2016 10:52:58 +0200	[thread overview]
Message-ID: <587cdb60-d7fe-3ab2-b635-02c5072e102e@axentia.se> (raw)
In-Reply-To: <20160916175842.GD1426@katana>

On 2016-09-16 19:58, Wolfram Sang wrote:
> 
>>> Looks good from my POV, but will wait for Peter to comment.
>>>
>>> If accepted, I'd think this should go via my I2C tree and I would like
>>> to ask Linus to ack patch 4. D'accord, everyone?
>>
>> Since it is not clear if "Peter" is me or PeterZ (I suspect PeterZ...),
> 
> Nope, I meant you :) I really value your input, it especially helps me
> on topics like locking, nesting, muxing... etc. Much appreciated, thanks
> a lot for doing that!
> 
>> I'm just adding that it all looks fine by me as well, just to prevent
>> this from being held up by a misunderstanding.
> 
> OK. I read this as Acked-by.
> 
>> It does unconditionally add a new function to i2c-core that is only
>> ever used if lockdep is enabled, but it is tiny and I'm not bothered
>> by that memory waste.
> 
> Same here. And if it prevents us from false positive lockdep reports, I
> am all for fixing it.

Except it doesn't, when I think some more about it...

If you have two gpio-expanders on the same depth but on different i2c
branches you still end up with a splat if one is used to control a mux
to reach the other.

The only way to solve it for good, that I see, is to have every instance
of the gpio-expander mutex in its own class. That might lead to many
lockdep classes but then again, how many gpio expanders could there be
in a system? A dozen or two seems extreme, so maybe that is the correct
approach anyway?

Cheers,
Peter


  reply	other threads:[~2016-09-18 18:25 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-16 16:02 [PATCH v2 0/4] gpio: fix an incorrect lockdep warning Bartosz Golaszewski
2016-09-16 16:02 ` [PATCH v2 1/4] i2c: export i2c_adapter_depth() Bartosz Golaszewski
2016-09-16 16:02 ` [PATCH v2 2/4] lockdep: make MAX_LOCKDEP_SUBCLASSES unconditionally visible Bartosz Golaszewski
2016-09-16 16:02 ` [PATCH v2 3/4] i2c: add a warning to i2c_adapter_depth() Bartosz Golaszewski
2016-09-16 16:02 ` [PATCH v2 4/4] gpio: pca953x: fix an incorrect lockdep warning Bartosz Golaszewski
2016-09-21  5:45   ` Wolfram Sang
2016-09-23  8:10     ` Linus Walleij
2016-09-24  8:55       ` Wolfram Sang
2016-09-24  9:15   ` Wolfram Sang
2016-09-24 14:26     ` Geert Uytterhoeven
2016-09-16 17:26 ` [PATCH v2 0/4] gpio: " Wolfram Sang
2016-09-16 17:45   ` Peter Rosin
2016-09-16 17:58     ` Wolfram Sang
2016-09-18  8:52       ` Peter Rosin [this message]
2016-09-18 19:43         ` Bartosz Golaszewski
2016-09-18 19:45           ` Bartosz Golaszewski
2016-09-19  8:01             ` Peter Rosin
2016-09-19  8:14               ` Peter Zijlstra
2016-09-19  8:48                 ` Peter Rosin
2016-09-19  9:03                   ` Peter Zijlstra
2016-09-20  8:48                     ` Peter Rosin
2016-09-20 10:07                       ` Bartosz Golaszewski
2016-09-20 10:28                         ` Peter Zijlstra
2016-09-20 10:48                         ` Peter Rosin
2016-09-20 11:30                           ` Geert Uytterhoeven
2016-09-20 12:32                             ` Bartosz Golaszewski
2016-09-20 15:33                       ` Thomas Gleixner
2016-09-21  9:47                         ` Peter Rosin
2016-09-17  1:19 ` Peter Zijlstra
2016-09-17 10:18   ` Wolfram Sang
2016-09-17 18:59     ` Bartosz Golaszewski
2016-09-24  8:56 ` Wolfram Sang

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=587cdb60-d7fe-3ab2-b635-02c5072e102e@axentia.se \
    --to=peda@axentia.se \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=geert+renesas@glider.be \
    --cc=gnurou@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=vigneshr@ti.com \
    --cc=wsa@the-dreams.de \
    --cc=yong.b.li@intel.com \
    /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.