On 2016-09-18 21:45, Bartosz Golaszewski wrote: > 2016-09-18 21:43 GMT+02:00 Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>: >> 2016-09-18 10:52 GMT+02:00 Peter Rosin <peda@xxxxxxxxxx>: >>> On 2016-09-16 19:58, Wolfram Sang wrote: >>>> >>>> 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? >> >> Wouldn't it be enough to have a separate class for every base (as in: >> not having any parent adapters) i2c adapter? >> > > Eeek -ESENTTOOEARLY > > Of course not - since we could have two branches deeper on the tree > with the same problem. > > Nevermind my last e-mail. Right, but you have a point, we can avoid some lockdep classes if we work at it. We could recognize that no gpio-expander can be involved with muxing for a gpio-expander sitting on a root i2c adapter. That much is trivially obvious. That means that we could treat all gpio-expanders sitting directly on a root i2c-adapter as we always have, just like v1 (and v2, implicitly) do, but instead of putting all other gpio-exanders in one lockdep class (as in v1) or in one lockdep class per depth (as in v2), we put all other gpio-mutexes in a lockdep class of their own. Then we do not get any extra lockdep classes unless there are i2c muxes, which is better. But only i2c-mux-gpio can cause the recursion. I think the theoretical minimal number of lockdep classes is to create a new lockdep class for every i2c-mux-gpio instance. gpio-expanders needing a mutex could walk up the adapter tree looking for a i2c-mux-gpio and getting the lockdep class from there. If the root i2c adapter is reached, use some default lockdep class. That would consolidate muxes from different gpio-expander drivers into the one lockdep class. I don't know if that is a big no-no? I guess that can be handled too with more code, but it is starting to get messy... Or, do what the i2c-mux code is doing and use an rt_mutex instead of an ordinary mutex. That way you are very sure to not get any lockdep splat ... at all. Ok, sorry, that was not a serious suggestion, but it would be a tad bit simpler to implement... Cheers, Peter -- 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
