All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Muir <john@jmuir.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Mark Rutland <mark.rutland@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	Linux List <linux-kernel@vger.kernel.org>,
	linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH 1/3] hwmon: Add Texas Instruments TMP108 temperature sensor driver.
Date: Mon, 28 Nov 2016 11:40:42 -0800	[thread overview]
Message-ID: <EDC5A938-C5F5-45A4-85BD-C19996BA6460@jmuir.com> (raw)
In-Reply-To: <c0f07695-e823-5974-829c-6fd64bd97a5b@roeck-us.net>


> On Nov 27, 2016, at 4:19 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> 
> On 11/26/2016 09:15 PM, John Muir wrote:
>> Add support for the TI TMP108 temperature sensor with some device
>> configuration parameters.
>> +- ti,alert-active-high : (boolean) make the alert pin active-high instead of
>> +      the default active-low.
> 
> The driver doesn't support interrupts/alerts. Do those properties really add value ?
Getting ahead of myself. I will create a patch for this in the future.

>> +static void tmp108_update_ready_time(struct tmp108 *tmp108)
>> +{
>> +	tmp108->ready_time = jiffies;
>> +	if ((tmp108->config & TMP108_CONF_MODE_MASK)
>> +	    == TMP108_MODE_CONTINUOUS) {
> 
> Don't you want a "!" here ? Presumably the delay is only needed
> if the original configuration was not for continuous mode.
> 
>> +		tmp108->ready_time +=
>> +			msecs_to_jiffies(TMP108_CONVERSION_TIME_MS);
>> +	}
>> +}
The delay is required for both really. When the device is set into continuous mode it starts converting and the first temperature is ready (just under) 30ms later.

For the (unsupported at this time) one-shot mode, there would likewise be a delay, but I was envisioning having the requesting task sleep while waiting for the data to be ready, rather than get an -EAGAIN until the data is ready. 

>> +	hwmon_dev = hwmon_device_register_with_groups(dev, client->name,
>> +						      tmp108, tmp108_groups);
> 
> Please consider using the devm_ function here.
> 
>> +	if (IS_ERR(hwmon_dev)) {
>> +		dev_dbg(dev, "unable to register hwmon device\n");
>> +		return PTR_ERR(hwmon_dev);
>> +	}
>> +
>> +	tmp108->hwmon_dev = hwmon_dev;
>> +	tmp108->tz = thermal_zone_of_sensor_register(hwmon_dev, 0, hwmon_dev,
>> +						     &tmp108_of_thermal_ops);
>> +	if (IS_ERR(tmp108->tz))
>> +		return PTR_ERR(tmp108->tz);
> 
> hwmon device not unregistered here. That would be fixed by using the devm
> function above.
> 
For the above two registrations and .remove function, I was worried that there would be an order problem between the i2c->remove and the device-managed cleanup. I’ll get deeper into that code to determine if that is a problem.

For your other comments, I will make the necessary changes.

Thanks!

John.

  reply	other threads:[~2016-11-28 19:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-27  5:15 [PATCH 1/3] hwmon: Add Texas Instruments TMP108 temperature sensor driver John Muir
2016-11-27  5:15 ` [PATCH 2/3] hwmon: tmp108: Use devm variants of registration interfaces John Muir
2016-11-27 12:21   ` Guenter Roeck
2016-11-27  5:15 ` [PATCH 3/3] hwmon: tmp108: Update driver to use hwmon_chip_info John Muir
2016-11-27 23:00   ` Guenter Roeck
2016-11-28  2:10     ` John Muir
2016-11-28  3:25       ` Guenter Roeck
2016-11-27 12:19 ` [PATCH 1/3] hwmon: Add Texas Instruments TMP108 temperature sensor driver Guenter Roeck
2016-11-28 19:40   ` John Muir [this message]
2016-11-28 19:58     ` Guenter Roeck
2016-11-28 21:25       ` John Muir
2016-11-28 22:19         ` Guenter Roeck
2016-11-28 23:10           ` John Muir
2016-11-28 23:33             ` 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=EDC5A938-C5F5-45A4-85BD-C19996BA6460@jmuir.com \
    --to=john@jmuir.com \
    --cc=corbet@lwn.net \
    --cc=jdelvare@suse.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.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 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.