All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [lm-sensors] [PATCH] hwmon: (max1668) Add support for
@ 2011-06-11  9:28 Jean Delvare
  2011-06-11 15:35 ` Guenter Roeck
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Jean Delvare @ 2011-06-11  9:28 UTC (permalink / raw)
  To: lm-sensors

Hi Guenter,

On Thu, 9 Jun 2011 18:14:07 -0700, Guenter Roeck wrote:
> MAX1668 and compatibles have several external temperature sensors, but only
> a single FAULT status bit. If a fault occurs, the temperature reported on
> affected sensors is 127 degrees C. Use this knowledge to report faults on
> individual external sensors.
> 
> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
> ---
> Tested with MAX1668 with one sensor disconnected. Resulting output is as follows.
> Seems to be better than just reporting extra-high temperature.

Looks overall good.

Acked-by: Jean Delvare <khali@linux-fr.org>

Minor comments below if you are interested.

As a side note, it seems that
http://git.kernel.org/?p=linux/kernel/git/groeck/staging.git;a=commit;h¯2dcfe730577d5399973a4df648190f5562b470
doesn't properly credit David as being the original author of the
commit.

> 
> root@groeck-desktop# sensors
> max1668-i2c-5-18
> Adapter: i2c-devantech-iss at bus 001 device 007
> temp1:        +23.0°C  (low  = -55.0°C, high = +127.0°C)
> temp2:        +25.0°C  (low  = -55.0°C, high = +127.0°C)
> temp3:        +25.0°C  (low  = -55.0°C, high = +127.0°C)
> temp4:        +25.0°C  (low  = -55.0°C, high = +127.0°C)
> temp5:          FAULT  (low  = -55.0°C, high = +127.0°C)    ALARM(MAX)
> 
>  drivers/hwmon/max1668.c |   26 +++++++++++++++++++++++++-
>  1 files changed, 25 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/hwmon/max1668.c b/drivers/hwmon/max1668.c
> index ddefb64..af85d44 100644
> --- a/drivers/hwmon/max1668.c
> +++ b/drivers/hwmon/max1668.c
> @@ -123,7 +123,7 @@ static struct max1668_data *max1668_update_device(struct device *dev)
>  		goto abort;
>  	}
>  	data->alarms &= 0x00ff;
> -	data->alarms |= ((u8) (val & 0x60)) << 8;
> +	data->alarms |= ((u8) (val & 0x70)) << 8;

The (u8) type cast doesn't seem needed. Same a few lines below for
MAX1668_REG_STAT2.

>  
>  	val = i2c_smbus_read_byte_data(client, MAX1668_REG_STAT2);
>  	if (unlikely(val < 0)) {
> @@ -189,6 +189,19 @@ static ssize_t show_alarm(struct device *dev, struct device_attribute *attr,
>  	return sprintf(buf, "%u\n", (data->alarms >> index) & 0x1);
>  }
>  
> +static ssize_t show_fault(struct device *dev,
> +			  struct device_attribute *devattr, char *buf)
> +{
> +	int index = to_sensor_dev_attr(devattr)->index;
> +	struct max1668_data *data = max1668_update_device(dev);
> +
> +	if (IS_ERR(data))
> +		return PTR_ERR(data);
> +
> +	return sprintf(buf, "%d\n",

%u would probably make more sense, as this is used for alarms above.
But I agree %d will work too.

> +		       (data->alarms & (1 << 12)) && data->temp[index] = 127);
> +}
> +
>  static ssize_t set_temp_max(struct device *dev,
>  			    struct device_attribute *devattr,
>  			    const char *buf, size_t count)
> @@ -276,6 +289,11 @@ static SENSOR_DEVICE_ATTR(temp4_max_alarm, S_IRUGO, show_alarm, NULL, 2);
>  static SENSOR_DEVICE_ATTR(temp5_min_alarm, S_IRUGO, show_alarm, NULL, 1);
>  static SENSOR_DEVICE_ATTR(temp5_max_alarm, S_IRUGO, show_alarm, NULL, 0);
>  
> +static SENSOR_DEVICE_ATTR(temp2_fault, S_IRUGO, show_fault, NULL, 1);
> +static SENSOR_DEVICE_ATTR(temp3_fault, S_IRUGO, show_fault, NULL, 2);
> +static SENSOR_DEVICE_ATTR(temp4_fault, S_IRUGO, show_fault, NULL, 3);
> +static SENSOR_DEVICE_ATTR(temp5_fault, S_IRUGO, show_fault, NULL, 4);
> +
>  /* Attributes common to MAX1668, MAX1989 and MAX1805 */
>  static struct attribute *max1668_attribute_common[] = {
>  	&sensor_dev_attr_temp1_max.dev_attr.attr,
> @@ -294,6 +312,9 @@ static struct attribute *max1668_attribute_common[] = {
>  	&sensor_dev_attr_temp2_min_alarm.dev_attr.attr,
>  	&sensor_dev_attr_temp3_max_alarm.dev_attr.attr,
>  	&sensor_dev_attr_temp3_min_alarm.dev_attr.attr,
> +
> +	&sensor_dev_attr_temp2_fault.dev_attr.attr,
> +	&sensor_dev_attr_temp3_fault.dev_attr.attr,
>  	NULL
>  };
>  
> @@ -310,6 +331,9 @@ static struct attribute *max1668_attribute_unique[] = {
>  	&sensor_dev_attr_temp4_min_alarm.dev_attr.attr,
>  	&sensor_dev_attr_temp5_max_alarm.dev_attr.attr,
>  	&sensor_dev_attr_temp5_min_alarm.dev_attr.attr,
> +
> +	&sensor_dev_attr_temp4_fault.dev_attr.attr,
> +	&sensor_dev_attr_temp5_fault.dev_attr.attr,
>  	NULL
>  };
>  


-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [lm-sensors] [PATCH] hwmon: (max1668) Add support for
  2011-06-11  9:28 [lm-sensors] [PATCH] hwmon: (max1668) Add support for Jean Delvare
@ 2011-06-11 15:35 ` Guenter Roeck
  2011-06-11 15:48 ` Jean Delvare
  2011-06-12  0:52 ` Guenter Roeck
  2 siblings, 0 replies; 4+ messages in thread
From: Guenter Roeck @ 2011-06-11 15:35 UTC (permalink / raw)
  To: lm-sensors

Hi Jean,

On Sat, Jun 11, 2011 at 05:28:18AM -0400, Jean Delvare wrote:
> Hi Guenter,
> 
> On Thu, 9 Jun 2011 18:14:07 -0700, Guenter Roeck wrote:
> > MAX1668 and compatibles have several external temperature sensors, but only
> > a single FAULT status bit. If a fault occurs, the temperature reported on
> > affected sensors is 127 degrees C. Use this knowledge to report faults on
> > individual external sensors.
> > 
> > Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
> > ---
> > Tested with MAX1668 with one sensor disconnected. Resulting output is as follows.
> > Seems to be better than just reporting extra-high temperature.
> 
> Looks overall good.
> 
> Acked-by: Jean Delvare <khali@linux-fr.org>
> 
> Minor comments below if you are interested.
> 
I am, see below. Thanks a lot for the review!

> As a side note, it seems that
> http://git.kernel.org/?p=linux/kernel/git/groeck/staging.git;a=commit;h¯2dcfe730577d5399973a4df648190f5562b470
> doesn't properly credit David as being the original author of the
> commit.
> 
One of those cases where "git am" didn't work and I had to apply the patch manually.
I'll fix it. One of those days I'll have to figure out how to apply such 
patches without having to revert to "patch".

> > 
> > root@groeck-desktop# sensors
> > max1668-i2c-5-18
> > Adapter: i2c-devantech-iss at bus 001 device 007
> > temp1:        +23.0°C  (low  = -55.0°C, high = +127.0°C)
> > temp2:        +25.0°C  (low  = -55.0°C, high = +127.0°C)
> > temp3:        +25.0°C  (low  = -55.0°C, high = +127.0°C)
> > temp4:        +25.0°C  (low  = -55.0°C, high = +127.0°C)
> > temp5:          FAULT  (low  = -55.0°C, high = +127.0°C)    ALARM(MAX)
> > 
> >  drivers/hwmon/max1668.c |   26 +++++++++++++++++++++++++-
> >  1 files changed, 25 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/hwmon/max1668.c b/drivers/hwmon/max1668.c
> > index ddefb64..af85d44 100644
> > --- a/drivers/hwmon/max1668.c
> > +++ b/drivers/hwmon/max1668.c
> > @@ -123,7 +123,7 @@ static struct max1668_data *max1668_update_device(struct device *dev)
> >  		goto abort;
> >  	}
> >  	data->alarms &= 0x00ff;
> > -	data->alarms |= ((u8) (val & 0x60)) << 8;
> > +	data->alarms |= ((u8) (val & 0x70)) << 8;
> 
> The (u8) type cast doesn't seem needed. Same a few lines below for
> MAX1668_REG_STAT2.
> 
Actually, turns out that
	data->alarms = val << 8;
followed by
	data->alarms |= val;
for MAX1668_REG_STAT2 is good enough.

> >  
> >  	val = i2c_smbus_read_byte_data(client, MAX1668_REG_STAT2);
> >  	if (unlikely(val < 0)) {
> > @@ -189,6 +189,19 @@ static ssize_t show_alarm(struct device *dev, struct device_attribute *attr,
> >  	return sprintf(buf, "%u\n", (data->alarms >> index) & 0x1);
> >  }
> >  
> > +static ssize_t show_fault(struct device *dev,
> > +			  struct device_attribute *devattr, char *buf)
> > +{
> > +	int index = to_sensor_dev_attr(devattr)->index;
> > +	struct max1668_data *data = max1668_update_device(dev);
> > +
> > +	if (IS_ERR(data))
> > +		return PTR_ERR(data);
> > +
> > +	return sprintf(buf, "%d\n",
> 
> %u would probably make more sense, as this is used for alarms above.
> But I agree %d will work too.
> 
Still more consistent. I changed it.

> > +		       (data->alarms & (1 << 12)) && data->temp[index] = 127);
> > +}
> > +
> >  static ssize_t set_temp_max(struct device *dev,
> >  			    struct device_attribute *devattr,
> >  			    const char *buf, size_t count)
> > @@ -276,6 +289,11 @@ static SENSOR_DEVICE_ATTR(temp4_max_alarm, S_IRUGO, show_alarm, NULL, 2);
> >  static SENSOR_DEVICE_ATTR(temp5_min_alarm, S_IRUGO, show_alarm, NULL, 1);
> >  static SENSOR_DEVICE_ATTR(temp5_max_alarm, S_IRUGO, show_alarm, NULL, 0);
> >  
> > +static SENSOR_DEVICE_ATTR(temp2_fault, S_IRUGO, show_fault, NULL, 1);
> > +static SENSOR_DEVICE_ATTR(temp3_fault, S_IRUGO, show_fault, NULL, 2);
> > +static SENSOR_DEVICE_ATTR(temp4_fault, S_IRUGO, show_fault, NULL, 3);
> > +static SENSOR_DEVICE_ATTR(temp5_fault, S_IRUGO, show_fault, NULL, 4);
> > +
> >  /* Attributes common to MAX1668, MAX1989 and MAX1805 */
> >  static struct attribute *max1668_attribute_common[] = {
> >  	&sensor_dev_attr_temp1_max.dev_attr.attr,
> > @@ -294,6 +312,9 @@ static struct attribute *max1668_attribute_common[] = {
> >  	&sensor_dev_attr_temp2_min_alarm.dev_attr.attr,
> >  	&sensor_dev_attr_temp3_max_alarm.dev_attr.attr,
> >  	&sensor_dev_attr_temp3_min_alarm.dev_attr.attr,
> > +
> > +	&sensor_dev_attr_temp2_fault.dev_attr.attr,
> > +	&sensor_dev_attr_temp3_fault.dev_attr.attr,
> >  	NULL
> >  };
> >  
> > @@ -310,6 +331,9 @@ static struct attribute *max1668_attribute_unique[] = {
> >  	&sensor_dev_attr_temp4_min_alarm.dev_attr.attr,
> >  	&sensor_dev_attr_temp5_max_alarm.dev_attr.attr,
> >  	&sensor_dev_attr_temp5_min_alarm.dev_attr.attr,
> > +
> > +	&sensor_dev_attr_temp4_fault.dev_attr.attr,
> > +	&sensor_dev_attr_temp5_fault.dev_attr.attr,
> >  	NULL
> >  };
> >  
> 
> 
> -- 
> Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [lm-sensors] [PATCH] hwmon: (max1668) Add support for
  2011-06-11  9:28 [lm-sensors] [PATCH] hwmon: (max1668) Add support for Jean Delvare
  2011-06-11 15:35 ` Guenter Roeck
@ 2011-06-11 15:48 ` Jean Delvare
  2011-06-12  0:52 ` Guenter Roeck
  2 siblings, 0 replies; 4+ messages in thread
From: Jean Delvare @ 2011-06-11 15:48 UTC (permalink / raw)
  To: lm-sensors

On Sat, 11 Jun 2011 08:35:31 -0700, Guenter Roeck wrote:
> On Sat, Jun 11, 2011 at 05:28:18AM -0400, Jean Delvare wrote:
> > On Thu, 9 Jun 2011 18:14:07 -0700, Guenter Roeck wrote:
> > > root@groeck-desktop# sensors
> > > max1668-i2c-5-18
> > > Adapter: i2c-devantech-iss at bus 001 device 007
> > > temp1:        +23.0°C  (low  = -55.0°C, high = +127.0°C)
> > > temp2:        +25.0°C  (low  = -55.0°C, high = +127.0°C)
> > > temp3:        +25.0°C  (low  = -55.0°C, high = +127.0°C)
> > > temp4:        +25.0°C  (low  = -55.0°C, high = +127.0°C)
> > > temp5:          FAULT  (low  = -55.0°C, high = +127.0°C)    ALARM(MAX)
> > > 
> > >  drivers/hwmon/max1668.c |   26 +++++++++++++++++++++++++-
> > >  1 files changed, 25 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/hwmon/max1668.c b/drivers/hwmon/max1668.c
> > > index ddefb64..af85d44 100644
> > > --- a/drivers/hwmon/max1668.c
> > > +++ b/drivers/hwmon/max1668.c
> > > @@ -123,7 +123,7 @@ static struct max1668_data *max1668_update_device(struct device *dev)
> > >  		goto abort;
> > >  	}
> > >  	data->alarms &= 0x00ff;
> > > -	data->alarms |= ((u8) (val & 0x60)) << 8;
> > > +	data->alarms |= ((u8) (val & 0x70)) << 8;
> > 
> > The (u8) type cast doesn't seem needed. Same a few lines below for
> > MAX1668_REG_STAT2.
> > 
> Actually, turns out that
> 	data->alarms = val << 8;
> followed by
> 	data->alarms |= val;
> for MAX1668_REG_STAT2 is good enough.

I think that the original idea was to preserve as much of data->alarms
as possible in case one of the two reads failed. But given that the rest
of the driver code doesn't leverage from that, you can indeed simplify
it.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [lm-sensors] [PATCH] hwmon: (max1668) Add support for
  2011-06-11  9:28 [lm-sensors] [PATCH] hwmon: (max1668) Add support for Jean Delvare
  2011-06-11 15:35 ` Guenter Roeck
  2011-06-11 15:48 ` Jean Delvare
@ 2011-06-12  0:52 ` Guenter Roeck
  2 siblings, 0 replies; 4+ messages in thread
From: Guenter Roeck @ 2011-06-12  0:52 UTC (permalink / raw)
  To: lm-sensors

Hi Jean,
[ ... ]
> > > > +	data->alarms |= ((u8) (val & 0x70)) << 8;
> > > 
> > > The (u8) type cast doesn't seem needed. Same a few lines below for
> > > MAX1668_REG_STAT2.
> > > 
> > Actually, turns out that
> > 	data->alarms = val << 8;
> > followed by
> > 	data->alarms |= val;
> > for MAX1668_REG_STAT2 is good enough.
> 
> I think that the original idea was to preserve as much of data->alarms
> as possible in case one of the two reads failed. But given that the rest
> of the driver code doesn't leverage from that, you can indeed simplify
> it.
> 
Yes, that is what I figured. I also don't really believe in error path code optimization.

Anyway, in case you are interested, here are some chip register dumps for you:

MAX1668:

No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 1c 1c 1c 00 00 80 00 00 7f c9 7f c9 7f c9 7f c9    ???..?..????????
10: 7f c9 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
20: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
30: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
40: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
50: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
60: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
70: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
80: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
90: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
a0: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
b0: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
c0: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
d0: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
e0: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05    ????????????????
f0: 05 05 05 05 05 05 05 05 05 05 05 05 05 05 4d 05    ??????????????M?

MAX1805:

No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 1a 1b 1b 1b 1b 80 00 00 7f c9 7f c9 7f c9 7f c9    ??????..????????
10: 7f c9 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
20: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
30: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
40: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
50: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
60: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
70: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
80: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
90: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
a0: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
b0: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
c0: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
d0: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
e0: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03    ????????????????
f0: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 4d 03    ??????????????M?

Interesting is that the chip ID is returned in all unused registers,
even if I read an existing register first.

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-06-12  0:52 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-11  9:28 [lm-sensors] [PATCH] hwmon: (max1668) Add support for Jean Delvare
2011-06-11 15:35 ` Guenter Roeck
2011-06-11 15:48 ` Jean Delvare
2011-06-12  0:52 ` Guenter Roeck

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.