On Mon, 2013-08-05 at 11:26 +0200, Jiri Kosina wrote: 

On Fri, 2 Aug 2013, Benjamin Tissoires wrote:

quoted

quoted

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 [off-list ref]
Intel Finland Oy