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 -- 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
