From: Guenter Roeck <linux@roeck-us.net>
To: Joshua Scott <joshua.scott@alliedtelesis.co.nz>
Cc: Jean Delvare <jdelvare@suse.com>,
linux-hwmon@vger.kernel.org,
Chris Packham <chris.packham@alliedtelesis.co.nz>
Subject: Re: [PATCH] hwmon: (lm73) Add temp1_max_hyst entry to sysfs
Date: Fri, 7 Oct 2016 11:44:10 -0700 [thread overview]
Message-ID: <20161007184410.GA10013@roeck-us.net> (raw)
In-Reply-To: <20161007044221.25577-1-joshua.scott@alliedtelesis.co.nz>
On Fri, Oct 07, 2016 at 05:42:21PM +1300, Joshua Scott wrote:
> Currently, the lm73 driver has a temp1_max and a temp1_min. These make
> sense when using temp1_max_alarm and temp1_min_alarm to determine if the
> temperature has exceeded the chosen limits.
>
> However, when using the ALARM output pin on the lm73 chip, the lower
> temperature value behaves as a hysteresis value. Rather than the low value
> triggering a "too cold" alarm, it is the point at which an existing high
> temperature alarm is turned off.
>
> Add a sysfs entry for temp1_max_hyst, tied to the same register as
> temp1_min.
>
Reading through the datasheet, resetting alert is really a side effect,
not really a hysteresis value. Hysteresis would be if THIGH would be
reset if the temperature goes below Tmin, but that is not the case.
It also looks like the alert bit should be reset by software, by
writing 1 into bit 3 of the configuration register.
Given that, I don't think we should change anything. One option,
though, might be to implement alert and/or interrupt support and handle
the alert condition as expected, ie send an event to user space and
reset the alert bit in the interrupt/alert handler.
Guenter
> Signed-off-by: Joshua Scott <joshua.scott@alliedtelesis.co.nz>
> ---
> drivers/hwmon/lm73.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/hwmon/lm73.c b/drivers/hwmon/lm73.c
> index 9653bb8..b46a91a 100644
> --- a/drivers/hwmon/lm73.c
> +++ b/drivers/hwmon/lm73.c
> @@ -170,6 +170,8 @@ abort:
>
> static SENSOR_DEVICE_ATTR(temp1_max, S_IWUSR | S_IRUGO,
> show_temp, set_temp, LM73_REG_MAX);
> +static SENSOR_DEVICE_ATTR(temp1_max_hyst, S_IWUSR | S_IRUGO,
> + show_temp, set_temp, LM73_REG_MIN);
> static SENSOR_DEVICE_ATTR(temp1_min, S_IWUSR | S_IRUGO,
> show_temp, set_temp, LM73_REG_MIN);
> static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO,
> @@ -184,6 +186,7 @@ static SENSOR_DEVICE_ATTR(temp1_min_alarm, S_IRUGO,
> static struct attribute *lm73_attrs[] = {
> &sensor_dev_attr_temp1_input.dev_attr.attr,
> &sensor_dev_attr_temp1_max.dev_attr.attr,
> + &sensor_dev_attr_temp1_max_hyst.dev_attr.attr,
> &sensor_dev_attr_temp1_min.dev_attr.attr,
> &sensor_dev_attr_update_interval.dev_attr.attr,
> &sensor_dev_attr_temp1_max_alarm.dev_attr.attr,
> --
> 2.9.3
>
prev parent reply other threads:[~2016-10-07 18:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-07 4:42 [PATCH] hwmon: (lm73) Add temp1_max_hyst entry to sysfs Joshua Scott
2016-10-07 18:44 ` Guenter Roeck [this message]
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=20161007184410.GA10013@roeck-us.net \
--to=linux@roeck-us.net \
--cc=chris.packham@alliedtelesis.co.nz \
--cc=jdelvare@suse.com \
--cc=joshua.scott@alliedtelesis.co.nz \
--cc=linux-hwmon@vger.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.