Re: [PATCH v2] input: synaptics-rmi4 - use snprintf instead of sprintf in rmi_i2c.c

[Christopher Heiny <cheiny@synaptics.com>]

On 01/09/2014 01:38 PM, Christopher Heiny wrote:
> On 01/09/2014 01:29 PM, Dmitry Torokhov wrote:
>> On Thu, Jan 09, 2014 at 01:23:37PM -0800, Christopher Heiny wrote:
>>> >On 01/09/2014 12:04 AM, Dmitry Torokhov wrote:
>>>> > >On Wed, Jan 08, 2014 at 05:18:39PM -0800, Christopher Heiny wrote:
>>>>> > >>This is a trivial change to replace the sprintf loop with
>>>>> snprintf using
>>>>> > >>up-to-date format capability.
>>>> > >
>>>> > >Hmm, how about we do this instead:
>>>> > >
>>>> > >Input: synaptics-rmi4 - clean up debug handling in rmi_i2c
>>>> > >
>>>> > >From: Dmitry Torokhov<dmitry.torokhov@gmail.com>
>>>> > >
>>>> > >Kernel now has standard facility to format and print binary
>>>> buffers, let's
>>>> > >use it. By doing so we no longer need to allocate memory for
>>>> debug buffers
>>>> > >and we can let debugfs code go as well.
>>> >
>>> >Not sure where to put this comment, so I'll drop it here.
>>> >
>>> >I agree the buffers can go.  I realized that on the drive home last
>>> >night, but was too tired to follow up.
>>> >
>>> >Talking with some of the folks who use this feature, there's a
>>> >desire to keep some sort of finer control on whether the comms
>>> >buffers are printed or not - either the existing debugfs setup
>>> >(preferred, since it lets them turn on the dmesg clutter only when
>>> >needed), or by converting to a config option such as
>>> >CONFIG_RMI4_COMMS_DEBUG.  It's very useful in new platform
>>> >development, since there's a surprising number of ways in which the
>>> >reads and writes can go wonky on new hardware.
>  >
>> That is why you have CONFIG_DYNAMIC_DEBUG: you can activate these debug
>> statements at will using the common kernel mechanisms.
>
> I'll check this out and get back.

Looks CONFIG_DYNAMIC_DEBUG will work fine!

Acked-by: Christopher Heiny <cheiny@synaptics.com>