From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH v2 0/4] gpio: fix an incorrect lockdep warning Date: Tue, 20 Sep 2016 12:28:37 +0200 Message-ID: <20160920102837.GS5012@twins.programming.kicks-ass.net> References: <20160916175842.GD1426@katana> <587cdb60-d7fe-3ab2-b635-02c5072e102e@axentia.se> <2f7d572c-59e0-f584-9748-48a1a45a1a50@axentia.se> <20160919081413.GR5016@twins.programming.kicks-ass.net> <88940f9a-79bf-6c88-8e1d-f76f32dda04a@axentia.se> <20160919090358.GU5016@twins.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-gpio-owner@vger.kernel.org To: Bartosz Golaszewski Cc: Peter Rosin , Wolfram Sang , Linus Walleij , Alexandre Courbot , Andy Shevchenko , Vignesh R , Yong Li , Geert Uytterhoeven , Ingo Molnar , linux-i2c , linux-gpio , LKML List-Id: linux-i2c@vger.kernel.org On Tue, Sep 20, 2016 at 12:07:39PM +0200, Bartosz Golaszewski wrote: > 2016-09-20 10:48 GMT+02:00 Peter Rosin : > > > > One pretty simple problematic case is: > > > > .---. .----. > > | | | |-- i2c2 > > | |-- i2c0 --|mux0| .----. > > | l | | |-- i2c3 --|gpio| > > | i | '----' '----' > > | n | .--------------' > > | u | .----. .----. > > | x | | |-- i2c4 --|dev0| > > | |-- i2c1 --|mux1| '----' > > | | | |-- i2c5 > > '---' '----' Shees, and I suppose this is all external to SoC stuff, so people can stick on whatever they pretty well please. I mean, its an i2c bus, just order parts from ebay and stick on a board. > > Accesses to dev0 will: > > > > 1. lock i2c1:mux_lock (depth 0) > > 2. switch mux1 to i2c4 using gpio > > a lock i2c0:mux_lock (depth 0) > > b switch mux0 to i2c3 using whatever > > c access gpio > > d unlock i2c0:mux_lock > > 3. access dev0 > > 4. unlock i2c1:mux_lock > > > > 2a will cause a lockdep splat if i2c0:mux_lock is in the same > > lockdep class & subclass as i2c1:mux_lock. So, lockdep needs > > separate lockdep classes depending on the i2c root adapter > > (subclasses are needed to handle deeper trees, so they are off > > limits). Great fun. How do I go about creating a new lockdep > > class for every i2c root adapter instance? > > > > I feel like it's just wrong to set an arbitrary limit on the number of > i2c branches - and this is what the result of this approach would be. > > One solution that comes to mind is to have a separate, global set of > lock classes solely for gpio expanders. I think you mentioned earlier > that it's the only thing that can cause this kind of lockdep false > positives. We could potentially have a limited set of lock classes and > every expander that would need one would request it using some kind of > API ensuring that every instance gets a separate class. But this > sounds like a big hack too I'm afraid... And regmap would need to be > aware of that as well. > > Anyways, we're past rc7 already and 4.9 will be the next LTS kernel. > We have real hardware here that runs on mainline linux and is > suffering from this issue. Are there any objections against merging > this series now and continuing the work on improving the solution for > 4.10? Seems sensible, I'll also see if I can come up with a better annotation that can help here.