On Mon, 2013-08-05 at 11:26 +0200, Jiri Kosina wrote: > On Fri, 2 Aug 2013, Benjamin Tissoires wrote: > > > > With only one condition if dynamic debug is enabled in kernel. > > > So, it would be nice to gather opinions, however, the decision is > > > totally depends on type of user who wants to debug the module. > > > > > Yep, I agree that Jiri's opinion would be helpful. > > > > Meanwhile, we could also wait a little for more i2c-hid to hit the > > market and to be widely tested, and then remove the debug flag. We > > should also remove the debug events in get_i2c_hid_get_input() which > > would pollute systems without dynamic debugging but with the DEBUG > > config still enabled. > > Well, it doesn't seem to make too much sense to me to have generic/bus use > hid_dbg() (although it's used very rarely) and a "sub-driver" use > something else. > > Basically the options I see: > > - keep i2c-hid as is > - convert the whole drivers/hid to dev_dbg() > - introduce another hid debugfs file in parallel to rdesc and events for > these types of messages Debugfs could be off in the kernel configuration. Whatever we choose there will be a kernel that has a disabled option which prevents to debug: either debugging is turned off, or driver itself. There is another possibility as well: instead of dev_dbg() we may add trace points and subscribe to them from userspace via perf, for example. -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
