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

On Thu, Jan 09, 2014 at 02:11:00PM -0800, Christopher Heiny wrote:

On 01/09/2014 01:38 PM, Christopher Heiny wrote:

quoted

On 01/09/2014 01:29 PM, Dmitry Torokhov wrote:

quoted

On Thu, Jan 09, 2014 at 01:23:37PM -0800, Christopher Heiny wrote:

quoted

quoted

On 01/09/2014 12:04 AM, Dmitry Torokhov wrote:

quoted

quoted

On Wed, Jan 08, 2014 at 05:18:39PM -0800, Christopher Heiny wrote:

quoted

quoted

This is a trivial change to replace the sprintf loop with

snprintf using

quoted

quoted

quoted

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

quoted

quoted

use it. By doing so we no longer need to allocate memory for

debug buffers

quoted

quoted

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

Cool, thanks! And another one:

Input: synaptics-rmi4 - fix disabling gpio config in i2c transport

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

We need to pass into pdata->gpio_config() gpio_data which is already a
pointer, and not its address.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/input/rmi4/rmi_i2c.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index ebe74ec..12aea8c 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c

@@ -168,7 +168,8 @@ exit:
 static int rmi_i2c_probe(struct i2c_client *client,
 			 const struct i2c_device_id *id)
 {
-	const struct rmi_device_platform_data *pdata = dev_get_platdata(&client->dev);
+	const struct rmi_device_platform_data *pdata =
+				dev_get_platdata(&client->dev);
 	struct rmi_transport_dev *xport;
 	struct rmi_i2c_data *data;
 	int retval;

@@ -250,12 +251,13 @@ err_gpio:
 static int rmi_i2c_remove(struct i2c_client *client)
 {
 	struct rmi_transport_dev *xport = i2c_get_clientdata(client);
-	struct rmi_device_platform_data *pdata = dev_get_platdata(&client->dev);
+	const struct rmi_device_platform_data *pdata =
+				dev_get_platdata(&client->dev);
 
 	rmi_unregister_transport_device(xport);
 
 	if (pdata->gpio_config)
-		pdata->gpio_config(&pdata->gpio_data, false);
+		pdata->gpio_config(pdata->gpio_data, false);
 
 	return 0;
 }

-- 
Dmitry