From: Guenter Roeck <linux@roeck-us.net>
To: Quentin Schulz <quentin.schulz@free-electrons.com>,
jdelvare@suse.com, jic23@kernel.org, knaack.h@gmx.de,
lars@metafoo.de, pmeerw@pmeerw.net,
maxime.ripard@free-electrons.com, wens@csie.org,
lee.jones@linaro.org
Cc: linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org,
linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
thomas.petazzoni@free-electrons.com,
antoine.tenart@free-electrons.com
Subject: Re: [PATCH v2 4/4] hwmon: iio: add label for channels read by iio_hwmon
Date: Fri, 15 Jul 2016 19:53:32 -0700 [thread overview]
Message-ID: <5789A1AC.1020706@roeck-us.net> (raw)
In-Reply-To: <5788F506.3040809@free-electrons.com>
On 07/15/2016 07:36 AM, Quentin Schulz wrote:
> On 15/07/2016 16:03, Guenter Roeck wrote:
>> On 07/15/2016 02:59 AM, Quentin Schulz wrote:
> [...]
>>> +static ssize_t iio_hwmon_read_label(struct device *dev,
>>> + struct device_attribute *attr,
>>> + char *buf)
>>> +{
>>> + struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
>>> + struct iio_hwmon_state *state = dev_get_drvdata(dev);
>>> + const char *label =
>>> state->channels[sattr->index].channel->extend_name;
>>> +
>>> + if (label)
>>> + return sprintf(buf, "%s\n", label);
>>> +
>> Can the name disappear on the fly, or be changed on the fly ?
>> Then this is unusable. We should and can only provide labels
>> if a name exists and is permanent. Otherwise all we do is
>> to confuse user space.
>
> It cannot, the extend_name field is const char* in the struct:
> http://lxr.free-electrons.com/source/include/linux/iio/iio.h#L247
>
Then why "if(label)" ?
> [...]
>>> @@ -107,6 +123,18 @@ static int iio_hwmon_probe(struct platform_device
>>> *pdev)
>>> }
>>>
>>> sysfs_attr_init(&a->dev_attr.attr);
>>> +
>>> + b = NULL;
>>> + if (st->channels[i].channel->extend_name) {
>>> + b = devm_kzalloc(dev, sizeof(*b), GFP_KERNEL);
>>> + if (b == NULL) {
>>> + ret = -ENOMEM;
>>> + goto error_release_channels;
>>> + }
>>> +
>>> + sysfs_attr_init(&b->dev_attr.attr);
>>
>> Why is this initialization here and not with the rest of the initialization
>> of this attribute ?
>
> I don't get your question. I've followed the exact same pattern as for
> "a" variable's initialization.
> The initialization is before the switch case because the name of the
> exposed sysfs file depends on the type of the IIO channel. If I move the
> initialization in the switch case, I'll have duplicated code.
>
Yes, but that didn't require all those if statements.
>>> + }
>>> +
>>> ret = iio_get_channel_type(&st->channels[i], &type);
>>> if (ret < 0)
>>> goto error_release_channels;
>>> @@ -115,35 +143,66 @@ static int iio_hwmon_probe(struct
>>> platform_device *pdev)
>>> case IIO_VOLTAGE:
>>> a->dev_attr.attr.name = kasprintf(GFP_KERNEL,
>>> "in%d_input",
>>> - in_i++);
>>> + in_i);
>>> + if (b)
>>> + b->dev_attr.attr.name = kasprintf(GFP_KERNEL,
>>> + "in%d_label",
>>> + in_i);
>>> + in_i++;
>>> break;
>>> case IIO_TEMP:
>>> a->dev_attr.attr.name = kasprintf(GFP_KERNEL,
>>> "temp%d_input",
>>> - temp_i++);
>>> + temp_i);
>>> +
>>> + if (b)
>>> + b->dev_attr.attr.name = kasprintf(GFP_KERNEL,
>>> + "temp%d_label",
>>> + temp_i);
>>> + temp_i++;
>>> break;
>>> case IIO_CURRENT:
>>> a->dev_attr.attr.name = kasprintf(GFP_KERNEL,
>>> "curr%d_input",
>>> - curr_i++);
>>> + curr_i);
>>> +
>>> + if (b)
>>> + b->dev_attr.attr.name = kasprintf(GFP_KERNEL,
>>> + "curr%d_label",
>>> + curr_i);
>>> + curr_i++;
>>> break;
>>> case IIO_HUMIDITYRELATIVE:
>>> a->dev_attr.attr.name = kasprintf(GFP_KERNEL,
>>> "humidity%d_input",
>>> - humidity_i++);
>>> + humidity_i);
>>> +
>>> + if (b)
>>> + b->dev_attr.attr.name = kasprintf(GFP_KERNEL,
>>> + "humidity%d_label",
>>> + humidity_i);
>>> + humidity_i++;
>>> break;
>>> default:
>>> ret = -EINVAL;
>>> goto error_release_channels;
>>> }
>>> - if (a->dev_attr.attr.name == NULL) {
>>> + if (a->dev_attr.attr.name == NULL ||
>>> + (b && b->dev_attr.attr.name == NULL)) {
>>> ret = -ENOMEM;
>>> goto error_release_channels;
>>> }
>>
>> Just realized that we have a memory leak here. The 'name' memory is
>> never released.
>>
>
> I don't know if we have to do something to revert the effects of
> sysfs_attr_init but you sure are right that the a and b's attribute's
> name is never freed. This case would be handled with devm_kasprintf, I
> guess? Thanks.
>
>>> a->dev_attr.show = iio_hwmon_read_val;
>>> a->dev_attr.attr.mode = S_IRUGO;
>>> a->index = i;
>>> - st->attrs[i] = &a->dev_attr.attr;
>>> + st->attrs[j++] = &a->dev_attr.attr;
>>> +
>>> + if (b) {
sysfs_attr_init() might be better here to keep the initialization of '*b'
as close together as possible.
Guenetr
>>> + b->dev_attr.show = iio_hwmon_read_label;
>>> + b->dev_attr.attr.mode = S_IRUGO;
>>> + b->index = i;
>>> + st->attrs[j++] = &b->dev_attr.attr;
>>> + }
>>> }
>>>
>>> st->attr_group.attrs = st->attrs;
>>>
>>
>
> Quentin
>
next prev parent reply other threads:[~2016-07-16 2:54 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-15 9:59 [PATCH v2 0/4] add support for Allwinner SoCs ADC Quentin Schulz
2016-07-15 9:59 ` [PATCH v2 1/4] hwmon: iio_hwmon: defer probe when no channel is found Quentin Schulz
2016-07-16 17:00 ` [v2,1/4] " Guenter Roeck
2016-07-18 10:02 ` Maxime Ripard
2016-07-18 13:29 ` Guenter Roeck
2016-07-15 9:59 ` [PATCH v2 2/4] iio: adc: add support for Allwinner SoCs ADC Quentin Schulz
2016-07-18 12:57 ` Maxime Ripard
2016-07-19 9:04 ` Quentin Schulz
2016-07-19 12:40 ` Maxime Ripard
2016-07-18 13:18 ` Jonathan Cameron
2016-07-19 8:33 ` Quentin Schulz
2016-07-20 14:57 ` Jonathan Cameron
2016-07-21 12:15 ` Quentin Schulz
2016-07-23 6:37 ` Jonathan Cameron
2016-07-20 12:37 ` Quentin Schulz
2016-07-20 14:15 ` Crt Mori
2016-07-20 14:59 ` Jonathan Cameron
2016-07-15 9:59 ` [PATCH v2 3/4] mfd: " Quentin Schulz
2016-07-18 13:02 ` Maxime Ripard
2016-07-19 12:04 ` Quentin Schulz
2016-07-18 13:25 ` Jonathan Cameron
2016-07-19 7:31 ` Lee Jones
2016-07-20 15:01 ` Jonathan Cameron
2016-07-21 12:12 ` Lee Jones
2016-07-21 20:08 ` Maxime Ripard
2016-07-22 13:55 ` Lee Jones
2016-07-23 6:42 ` Jonathan Cameron
2016-07-25 9:55 ` Maxime Ripard
2016-07-19 8:35 ` Quentin Schulz
2016-07-15 9:59 ` [PATCH v2 4/4] hwmon: iio: add label for channels read by iio_hwmon Quentin Schulz
2016-07-15 14:03 ` Guenter Roeck
2016-07-15 14:36 ` Quentin Schulz
2016-07-16 2:53 ` Guenter Roeck [this message]
2016-07-18 12:24 ` Jonathan Cameron
2016-07-19 6:55 ` Quentin Schulz
2016-07-20 14:49 ` Jonathan Cameron
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=5789A1AC.1020706@roeck-us.net \
--to=linux@roeck-us.net \
--cc=antoine.tenart@free-electrons.com \
--cc=jdelvare@suse.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=pmeerw@pmeerw.net \
--cc=quentin.schulz@free-electrons.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=wens@csie.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox