On Fri, Jun 26, 2015 at 12:08 AM, Mark Brown <[email protected]> wrote: [...] >> >As far as I can tell we're likely to end up needing a key per regmap or >> >something similar. > >> Since the number of lockdep classes itself is also limited we should avoid >> creating extra lockdep classes when we can. I think the approach which >> having the option of specifying a lockdep class in the regmap config will be >> ok. The only case it can't handle if we nest instances with the same config, >> but I don't really see valid use scases for that at the moment. > > Oh, ffs. This just keeps getting better. I hadn't been aware of that > limitation. We still have the problem that this needs to be something > users can understand rather than something that's just "define something > here in one of your drivers if you're running into problems with > spurious warnings" here. That's always been the biggest problem here > (once we got past the "what is this supposed to do in the first place?" > issues).
I found that V4L2 uses separate lockdep classes for each of their v4l2_ctrl. This was introduced in 6cd247ef22e "[media] v4l2-ctrls: eliminate lockdep false alarms for struct v4l2_ctrl_handler.lock" (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd247ef22e), so we could possibly take that approach. On my system, I have: # cat /proc/lockdep_stats lock-classes: 1241 [max: 8191] direct dependencies: 7364 [max: 32768] indirect dependencies: 27686 all direct dependencies: 158097 dependency chains: 10011 [max: 65536] dependency chain hlocks: 38887 [max: 327680] in-hardirq chains: 92 in-softirq chains: 372 in-process chains: 9547 stack-trace entries: 107703 [max: 524288] So, at least on that platform, there is some room to grow... I'm just afraid that implementing this may require creating a bunch of macros to wrap all regmap_init_[i2c/spi/...] functions, as the lockdep classes need to be statically allocated... Unless we find a different solution than what V4L2 does. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
