On Tue, Sep 20, 2016 at 12:07:39PM +0200, Bartosz Golaszewski wrote: > 2016-09-20 10:48 GMT+02:00 Peter Rosin <peda@xxxxxxxxxx>: > > > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
