All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: Guenter Roeck <linux@roeck-us.net>
Cc: "Peter Hüwe" <PeterHuewe@gmx.de>,
	linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Question about hwmon_attr_show_string
Date: Tue, 7 Mar 2017 10:08:46 +0100	[thread overview]
Message-ID: <20170307100846.0487135b@endymion> (raw)
In-Reply-To: <20170306234755.GA16512@roeck-us.net>

Hi Guenter,

On Mon, 6 Mar 2017 15:47:55 -0800, Guenter Roeck wrote:
> On Mon, Mar 06, 2017 at 09:48:35PM +0100, Peter Hüwe wrote:
> > Hi Guenter,
> > 
> > I was wondering whether there was a particular reason why 
> > hwmon_attr_show_string passes only an "empty" pointer(pointer) to the ops-
> > >read_string function rather than the buffer itself?
> > 
> > Wouldn't this mean that in ops->read_string I'd have to reserve some space for 
> > the value on the heap (and taking care to free it somewhere, since returning 
> > an address on the stack is bad idea), instead of calling sprintf(buf, "%s\n", 
> > s) directly?
> > 
> > With the current implementation I have to sprintf it into my local buffer and 
> > you sprintf it again into the final buffer.
>
> The idea was that the called code would return a pointer to a constant string,
> ie one that isn't changing from call to call.

In that case, what about the following change?

Subject: hwmon: Constify str parameter of hwmon_ops->read_string

The read_string callback is supposed to retrieve a pointer to a
constant string.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
---
 drivers/hwmon/hwmon.c |    2 +-
 include/linux/hwmon.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-4.10.orig/drivers/hwmon/hwmon.c	2017-02-19 23:34:00.000000000 +0100
+++ linux-4.10/drivers/hwmon/hwmon.c	2017-03-07 08:22:27.784527968 +0100
@@ -186,7 +186,7 @@ static ssize_t hwmon_attr_show_string(st
 				      char *buf)
 {
 	struct hwmon_device_attribute *hattr = to_hwmon_attr(devattr);
-	char *s;
+	const char *s;
 	int ret;
 
 	ret = hattr->ops->read_string(dev, hattr->type, hattr->attr,
--- linux-4.10.orig/include/linux/hwmon.h	2017-02-19 23:34:00.000000000 +0100
+++ linux-4.10/include/linux/hwmon.h	2017-03-07 08:21:28.247998585 +0100
@@ -336,7 +336,7 @@ struct hwmon_ops {
 	int (*read)(struct device *dev, enum hwmon_sensor_types type,
 		    u32 attr, int channel, long *val);
 	int (*read_string)(struct device *dev, enum hwmon_sensor_types type,
-		    u32 attr, int channel, char **str);
+		    u32 attr, int channel, const char **str);
 	int (*write)(struct device *dev, enum hwmon_sensor_types type,
 		     u32 attr, int channel, long val);
 };


-- 
Jean Delvare
SUSE L3 Support

  reply	other threads:[~2017-03-07  9:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-03  0:33 Conversion of w83627ehf to hwmon_device_register_with_info ? Peter Hüwe
2017-03-03  2:56 ` Guenter Roeck
2017-03-21 10:46   ` Peter Hüwe
2017-03-21 13:35     ` Guenter Roeck
2017-03-23  1:11       ` Peter Hüwe
2017-03-03 10:52 ` Jean Delvare
2017-03-06 20:48 ` Question about hwmon_attr_show_string Peter Hüwe
2017-03-06 23:47   ` Guenter Roeck
2017-03-07  9:08     ` Jean Delvare [this message]
2017-03-07  9:14       ` Peter Huewe
2017-03-07  9:14         ` Peter Huewe
2017-03-07 14:16       ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170307100846.0487135b@endymion \
    --to=jdelvare@suse.de \
    --cc=PeterHuewe@gmx.de \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.