diff mbox

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

Message ID 20140109222546.GA20994@core.coreip.homeip.net (mailing list archive)
State New, archived
Headers show

Commit Message

Dmitry Torokhov Jan. 9, 2014, 10:25 p.m. UTC
On Thu, Jan 09, 2014 at 02:11:00PM -0800, Christopher Heiny wrote:
> 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>

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(-)

Comments

Christopher Heiny Jan. 9, 2014, 10:47 p.m. UTC | #1
On 01/09/2014 02:25 PM, Dmitry Torokhov wrote:
> 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;
>   }

It's just plain freaky that no problem ever arose from that, but 
definitely it's a bug.

Acked-by: Christopher Heiny <cheiny@synaptics.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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;
 }