All of lore.kernel.org
 help / color / mirror / Atom feed
* [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature sensor
@ 2010-02-04  1:23 ` Steven King
  0 siblings, 0 replies; 18+ messages in thread
From: Steven King @ 2010-02-04  1:23 UTC (permalink / raw)
  To: Jean Delvare; +Cc: lm-sensors, linux-kernel

The TI TMP102 is similar to the lm75.  It differs from the lm75 by having a 16 bit conf register
and the temp registers have a minimum resolution of 12bits; the extended conf register
can select 13 bit resolution (which this driver does) and also change the update rate (which this
driver currently doesn't use).

Signed-off-by: Steven King <sfking@fdwdc.com>
---

Driver for the TI TMP102.

 Documentation/hwmon/tmp102 |   27 ++++
 drivers/hwmon/Kconfig      |   10 ++
 drivers/hwmon/Makefile     |    1 +
 drivers/hwmon/tmp102.c     |  345 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 383 insertions(+), 0 deletions(-)

diff --git a/Documentation/hwmon/tmp102 b/Documentation/hwmon/tmp102
new file mode 100644
index 0000000..239dded
--- /dev/null
+++ b/Documentation/hwmon/tmp102
@@ -0,0 +1,27 @@
+Kernel driver tmp102
+==========
+
+Supported chips:
+  * Texas Instruments TMP102
+    Prefix: 'tmp102'
+    Addresses scanned: I2C 0x48 0x49 0x4a 0x4b
+    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp102.html
+
+Author:
+	Steven King <sfking@fdwdc.com>
+
+Description
+-----------
+
+The Texas Instruments TMP102 implements one temperature sensor.  Limits can be
+set through the Overtemperature Shutdown register and Hysteresis register.  The
+sensor is accurate to 0.5 degrees over the range of -25 to +85 C, and to 1.0
+degrees from -40 to +125 C. Resolution of the sensor is 0.0625 degree.  The
+operating temperature has a minimum of -55 C and a maximum of +150 C.
+
+The TMP102 has a programmable update rate that can select between 8, 4, 1, and
+0.5 Hz. (Currently the driver only supports the default of 4 Hz).
+
+The driver provides the common sysfs-interface for temperatures (see
+/Documentation/hwmon/sysfs-interface under Temperatures).
+
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 68cf877..cf9d7d3 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -812,6 +812,16 @@ config SENSORS_THMC50
 	  This driver can also be built as a module.  If so, the module
 	  will be called thmc50.
 
+config SENSORS_TMP102
+	tristate "Texas Instruments TMP102 and compatibles"
+	depends on I2C && EXPERIMENTAL
+	help
+	  If you say yes here you get support for Texas Instruments TMP102
+	  sensor chips.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called tmp102.
+
 config SENSORS_TMP401
 	tristate "Texas Instruments TMP401 and compatibles"
 	depends on I2C && EXPERIMENTAL
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 4bc215c..0e5cf73 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_SENSORS_SMSC47M1)	+= smsc47m1.o
 obj-$(CONFIG_SENSORS_SMSC47M192)+= smsc47m192.o
 obj-$(CONFIG_SENSORS_AMC6821)	+= amc6821.o
 obj-$(CONFIG_SENSORS_THMC50)	+= thmc50.o
+obj-$(CONFIG_SENSORS_TMP102)	+= tmp102.o
 obj-$(CONFIG_SENSORS_TMP401)	+= tmp401.o
 obj-$(CONFIG_SENSORS_TMP421)	+= tmp421.o
 obj-$(CONFIG_SENSORS_VIA_CPUTEMP)+= via-cputemp.o
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
new file mode 100644
index 0000000..7b96b1c
--- /dev/null
+++ b/drivers/hwmon/tmp102.c
@@ -0,0 +1,345 @@
+/* Texas Instruments TMP102 SMBUS temperature sensor driver
+ *
+ * Copyright 2010 Steven King <sfking@fdwdc.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/i2c.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/err.h>
+#include <linux/mutex.h>
+#include <linux/delay.h>
+
+#define	DRIVER_NAME "tmp102"
+
+#define	TMP102_TEMP_REG			0x00
+#define	TMP102_CONF_REG			0x01
+/* note: these bit definitions are byte swapped */
+#define		TMP102_CONF_SD		0x0100
+#define		TMP102_CONF_TM		0x0200
+#define		TMP102_CONF_POL		0x0400
+#define		TMP102_CONF_F0		0x0800
+#define		TMP102_CONF_F1		0x1000
+#define		TMP102_CONF_R0		0x2000
+#define		TMP102_CONF_R1		0x4000
+#define		TMP102_CONF_OS		0x8000
+#define		TMP102_CONF_EM		0x0010
+#define		TMP102_CONF_AL		0x0020
+#define		TMP102_CONF_CR0		0x0040
+#define		TMP102_CONF_CR1		0x0080
+#define	TMP102_TLOW_REG			0x02
+#define	TMP102_THIGH_REG		0x03
+
+struct tmp102 {
+	struct device *hwmon_dev;
+	struct mutex lock;
+	unsigned long last_update;
+	s16 temp[3];
+};
+
+/* the TMP102 registers are big endian so we have to swab16 the values */
+static int tmp102_read_reg(struct i2c_client *client, u8 reg)
+{
+	int result = i2c_smbus_read_word_data(client, reg);
+	return result < 0 ? result : swab16(result);
+}
+
+static int tmp102_write_reg(struct i2c_client *client, u8 reg, u16 val)
+{
+	return i2c_smbus_write_word_data(client, reg, swab16(val));
+}
+
+/* convert left adjusted 13bit TMP102 register value to miliCelsius */
+static int tmp102_reg_to_mC(s16 val)
+{
+	return (val * 100) / 128;
+}
+
+/* convert miliCelsius to left adjusted 13bit TMP102 register value */
+static u16 tmp102_mC_to_reg(int val)
+{
+	return (val * 128) / 100;
+}
+
+static const u8 tmp102_reg[] = {
+	TMP102_TEMP_REG,
+	TMP102_TLOW_REG,
+	TMP102_THIGH_REG,
+};
+
+static struct tmp102 *tmp102_update_device(struct i2c_client *client)
+{
+	struct tmp102 *tmp102 = i2c_get_clientdata(client);
+
+	mutex_lock(&tmp102->lock);
+	if (time_after(jiffies, tmp102->last_update + HZ / 4)) {
+		int i = 0;
+		do {
+			int status = tmp102_read_reg(client, tmp102_reg[i]);
+			if (status > -1)
+				tmp102->temp[i] = tmp102_reg_to_mC(status);
+
+		} while (++i < ARRAY_SIZE(tmp102->temp));
+		tmp102->last_update = jiffies;
+	}
+	mutex_unlock(&tmp102->lock);
+	return tmp102;
+}
+
+static ssize_t tmp102_show_temp(struct device *dev,
+				struct device_attribute *attr,
+				char *buf)
+{
+	struct sensor_device_attribute *sda = to_sensor_dev_attr(attr);
+	struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
+
+	return sprintf(buf, "%d\n", tmp102->temp[sda->index]);
+}
+
+static ssize_t tmp102_set_temp(struct device *dev,
+			       struct device_attribute *attr,
+			       const char *buf, size_t count)
+{
+	struct sensor_device_attribute *sda = to_sensor_dev_attr(attr);
+	struct i2c_client *client = to_i2c_client(dev);
+	struct tmp102 *tmp102 = i2c_get_clientdata(client);
+	long val;
+	int status = 0;
+
+	if ((strict_strtol(buf, 10, &val) < 0) || (abs(val) > 15000))
+		return -EINVAL;
+	mutex_lock(&tmp102->lock);
+	if (tmp102->temp[sda->index] != val) {
+		tmp102->temp[sda->index] = val;
+		status = tmp102_write_reg(client, tmp102_reg[sda->index],
+					  tmp102_mC_to_reg(val));
+	}
+	mutex_unlock(&tmp102->lock);
+	return status ? : count;
+}
+
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, tmp102_show_temp, NULL , 0);
+
+static SENSOR_DEVICE_ATTR(temp1_max_hyst, S_IWUSR | S_IRUGO, tmp102_show_temp,
+			  tmp102_set_temp, 1);
+
+static SENSOR_DEVICE_ATTR(temp1_max, S_IWUSR | S_IRUGO, tmp102_show_temp,
+			  tmp102_set_temp, 2);
+
+static struct attribute *tmp102_attributes[] = {
+	&sensor_dev_attr_temp1_input.dev_attr.attr,
+	&sensor_dev_attr_temp1_max_hyst.dev_attr.attr,
+	&sensor_dev_attr_temp1_max.dev_attr.attr,
+	NULL
+};
+
+static const struct attribute_group tmp102_attr_group = {
+	.attrs = tmp102_attributes,
+};
+
+#define TMP102_CONFIG  (TMP102_CONF_TM | TMP102_CONF_EM | TMP102_CONF_CR1)
+#define TMP102_CONFIG_RD_ONLY (TMP102_CONF_R0 | TMP102_CONF_R1 | TMP102_CONF_AL)
+
+static int __devinit tmp102_probe(struct i2c_client *client,
+				  const struct i2c_device_id *id)
+{
+	struct tmp102 *tmp102;
+	int status;
+
+	if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA |
+				     I2C_FUNC_SMBUS_WORD_DATA)) {
+		dev_dbg(&client->dev, "adapter doesnt support SMBUS\n");
+		return -ENODEV;
+	}
+
+	tmp102 = kzalloc(sizeof(*tmp102), GFP_KERNEL);
+	if (!tmp102) {
+		dev_dbg(&client->dev, "kzalloc failed\n");
+		return -ENOMEM;
+	}
+	i2c_set_clientdata(client, tmp102);
+
+	tmp102_write_reg(client, TMP102_CONF_REG, TMP102_CONFIG);
+	status = tmp102_read_reg(client, TMP102_CONF_REG);
+	if (status < 0) {
+		dev_dbg(&client->dev, "error reading config register\n");
+		goto fail0;
+	}
+	status &= ~TMP102_CONFIG_RD_ONLY;
+	if (status != TMP102_CONFIG) {
+		dev_dbg(&client->dev, "could not verify config settings\n");
+		status = -EIO;
+		goto fail0;
+	}
+	tmp102->last_update = jiffies - HZ;
+	mutex_init(&tmp102->lock);
+
+	status = sysfs_create_group(&client->dev.kobj, &tmp102_attr_group);
+	if (status) {
+		dev_dbg(&client->dev, "could not create sysfs files\n");
+		goto fail0;
+	}
+	tmp102->hwmon_dev = hwmon_device_register(&client->dev);
+	if (IS_ERR(tmp102->hwmon_dev)) {
+		dev_dbg(&client->dev, "unable to register hwmon device\n");
+		status = PTR_ERR(tmp102->hwmon_dev);
+		goto fail1;
+	}
+
+	dev_info(&client->dev, "initialized\n");
+
+	return 0;
+fail1:
+	sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
+fail0:
+	i2c_set_clientdata(client, NULL);
+	kfree(tmp102);
+
+	return 0;
+}
+
+static int __devexit tmp102_remove(struct i2c_client *client)
+{
+	struct tmp102 *tmp102 = i2c_get_clientdata(client);
+
+	/* shutdown the chip */
+	tmp102_write_reg(client, TMP102_CONF_REG, TMP102_CONF_SD);
+
+	hwmon_device_unregister(tmp102->hwmon_dev);
+	sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
+	i2c_set_clientdata(client, NULL);
+	kfree(tmp102);
+
+	return 0;
+}
+
+static int tmp102_detect(struct i2c_client *client, struct i2c_board_info *info)
+{
+	int reg;
+
+	if (!i2c_check_functionality(client->adapter,
+				     I2C_FUNC_SMBUS_BYTE_DATA |
+				     I2C_FUNC_SMBUS_WORD_DATA)) {
+		dev_dbg(&client->dev, "adapter doesnt support SMBUS\n");
+		return -ENODEV;
+	}
+
+	reg = i2c_smbus_read_word_data(client, TMP102_CONF_REG);
+	if (reg < 0)
+		goto fail;
+	/* the tmp102 has a 16 bit config register and the low 4 bits of the
+	 * byte swapped 1st byte are 0.
+	*/
+	if (reg & 0x000f)
+		goto fail;
+	reg = i2c_smbus_read_word_data(client, TMP102_TLOW_REG);
+	if (reg < 0)
+		goto fail;
+	if (i2c_smbus_read_word_data(client, 4) != reg ||
+		i2c_smbus_read_word_data(client, 5) != reg ||
+		i2c_smbus_read_word_data(client, 6) != reg ||
+		i2c_smbus_read_word_data(client, 7) != reg ||
+		i2c_smbus_read_word_data(client, 8) != reg)
+		goto fail;
+	reg = i2c_smbus_read_word_data(client, TMP102_THIGH_REG);
+	if (reg < 0)
+		goto fail;
+	if (i2c_smbus_read_word_data(client, 4) != reg ||
+		i2c_smbus_read_word_data(client, 5) != reg ||
+		i2c_smbus_read_word_data(client, 6) != reg ||
+		i2c_smbus_read_word_data(client, 7) != reg ||
+		i2c_smbus_read_word_data(client, 8) != reg)
+		goto fail;
+
+	strlcpy(info->type, "tmp102", I2C_NAME_SIZE);
+
+	return 0;
+fail:
+	dev_dbg(&client->dev, "not a tmp102\n");
+
+	return -ENODEV;
+}
+
+#ifdef CONFIG_PM
+static int tmp102_suspend(struct device *dev)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+
+	tmp102_write_reg(client, TMP102_CONF_REG, TMP102_CONF_SD);
+
+	return 0;
+}
+
+static int tmp102_resume(struct device *dev)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+
+	tmp102_write_reg(client, TMP102_CONF_REG, TMP102_CONFIG);
+
+	return 0;
+}
+
+static struct dev_pm_ops tmp102_dev_pm_ops = {
+	.suspend	= tmp102_suspend,
+	.resume		= tmp102_resume,
+};
+
+#define TMP102_DEV_PM_OPS (&tmp102_dev_pm_ops)
+#else
+#define	TMP102_DEV_PM_OPS NULL
+#endif /* CONFIG_PM */
+
+static const unsigned short normal_i2c[] = {
+	0x48, 0x49, 0x4a, 0x4b, I2C_CLIENT_END
+};
+
+static const struct i2c_device_id tmp102_id[] = {
+	{ DRIVER_NAME, 0 },
+	{ }
+};
+
+static struct i2c_driver tmp102_driver = {
+	.driver.name	= DRIVER_NAME,
+	.driver.pm	= TMP102_DEV_PM_OPS,
+	.class		= I2C_CLASS_HWMON,
+	.probe		= tmp102_probe,
+	.remove		= __devexit_p(tmp102_remove),
+	.id_table	= tmp102_id,
+	.detect		= tmp102_detect,
+	.address_list	= normal_i2c,
+};
+
+static int __init tmp102_init(void)
+{
+	return i2c_add_driver(&tmp102_driver);
+}
+module_init(tmp102_init);
+
+static void __init tmp102_exit(void)
+{
+	i2c_del_driver(&tmp102_driver);
+}
+module_exit(tmp102_exit);
+
+
+MODULE_AUTHOR("Steven King <sfking@fdwdc.com>");
+MODULE_DESCRIPTION("Texas Instruments TMP102 temperature sensor driver");
+MODULE_LICENSE("GPL");


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

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

* [PATCH] hwmon: driver for TI tmp102 temperature sensor
@ 2010-02-04  1:23 ` Steven King
  0 siblings, 0 replies; 18+ messages in thread
From: Steven King @ 2010-02-04  1:23 UTC (permalink / raw)
  To: Jean Delvare; +Cc: lm-sensors, linux-kernel

The TI TMP102 is similar to the lm75.  It differs from the lm75 by having a 16 bit conf register
and the temp registers have a minimum resolution of 12bits; the extended conf register
can select 13 bit resolution (which this driver does) and also change the update rate (which this
driver currently doesn't use).

Signed-off-by: Steven King <sfking@fdwdc.com>
---

Driver for the TI TMP102.

 Documentation/hwmon/tmp102 |   27 ++++
 drivers/hwmon/Kconfig      |   10 ++
 drivers/hwmon/Makefile     |    1 +
 drivers/hwmon/tmp102.c     |  345 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 383 insertions(+), 0 deletions(-)

diff --git a/Documentation/hwmon/tmp102 b/Documentation/hwmon/tmp102
new file mode 100644
index 0000000..239dded
--- /dev/null
+++ b/Documentation/hwmon/tmp102
@@ -0,0 +1,27 @@
+Kernel driver tmp102
+====================
+
+Supported chips:
+  * Texas Instruments TMP102
+    Prefix: 'tmp102'
+    Addresses scanned: I2C 0x48 0x49 0x4a 0x4b
+    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp102.html
+
+Author:
+	Steven King <sfking@fdwdc.com>
+
+Description
+-----------
+
+The Texas Instruments TMP102 implements one temperature sensor.  Limits can be
+set through the Overtemperature Shutdown register and Hysteresis register.  The
+sensor is accurate to 0.5 degrees over the range of -25 to +85 C, and to 1.0
+degrees from -40 to +125 C. Resolution of the sensor is 0.0625 degree.  The
+operating temperature has a minimum of -55 C and a maximum of +150 C.
+
+The TMP102 has a programmable update rate that can select between 8, 4, 1, and
+0.5 Hz. (Currently the driver only supports the default of 4 Hz).
+
+The driver provides the common sysfs-interface for temperatures (see
+/Documentation/hwmon/sysfs-interface under Temperatures).
+
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 68cf877..cf9d7d3 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -812,6 +812,16 @@ config SENSORS_THMC50
 	  This driver can also be built as a module.  If so, the module
 	  will be called thmc50.
 
+config SENSORS_TMP102
+	tristate "Texas Instruments TMP102 and compatibles"
+	depends on I2C && EXPERIMENTAL
+	help
+	  If you say yes here you get support for Texas Instruments TMP102
+	  sensor chips.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called tmp102.
+
 config SENSORS_TMP401
 	tristate "Texas Instruments TMP401 and compatibles"
 	depends on I2C && EXPERIMENTAL
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 4bc215c..0e5cf73 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_SENSORS_SMSC47M1)	+= smsc47m1.o
 obj-$(CONFIG_SENSORS_SMSC47M192)+= smsc47m192.o
 obj-$(CONFIG_SENSORS_AMC6821)	+= amc6821.o
 obj-$(CONFIG_SENSORS_THMC50)	+= thmc50.o
+obj-$(CONFIG_SENSORS_TMP102)	+= tmp102.o
 obj-$(CONFIG_SENSORS_TMP401)	+= tmp401.o
 obj-$(CONFIG_SENSORS_TMP421)	+= tmp421.o
 obj-$(CONFIG_SENSORS_VIA_CPUTEMP)+= via-cputemp.o
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
new file mode 100644
index 0000000..7b96b1c
--- /dev/null
+++ b/drivers/hwmon/tmp102.c
@@ -0,0 +1,345 @@
+/* Texas Instruments TMP102 SMBUS temperature sensor driver
+ *
+ * Copyright 2010 Steven King <sfking@fdwdc.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/i2c.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/err.h>
+#include <linux/mutex.h>
+#include <linux/delay.h>
+
+#define	DRIVER_NAME "tmp102"
+
+#define	TMP102_TEMP_REG			0x00
+#define	TMP102_CONF_REG			0x01
+/* note: these bit definitions are byte swapped */
+#define		TMP102_CONF_SD		0x0100
+#define		TMP102_CONF_TM		0x0200
+#define		TMP102_CONF_POL		0x0400
+#define		TMP102_CONF_F0		0x0800
+#define		TMP102_CONF_F1		0x1000
+#define		TMP102_CONF_R0		0x2000
+#define		TMP102_CONF_R1		0x4000
+#define		TMP102_CONF_OS		0x8000
+#define		TMP102_CONF_EM		0x0010
+#define		TMP102_CONF_AL		0x0020
+#define		TMP102_CONF_CR0		0x0040
+#define		TMP102_CONF_CR1		0x0080
+#define	TMP102_TLOW_REG			0x02
+#define	TMP102_THIGH_REG		0x03
+
+struct tmp102 {
+	struct device *hwmon_dev;
+	struct mutex lock;
+	unsigned long last_update;
+	s16 temp[3];
+};
+
+/* the TMP102 registers are big endian so we have to swab16 the values */
+static int tmp102_read_reg(struct i2c_client *client, u8 reg)
+{
+	int result = i2c_smbus_read_word_data(client, reg);
+	return result < 0 ? result : swab16(result);
+}
+
+static int tmp102_write_reg(struct i2c_client *client, u8 reg, u16 val)
+{
+	return i2c_smbus_write_word_data(client, reg, swab16(val));
+}
+
+/* convert left adjusted 13bit TMP102 register value to miliCelsius */
+static int tmp102_reg_to_mC(s16 val)
+{
+	return (val * 100) / 128;
+}
+
+/* convert miliCelsius to left adjusted 13bit TMP102 register value */
+static u16 tmp102_mC_to_reg(int val)
+{
+	return (val * 128) / 100;
+}
+
+static const u8 tmp102_reg[] = {
+	TMP102_TEMP_REG,
+	TMP102_TLOW_REG,
+	TMP102_THIGH_REG,
+};
+
+static struct tmp102 *tmp102_update_device(struct i2c_client *client)
+{
+	struct tmp102 *tmp102 = i2c_get_clientdata(client);
+
+	mutex_lock(&tmp102->lock);
+	if (time_after(jiffies, tmp102->last_update + HZ / 4)) {
+		int i = 0;
+		do {
+			int status = tmp102_read_reg(client, tmp102_reg[i]);
+			if (status > -1)
+				tmp102->temp[i] = tmp102_reg_to_mC(status);
+
+		} while (++i < ARRAY_SIZE(tmp102->temp));
+		tmp102->last_update = jiffies;
+	}
+	mutex_unlock(&tmp102->lock);
+	return tmp102;
+}
+
+static ssize_t tmp102_show_temp(struct device *dev,
+				struct device_attribute *attr,
+				char *buf)
+{
+	struct sensor_device_attribute *sda = to_sensor_dev_attr(attr);
+	struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
+
+	return sprintf(buf, "%d\n", tmp102->temp[sda->index]);
+}
+
+static ssize_t tmp102_set_temp(struct device *dev,
+			       struct device_attribute *attr,
+			       const char *buf, size_t count)
+{
+	struct sensor_device_attribute *sda = to_sensor_dev_attr(attr);
+	struct i2c_client *client = to_i2c_client(dev);
+	struct tmp102 *tmp102 = i2c_get_clientdata(client);
+	long val;
+	int status = 0;
+
+	if ((strict_strtol(buf, 10, &val) < 0) || (abs(val) > 15000))
+		return -EINVAL;
+	mutex_lock(&tmp102->lock);
+	if (tmp102->temp[sda->index] != val) {
+		tmp102->temp[sda->index] = val;
+		status = tmp102_write_reg(client, tmp102_reg[sda->index],
+					  tmp102_mC_to_reg(val));
+	}
+	mutex_unlock(&tmp102->lock);
+	return status ? : count;
+}
+
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, tmp102_show_temp, NULL , 0);
+
+static SENSOR_DEVICE_ATTR(temp1_max_hyst, S_IWUSR | S_IRUGO, tmp102_show_temp,
+			  tmp102_set_temp, 1);
+
+static SENSOR_DEVICE_ATTR(temp1_max, S_IWUSR | S_IRUGO, tmp102_show_temp,
+			  tmp102_set_temp, 2);
+
+static struct attribute *tmp102_attributes[] = {
+	&sensor_dev_attr_temp1_input.dev_attr.attr,
+	&sensor_dev_attr_temp1_max_hyst.dev_attr.attr,
+	&sensor_dev_attr_temp1_max.dev_attr.attr,
+	NULL
+};
+
+static const struct attribute_group tmp102_attr_group = {
+	.attrs = tmp102_attributes,
+};
+
+#define TMP102_CONFIG  (TMP102_CONF_TM | TMP102_CONF_EM | TMP102_CONF_CR1)
+#define TMP102_CONFIG_RD_ONLY (TMP102_CONF_R0 | TMP102_CONF_R1 | TMP102_CONF_AL)
+
+static int __devinit tmp102_probe(struct i2c_client *client,
+				  const struct i2c_device_id *id)
+{
+	struct tmp102 *tmp102;
+	int status;
+
+	if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA |
+				     I2C_FUNC_SMBUS_WORD_DATA)) {
+		dev_dbg(&client->dev, "adapter doesnt support SMBUS\n");
+		return -ENODEV;
+	}
+
+	tmp102 = kzalloc(sizeof(*tmp102), GFP_KERNEL);
+	if (!tmp102) {
+		dev_dbg(&client->dev, "kzalloc failed\n");
+		return -ENOMEM;
+	}
+	i2c_set_clientdata(client, tmp102);
+
+	tmp102_write_reg(client, TMP102_CONF_REG, TMP102_CONFIG);
+	status = tmp102_read_reg(client, TMP102_CONF_REG);
+	if (status < 0) {
+		dev_dbg(&client->dev, "error reading config register\n");
+		goto fail0;
+	}
+	status &= ~TMP102_CONFIG_RD_ONLY;
+	if (status != TMP102_CONFIG) {
+		dev_dbg(&client->dev, "could not verify config settings\n");
+		status = -EIO;
+		goto fail0;
+	}
+	tmp102->last_update = jiffies - HZ;
+	mutex_init(&tmp102->lock);
+
+	status = sysfs_create_group(&client->dev.kobj, &tmp102_attr_group);
+	if (status) {
+		dev_dbg(&client->dev, "could not create sysfs files\n");
+		goto fail0;
+	}
+	tmp102->hwmon_dev = hwmon_device_register(&client->dev);
+	if (IS_ERR(tmp102->hwmon_dev)) {
+		dev_dbg(&client->dev, "unable to register hwmon device\n");
+		status = PTR_ERR(tmp102->hwmon_dev);
+		goto fail1;
+	}
+
+	dev_info(&client->dev, "initialized\n");
+
+	return 0;
+fail1:
+	sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
+fail0:
+	i2c_set_clientdata(client, NULL);
+	kfree(tmp102);
+
+	return 0;
+}
+
+static int __devexit tmp102_remove(struct i2c_client *client)
+{
+	struct tmp102 *tmp102 = i2c_get_clientdata(client);
+
+	/* shutdown the chip */
+	tmp102_write_reg(client, TMP102_CONF_REG, TMP102_CONF_SD);
+
+	hwmon_device_unregister(tmp102->hwmon_dev);
+	sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
+	i2c_set_clientdata(client, NULL);
+	kfree(tmp102);
+
+	return 0;
+}
+
+static int tmp102_detect(struct i2c_client *client, struct i2c_board_info *info)
+{
+	int reg;
+
+	if (!i2c_check_functionality(client->adapter,
+				     I2C_FUNC_SMBUS_BYTE_DATA |
+				     I2C_FUNC_SMBUS_WORD_DATA)) {
+		dev_dbg(&client->dev, "adapter doesnt support SMBUS\n");
+		return -ENODEV;
+	}
+
+	reg = i2c_smbus_read_word_data(client, TMP102_CONF_REG);
+	if (reg < 0)
+		goto fail;
+	/* the tmp102 has a 16 bit config register and the low 4 bits of the
+	 * byte swapped 1st byte are 0.
+	*/
+	if (reg & 0x000f)
+		goto fail;
+	reg = i2c_smbus_read_word_data(client, TMP102_TLOW_REG);
+	if (reg < 0)
+		goto fail;
+	if (i2c_smbus_read_word_data(client, 4) != reg ||
+		i2c_smbus_read_word_data(client, 5) != reg ||
+		i2c_smbus_read_word_data(client, 6) != reg ||
+		i2c_smbus_read_word_data(client, 7) != reg ||
+		i2c_smbus_read_word_data(client, 8) != reg)
+		goto fail;
+	reg = i2c_smbus_read_word_data(client, TMP102_THIGH_REG);
+	if (reg < 0)
+		goto fail;
+	if (i2c_smbus_read_word_data(client, 4) != reg ||
+		i2c_smbus_read_word_data(client, 5) != reg ||
+		i2c_smbus_read_word_data(client, 6) != reg ||
+		i2c_smbus_read_word_data(client, 7) != reg ||
+		i2c_smbus_read_word_data(client, 8) != reg)
+		goto fail;
+
+	strlcpy(info->type, "tmp102", I2C_NAME_SIZE);
+
+	return 0;
+fail:
+	dev_dbg(&client->dev, "not a tmp102\n");
+
+	return -ENODEV;
+}
+
+#ifdef CONFIG_PM
+static int tmp102_suspend(struct device *dev)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+
+	tmp102_write_reg(client, TMP102_CONF_REG, TMP102_CONF_SD);
+
+	return 0;
+}
+
+static int tmp102_resume(struct device *dev)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+
+	tmp102_write_reg(client, TMP102_CONF_REG, TMP102_CONFIG);
+
+	return 0;
+}
+
+static struct dev_pm_ops tmp102_dev_pm_ops = {
+	.suspend	= tmp102_suspend,
+	.resume		= tmp102_resume,
+};
+
+#define TMP102_DEV_PM_OPS (&tmp102_dev_pm_ops)
+#else
+#define	TMP102_DEV_PM_OPS NULL
+#endif /* CONFIG_PM */
+
+static const unsigned short normal_i2c[] = {
+	0x48, 0x49, 0x4a, 0x4b, I2C_CLIENT_END
+};
+
+static const struct i2c_device_id tmp102_id[] = {
+	{ DRIVER_NAME, 0 },
+	{ }
+};
+
+static struct i2c_driver tmp102_driver = {
+	.driver.name	= DRIVER_NAME,
+	.driver.pm	= TMP102_DEV_PM_OPS,
+	.class		= I2C_CLASS_HWMON,
+	.probe		= tmp102_probe,
+	.remove		= __devexit_p(tmp102_remove),
+	.id_table	= tmp102_id,
+	.detect		= tmp102_detect,
+	.address_list	= normal_i2c,
+};
+
+static int __init tmp102_init(void)
+{
+	return i2c_add_driver(&tmp102_driver);
+}
+module_init(tmp102_init);
+
+static void __init tmp102_exit(void)
+{
+	i2c_del_driver(&tmp102_driver);
+}
+module_exit(tmp102_exit);
+
+
+MODULE_AUTHOR("Steven King <sfking@fdwdc.com>");
+MODULE_DESCRIPTION("Texas Instruments TMP102 temperature sensor driver");
+MODULE_LICENSE("GPL");


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

* Re: [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature
  2010-02-04  1:23 ` Steven King
@ 2010-02-04 18:22   ` Andrew Morton
  -1 siblings, 0 replies; 18+ messages in thread
From: Andrew Morton @ 2010-02-04 18:22 UTC (permalink / raw)
  To: Steven King; +Cc: Jean Delvare, lm-sensors, linux-kernel

On Wed, 3 Feb 2010 17:23:49 -0800
Steven King <sfking@fdwdc.com> wrote:

> The TI TMP102 is similar to the lm75.  It differs from the lm75 by having a 16 bit conf register
> and the temp registers have a minimum resolution of 12bits; the extended conf register
> can select 13 bit resolution (which this driver does) and also change the update rate (which this
> driver currently doesn't use).
> 

A neat little driver.

checkpatch spits this warning:

    WARNING: struct dev_pm_ops should normally be const
    #387: FILE: drivers/hwmon/tmp102.c:300:
    +static struct dev_pm_ops tmp102_dev_pm_ops = {

which seems truthful enough.

--- a/drivers/hwmon/tmp102.c~hwmon-driver-for-ti-tmp102-temperature-sensor-checkpatch-fixes
+++ a/drivers/hwmon/tmp102.c
@@ -297,7 +297,7 @@ static int tmp102_resume(struct device *
 	return 0;
 }
 
-static struct dev_pm_ops tmp102_dev_pm_ops = {
+static const struct dev_pm_ops tmp102_dev_pm_ops = {
 	.suspend	= tmp102_suspend,
 	.resume		= tmp102_resume,
 };
_



And doing this will hurt readers' brains less:



Use conventional array-walk loop.

--- a/drivers/hwmon/tmp102.c~hwmon-driver-for-ti-tmp102-temperature-sensor-fix
+++ a/drivers/hwmon/tmp102.c
@@ -91,13 +91,14 @@ static struct tmp102 *tmp102_update_devi
 
 	mutex_lock(&tmp102->lock);
 	if (time_after(jiffies, tmp102->last_update + HZ / 4)) {
-		int i = 0;
-		do {
+		int i;
+		
+		for (i = 0; i < ARRAY_SIZE(tmp102->temp); i++) {
 			int status = tmp102_read_reg(client, tmp102_reg[i]);
 			if (status > -1)
 				tmp102->temp[i] = tmp102_reg_to_mC(status);
 
-		} while (++i < ARRAY_SIZE(tmp102->temp));
+		}
 		tmp102->last_update = jiffies;
 	}
 	mutex_unlock(&tmp102->lock);
_


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

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

* Re: [PATCH] hwmon: driver for TI tmp102 temperature sensor
@ 2010-02-04 18:22   ` Andrew Morton
  0 siblings, 0 replies; 18+ messages in thread
From: Andrew Morton @ 2010-02-04 18:22 UTC (permalink / raw)
  To: Steven King; +Cc: Jean Delvare, lm-sensors, linux-kernel

On Wed, 3 Feb 2010 17:23:49 -0800
Steven King <sfking@fdwdc.com> wrote:

> The TI TMP102 is similar to the lm75.  It differs from the lm75 by having a 16 bit conf register
> and the temp registers have a minimum resolution of 12bits; the extended conf register
> can select 13 bit resolution (which this driver does) and also change the update rate (which this
> driver currently doesn't use).
> 

A neat little driver.

checkpatch spits this warning:

    WARNING: struct dev_pm_ops should normally be const
    #387: FILE: drivers/hwmon/tmp102.c:300:
    +static struct dev_pm_ops tmp102_dev_pm_ops = {

which seems truthful enough.

--- a/drivers/hwmon/tmp102.c~hwmon-driver-for-ti-tmp102-temperature-sensor-checkpatch-fixes
+++ a/drivers/hwmon/tmp102.c
@@ -297,7 +297,7 @@ static int tmp102_resume(struct device *
 	return 0;
 }
 
-static struct dev_pm_ops tmp102_dev_pm_ops = {
+static const struct dev_pm_ops tmp102_dev_pm_ops = {
 	.suspend	= tmp102_suspend,
 	.resume		= tmp102_resume,
 };
_



And doing this will hurt readers' brains less:



Use conventional array-walk loop.

--- a/drivers/hwmon/tmp102.c~hwmon-driver-for-ti-tmp102-temperature-sensor-fix
+++ a/drivers/hwmon/tmp102.c
@@ -91,13 +91,14 @@ static struct tmp102 *tmp102_update_devi
 
 	mutex_lock(&tmp102->lock);
 	if (time_after(jiffies, tmp102->last_update + HZ / 4)) {
-		int i = 0;
-		do {
+		int i;
+		
+		for (i = 0; i < ARRAY_SIZE(tmp102->temp); i++) {
 			int status = tmp102_read_reg(client, tmp102_reg[i]);
 			if (status > -1)
 				tmp102->temp[i] = tmp102_reg_to_mC(status);
 
-		} while (++i < ARRAY_SIZE(tmp102->temp));
+		}
 		tmp102->last_update = jiffies;
 	}
 	mutex_unlock(&tmp102->lock);
_


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

* Re: [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature
  2010-02-04  1:23 ` Steven King
@ 2010-02-04 18:37   ` Jean Delvare
  -1 siblings, 0 replies; 18+ messages in thread
From: Jean Delvare @ 2010-02-04 18:37 UTC (permalink / raw)
  To: Steven King; +Cc: lm-sensors, linux-kernel

Hi Steven,

On Wed, 3 Feb 2010 17:23:49 -0800, Steven King wrote:
> The TI TMP102 is similar to the lm75.  It differs from the lm75 by having a 16 bit conf register
> and the temp registers have a minimum resolution of 12bits; the extended conf register
> can select 13 bit resolution (which this driver does) and also change the update rate (which this
> driver currently doesn't use).
> 
> Signed-off-by: Steven King <sfking@fdwdc.com>
> ---
> 
> Driver for the TI TMP102.

Could you please send a dump of your TMP102 chip, using i2cdump in word
mode?

-- 
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] 18+ messages in thread

* Re: [PATCH] hwmon: driver for TI tmp102 temperature sensor
@ 2010-02-04 18:37   ` Jean Delvare
  0 siblings, 0 replies; 18+ messages in thread
From: Jean Delvare @ 2010-02-04 18:37 UTC (permalink / raw)
  To: Steven King; +Cc: lm-sensors, linux-kernel

Hi Steven,

On Wed, 3 Feb 2010 17:23:49 -0800, Steven King wrote:
> The TI TMP102 is similar to the lm75.  It differs from the lm75 by having a 16 bit conf register
> and the temp registers have a minimum resolution of 12bits; the extended conf register
> can select 13 bit resolution (which this driver does) and also change the update rate (which this
> driver currently doesn't use).
> 
> Signed-off-by: Steven King <sfking@fdwdc.com>
> ---
> 
> Driver for the TI TMP102.

Could you please send a dump of your TMP102 chip, using i2cdump in word
mode?

-- 
Jean Delvare

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

* Re: [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature
  2010-02-04 18:22   ` [PATCH] hwmon: driver for TI tmp102 temperature sensor Andrew Morton
@ 2010-02-04 21:17     ` Steven King
  -1 siblings, 0 replies; 18+ messages in thread
From: Steven King @ 2010-02-04 21:17 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Jean Delvare, lm-sensors, linux-kernel

On Thursday 04 February 2010 10:22:03 Andrew Morton wrote:
> On Wed, 3 Feb 2010 17:23:49 -0800
>
> Steven King <sfking@fdwdc.com> wrote:
> > The TI TMP102 is similar to the lm75.  It differs from the lm75 by having
> > a 16 bit conf register and the temp registers have a minimum resolution
> > of 12bits; the extended conf register can select 13 bit resolution (which
> > this driver does) and also change the update rate (which this driver
> > currently doesn't use).
>
> A neat little driver.

Thanks.

> checkpatch spits this warning:
>
>     WARNING: struct dev_pm_ops should normally be const
>     #387: FILE: drivers/hwmon/tmp102.c:300:
>     +static struct dev_pm_ops tmp102_dev_pm_ops = {
>
> which seems truthful enough.

Indeed.   I am, however, somewhat surprised since I ran the patch thru 
checkpatch before posting it and no errors or warnings were reported.  Is 
there a version of checkpatch other than the one included in the tree that I 
should be using?

>
> And doing this will hurt readers' brains less:
>
>
>
> Use conventional array-walk loop.

Ah yes, an idiosyncrasy of mine in preferring do while over for loops 
especially when I 'know' the initial test will pass.  Whatever is the 
preferred idiom for the kernel is fine with me.

-- 
Steven King -- sfking at fdwdc dot com

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

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

* Re: [PATCH] hwmon: driver for TI tmp102 temperature sensor
@ 2010-02-04 21:17     ` Steven King
  0 siblings, 0 replies; 18+ messages in thread
From: Steven King @ 2010-02-04 21:17 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Jean Delvare, lm-sensors, linux-kernel

On Thursday 04 February 2010 10:22:03 Andrew Morton wrote:
> On Wed, 3 Feb 2010 17:23:49 -0800
>
> Steven King <sfking@fdwdc.com> wrote:
> > The TI TMP102 is similar to the lm75.  It differs from the lm75 by having
> > a 16 bit conf register and the temp registers have a minimum resolution
> > of 12bits; the extended conf register can select 13 bit resolution (which
> > this driver does) and also change the update rate (which this driver
> > currently doesn't use).
>
> A neat little driver.

Thanks.

> checkpatch spits this warning:
>
>     WARNING: struct dev_pm_ops should normally be const
>     #387: FILE: drivers/hwmon/tmp102.c:300:
>     +static struct dev_pm_ops tmp102_dev_pm_ops = {
>
> which seems truthful enough.

Indeed.   I am, however, somewhat surprised since I ran the patch thru 
checkpatch before posting it and no errors or warnings were reported.  Is 
there a version of checkpatch other than the one included in the tree that I 
should be using?

>
> And doing this will hurt readers' brains less:
>
>
>
> Use conventional array-walk loop.

Ah yes, an idiosyncrasy of mine in preferring do while over for loops 
especially when I 'know' the initial test will pass.  Whatever is the 
preferred idiom for the kernel is fine with me.

-- 
Steven King -- sfking at fdwdc dot com

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

* Re: [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature
  2010-02-04 21:17     ` [PATCH] hwmon: driver for TI tmp102 temperature sensor Steven King
@ 2010-02-04 21:26       ` Andrew Morton
  -1 siblings, 0 replies; 18+ messages in thread
From: Andrew Morton @ 2010-02-04 21:26 UTC (permalink / raw)
  To: Steven King; +Cc: Jean Delvare, lm-sensors, linux-kernel

On Thu, 4 Feb 2010 13:17:37 -0800
Steven King <sfking@fdwdc.com> wrote:

> > checkpatch spits this warning:
> >
> >     WARNING: struct dev_pm_ops should normally be const
> >     #387: FILE: drivers/hwmon/tmp102.c:300:
> >     +static struct dev_pm_ops tmp102_dev_pm_ops = {
> >
> > which seems truthful enough.
> 
> Indeed.   I am, however, somewhat surprised since I ran the patch thru 
> checkpatch before posting it and no errors or warnings were reported.  Is 
> there a version of checkpatch other than the one included in the tree that I 
> should be using?

It was -mm's
checkpatchpl-extend-list-of-expected-to-be-const-structures.patch which
found this.


From: Emese Revfy <re.emese@gmail.com>

Based on Arjan's suggestion, extend the list of ops structures that should
be const.

Signed-off-by: Emese Revfy <re.emese@gmail.com>
Cc: Andy Whitcroft <apw@shadowen.org>
Cc: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 scripts/checkpatch.pl |   41 ++++++++++++++++++++++++++++++++++++++--
 1 file changed, 39 insertions(+), 2 deletions(-)

diff -puN scripts/checkpatch.pl~checkpatchpl-extend-list-of-expected-to-be-const-structures scripts/checkpatch.pl
--- a/scripts/checkpatch.pl~checkpatchpl-extend-list-of-expected-to-be-const-structures
+++ a/scripts/checkpatch.pl
@@ -2654,9 +2654,46 @@ sub process {
 		if ($line =~ /^.\s*__initcall\s*\(/) {
 			WARN("please use device_initcall() instead of __initcall()\n" . $herecurr);
 		}
-# check for struct file_operations, ensure they are const.
+# check for various ops structs, ensure they are const.
+		my $struct_ops = qr{acpi_dock_ops|
+				address_space_operations|
+				backlight_ops|
+				block_device_operations|
+				dentry_operations|
+				dev_pm_ops|
+				dma_map_ops|
+				extent_io_ops|
+				file_lock_operations|
+				file_operations|
+				hv_ops|
+				ide_dma_ops|
+				intel_dvo_dev_ops|
+				item_operations|
+				iwl_ops|
+				kgdb_arch|
+				kgdb_io|
+				kset_uevent_ops|
+				lock_manager_operations|
+				microcode_ops|
+				mtrr_ops|
+				neigh_ops|
+				nlmsvc_binding|
+				pci_raw_ops|
+				pipe_buf_operations|
+				platform_hibernation_ops|
+				platform_suspend_ops|
+				proto_ops|
+				rpc_pipe_ops|
+				seq_operations|
+				snd_ac97_build_ops|
+				soc_pcmcia_socket_ops|
+				stacktrace_ops|
+				sysfs_ops|
+				tty_operations|
+				usb_mon_operations|
+				wd_ops}x;
 		if ($line !~ /\bconst\b/ &&
-		    $line =~ /\bstruct\s+(file_operations|seq_operations)\b/) {
+		    $line =~ /\bstruct\s+($struct_ops)\b/) {
 			WARN("struct $1 should normally be const\n" .
 				$herecurr);
 		}
_


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

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

* Re: [PATCH] hwmon: driver for TI tmp102 temperature sensor
@ 2010-02-04 21:26       ` Andrew Morton
  0 siblings, 0 replies; 18+ messages in thread
From: Andrew Morton @ 2010-02-04 21:26 UTC (permalink / raw)
  To: Steven King; +Cc: Jean Delvare, lm-sensors, linux-kernel

On Thu, 4 Feb 2010 13:17:37 -0800
Steven King <sfking@fdwdc.com> wrote:

> > checkpatch spits this warning:
> >
> >     WARNING: struct dev_pm_ops should normally be const
> >     #387: FILE: drivers/hwmon/tmp102.c:300:
> >     +static struct dev_pm_ops tmp102_dev_pm_ops = {
> >
> > which seems truthful enough.
> 
> Indeed.   I am, however, somewhat surprised since I ran the patch thru 
> checkpatch before posting it and no errors or warnings were reported.  Is 
> there a version of checkpatch other than the one included in the tree that I 
> should be using?

It was -mm's
checkpatchpl-extend-list-of-expected-to-be-const-structures.patch which
found this.


From: Emese Revfy <re.emese@gmail.com>

Based on Arjan's suggestion, extend the list of ops structures that should
be const.

Signed-off-by: Emese Revfy <re.emese@gmail.com>
Cc: Andy Whitcroft <apw@shadowen.org>
Cc: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 scripts/checkpatch.pl |   41 ++++++++++++++++++++++++++++++++++++++--
 1 file changed, 39 insertions(+), 2 deletions(-)

diff -puN scripts/checkpatch.pl~checkpatchpl-extend-list-of-expected-to-be-const-structures scripts/checkpatch.pl
--- a/scripts/checkpatch.pl~checkpatchpl-extend-list-of-expected-to-be-const-structures
+++ a/scripts/checkpatch.pl
@@ -2654,9 +2654,46 @@ sub process {
 		if ($line =~ /^.\s*__initcall\s*\(/) {
 			WARN("please use device_initcall() instead of __initcall()\n" . $herecurr);
 		}
-# check for struct file_operations, ensure they are const.
+# check for various ops structs, ensure they are const.
+		my $struct_ops = qr{acpi_dock_ops|
+				address_space_operations|
+				backlight_ops|
+				block_device_operations|
+				dentry_operations|
+				dev_pm_ops|
+				dma_map_ops|
+				extent_io_ops|
+				file_lock_operations|
+				file_operations|
+				hv_ops|
+				ide_dma_ops|
+				intel_dvo_dev_ops|
+				item_operations|
+				iwl_ops|
+				kgdb_arch|
+				kgdb_io|
+				kset_uevent_ops|
+				lock_manager_operations|
+				microcode_ops|
+				mtrr_ops|
+				neigh_ops|
+				nlmsvc_binding|
+				pci_raw_ops|
+				pipe_buf_operations|
+				platform_hibernation_ops|
+				platform_suspend_ops|
+				proto_ops|
+				rpc_pipe_ops|
+				seq_operations|
+				snd_ac97_build_ops|
+				soc_pcmcia_socket_ops|
+				stacktrace_ops|
+				sysfs_ops|
+				tty_operations|
+				usb_mon_operations|
+				wd_ops}x;
 		if ($line !~ /\bconst\b/ &&
-		    $line =~ /\bstruct\s+(file_operations|seq_operations)\b/) {
+		    $line =~ /\bstruct\s+($struct_ops)\b/) {
 			WARN("struct $1 should normally be const\n" .
 				$herecurr);
 		}
_


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

* Re: [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature
  2010-02-04 18:37   ` [PATCH] hwmon: driver for TI tmp102 temperature sensor Jean Delvare
@ 2010-02-04 21:57     ` Steven King
  -1 siblings, 0 replies; 18+ messages in thread
From: Steven King @ 2010-02-04 21:57 UTC (permalink / raw)
  To: Jean Delvare; +Cc: lm-sensors, linux-kernel

On Thursday 04 February 2010 10:37:12 Jean Delvare wrote:
> Hi Steven,
>
> On Wed, 3 Feb 2010 17:23:49 -0800, Steven King wrote:
> > The TI TMP102 is similar to the lm75.  It differs from the lm75 by having
> > a 16 bit conf register and the temp registers have a minimum resolution
> > of 12bits; the extended conf register can select 13 bit resolution (which
> > this driver does) and also change the update rate (which this driver
> > currently doesn't use).
> >
> > Signed-off-by: Steven King <sfking@fdwdc.com>
> > ---
> >
> > Driver for the TI TMP102.
>
> Could you please send a dump of your TMP102 chip, using i2cdump in word
> mode?

sure, like so?

# ./i2cdump 0 0x4a w
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x4a, mode word
Continue? [Y/n] y
     0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
00: d90c b062 002d 004b c01a d006 0000 0000
08: d90c b062 002d 004b c01a d006 0000 0000
10: d90c b062 002d 004b c01a d006 0000 0000
18: d90c b062 002d 004b c01a d006 0000 0000
20: d90c b062 002d 004b c01a d006 0000 0000
28: d90c b062 002d 004b c01a d006 0000 0000
30: d90c b062 002d 004b c01a d006 0000 0000
38: d90c b062 002d 004b c01a d006 0000 0000
40: d90c b062 002d 004b c01a d006 0000 0000
48: d90c b062 002d 004b c01a d006 0000 0000
50: d90c b062 002d 004b c01a d006 0000 0000
58: d90c b062 002d 004b c01a d006 0000 0000
60: d90c b062 002d 004b c01a d006 0000 0000
68: d90c b062 002d 004b c01a d006 0000 0000
70: d90c b062 002d 004b c01a d006 0000 0000
78: d90c b062 002d 004b c01a d006 0000 0000
80: d90c b062 002d 004b c01a d006 0000 0000
88: d90c b062 002d 004b c01a d006 0000 0000
90: d90c b062 002d 004b c01a d006 0000 0000
98: d90c b062 002d 004b c01a d006 0000 0000
a0: d90c b062 002d 004b c01a d006 0000 0000
a8: d90c b062 002d 004b c01a d006 0000 0000
b0: d90c b062 002d 004b c01a d006 0000 0000
b8: d90c b062 002d 004b c01a d006 0000 0000
c0: d90c b062 002d 004b c01a d006 0000 0000
c8: d90c b062 002d 004b c01a d006 0000 0000
d0: d90c b062 002d 004b c01a d006 0000 0000
d8: d90c b062 002d 004b c01a d006 0000 0000
e0: d10c b062 002d 004b c01a d006 0000 0000
e8: d10c b062 002d 004b c01a d006 0000 0000
f0: d10c b062 002d 004b c01a d006 0000 0000
f8: d10c b062 002d 004b c01a d006 0000 0000
# 

-- 
Steven King -- sfking at fdwdc dot com


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

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

* Re: [PATCH] hwmon: driver for TI tmp102 temperature sensor
@ 2010-02-04 21:57     ` Steven King
  0 siblings, 0 replies; 18+ messages in thread
From: Steven King @ 2010-02-04 21:57 UTC (permalink / raw)
  To: Jean Delvare; +Cc: lm-sensors, linux-kernel

On Thursday 04 February 2010 10:37:12 Jean Delvare wrote:
> Hi Steven,
>
> On Wed, 3 Feb 2010 17:23:49 -0800, Steven King wrote:
> > The TI TMP102 is similar to the lm75.  It differs from the lm75 by having
> > a 16 bit conf register and the temp registers have a minimum resolution
> > of 12bits; the extended conf register can select 13 bit resolution (which
> > this driver does) and also change the update rate (which this driver
> > currently doesn't use).
> >
> > Signed-off-by: Steven King <sfking@fdwdc.com>
> > ---
> >
> > Driver for the TI TMP102.
>
> Could you please send a dump of your TMP102 chip, using i2cdump in word
> mode?

sure, like so?

# ./i2cdump 0 0x4a w
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x4a, mode word
Continue? [Y/n] y
     0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
00: d90c b062 002d 004b c01a d006 0000 0000
08: d90c b062 002d 004b c01a d006 0000 0000
10: d90c b062 002d 004b c01a d006 0000 0000
18: d90c b062 002d 004b c01a d006 0000 0000
20: d90c b062 002d 004b c01a d006 0000 0000
28: d90c b062 002d 004b c01a d006 0000 0000
30: d90c b062 002d 004b c01a d006 0000 0000
38: d90c b062 002d 004b c01a d006 0000 0000
40: d90c b062 002d 004b c01a d006 0000 0000
48: d90c b062 002d 004b c01a d006 0000 0000
50: d90c b062 002d 004b c01a d006 0000 0000
58: d90c b062 002d 004b c01a d006 0000 0000
60: d90c b062 002d 004b c01a d006 0000 0000
68: d90c b062 002d 004b c01a d006 0000 0000
70: d90c b062 002d 004b c01a d006 0000 0000
78: d90c b062 002d 004b c01a d006 0000 0000
80: d90c b062 002d 004b c01a d006 0000 0000
88: d90c b062 002d 004b c01a d006 0000 0000
90: d90c b062 002d 004b c01a d006 0000 0000
98: d90c b062 002d 004b c01a d006 0000 0000
a0: d90c b062 002d 004b c01a d006 0000 0000
a8: d90c b062 002d 004b c01a d006 0000 0000
b0: d90c b062 002d 004b c01a d006 0000 0000
b8: d90c b062 002d 004b c01a d006 0000 0000
c0: d90c b062 002d 004b c01a d006 0000 0000
c8: d90c b062 002d 004b c01a d006 0000 0000
d0: d90c b062 002d 004b c01a d006 0000 0000
d8: d90c b062 002d 004b c01a d006 0000 0000
e0: d10c b062 002d 004b c01a d006 0000 0000
e8: d10c b062 002d 004b c01a d006 0000 0000
f0: d10c b062 002d 004b c01a d006 0000 0000
f8: d10c b062 002d 004b c01a d006 0000 0000
# 

-- 
Steven King -- sfking at fdwdc dot com


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

* Re: [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature
  2010-02-04 21:57     ` [PATCH] hwmon: driver for TI tmp102 temperature sensor Steven King
@ 2010-02-05  8:12       ` Jean Delvare
  -1 siblings, 0 replies; 18+ messages in thread
From: Jean Delvare @ 2010-02-05  8:12 UTC (permalink / raw)
  To: Steven King; +Cc: lm-sensors, linux-kernel

On Thu, 4 Feb 2010 13:57:06 -0800, Steven King wrote:
> On Thursday 04 February 2010 10:37:12 Jean Delvare wrote:
> > Could you please send a dump of your TMP102 chip, using i2cdump in word
> > mode?
> 
> sure, like so?
> 
> # ./i2cdump 0 0x4a w
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-0, address 0x4a, mode word
> Continue? [Y/n] y
>      0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
> 00: d90c b062 002d 004b c01a d006 0000 0000
> 08: d90c b062 002d 004b c01a d006 0000 0000
> 10: d90c b062 002d 004b c01a d006 0000 0000
> 18: d90c b062 002d 004b c01a d006 0000 0000
> 20: d90c b062 002d 004b c01a d006 0000 0000
> 28: d90c b062 002d 004b c01a d006 0000 0000
> 30: d90c b062 002d 004b c01a d006 0000 0000
> 38: d90c b062 002d 004b c01a d006 0000 0000
> 40: d90c b062 002d 004b c01a d006 0000 0000
> 48: d90c b062 002d 004b c01a d006 0000 0000
> 50: d90c b062 002d 004b c01a d006 0000 0000
> 58: d90c b062 002d 004b c01a d006 0000 0000
> 60: d90c b062 002d 004b c01a d006 0000 0000
> 68: d90c b062 002d 004b c01a d006 0000 0000
> 70: d90c b062 002d 004b c01a d006 0000 0000
> 78: d90c b062 002d 004b c01a d006 0000 0000
> 80: d90c b062 002d 004b c01a d006 0000 0000
> 88: d90c b062 002d 004b c01a d006 0000 0000
> 90: d90c b062 002d 004b c01a d006 0000 0000
> 98: d90c b062 002d 004b c01a d006 0000 0000
> a0: d90c b062 002d 004b c01a d006 0000 0000
> a8: d90c b062 002d 004b c01a d006 0000 0000
> b0: d90c b062 002d 004b c01a d006 0000 0000
> b8: d90c b062 002d 004b c01a d006 0000 0000
> c0: d90c b062 002d 004b c01a d006 0000 0000
> c8: d90c b062 002d 004b c01a d006 0000 0000
> d0: d90c b062 002d 004b c01a d006 0000 0000
> d8: d90c b062 002d 004b c01a d006 0000 0000
> e0: d10c b062 002d 004b c01a d006 0000 0000
> e8: d10c b062 002d 004b c01a d006 0000 0000
> f0: d10c b062 002d 004b c01a d006 0000 0000
> f8: d10c b062 002d 004b c01a d006 0000 0000
> # 

Exactly, thank you!

-- 
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] 18+ messages in thread

* Re: [PATCH] hwmon: driver for TI tmp102 temperature sensor
@ 2010-02-05  8:12       ` Jean Delvare
  0 siblings, 0 replies; 18+ messages in thread
From: Jean Delvare @ 2010-02-05  8:12 UTC (permalink / raw)
  To: Steven King; +Cc: lm-sensors, linux-kernel

On Thu, 4 Feb 2010 13:57:06 -0800, Steven King wrote:
> On Thursday 04 February 2010 10:37:12 Jean Delvare wrote:
> > Could you please send a dump of your TMP102 chip, using i2cdump in word
> > mode?
> 
> sure, like so?
> 
> # ./i2cdump 0 0x4a w
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-0, address 0x4a, mode word
> Continue? [Y/n] y
>      0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
> 00: d90c b062 002d 004b c01a d006 0000 0000
> 08: d90c b062 002d 004b c01a d006 0000 0000
> 10: d90c b062 002d 004b c01a d006 0000 0000
> 18: d90c b062 002d 004b c01a d006 0000 0000
> 20: d90c b062 002d 004b c01a d006 0000 0000
> 28: d90c b062 002d 004b c01a d006 0000 0000
> 30: d90c b062 002d 004b c01a d006 0000 0000
> 38: d90c b062 002d 004b c01a d006 0000 0000
> 40: d90c b062 002d 004b c01a d006 0000 0000
> 48: d90c b062 002d 004b c01a d006 0000 0000
> 50: d90c b062 002d 004b c01a d006 0000 0000
> 58: d90c b062 002d 004b c01a d006 0000 0000
> 60: d90c b062 002d 004b c01a d006 0000 0000
> 68: d90c b062 002d 004b c01a d006 0000 0000
> 70: d90c b062 002d 004b c01a d006 0000 0000
> 78: d90c b062 002d 004b c01a d006 0000 0000
> 80: d90c b062 002d 004b c01a d006 0000 0000
> 88: d90c b062 002d 004b c01a d006 0000 0000
> 90: d90c b062 002d 004b c01a d006 0000 0000
> 98: d90c b062 002d 004b c01a d006 0000 0000
> a0: d90c b062 002d 004b c01a d006 0000 0000
> a8: d90c b062 002d 004b c01a d006 0000 0000
> b0: d90c b062 002d 004b c01a d006 0000 0000
> b8: d90c b062 002d 004b c01a d006 0000 0000
> c0: d90c b062 002d 004b c01a d006 0000 0000
> c8: d90c b062 002d 004b c01a d006 0000 0000
> d0: d90c b062 002d 004b c01a d006 0000 0000
> d8: d90c b062 002d 004b c01a d006 0000 0000
> e0: d10c b062 002d 004b c01a d006 0000 0000
> e8: d10c b062 002d 004b c01a d006 0000 0000
> f0: d10c b062 002d 004b c01a d006 0000 0000
> f8: d10c b062 002d 004b c01a d006 0000 0000
> # 

Exactly, thank you!

-- 
Jean Delvare

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

* Re: [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature
  2010-02-04  1:23 ` Steven King
                   ` (2 preceding siblings ...)
  (?)
@ 2010-03-06  8:35 ` Jean Delvare
  -1 siblings, 0 replies; 18+ messages in thread
From: Jean Delvare @ 2010-03-06  8:35 UTC (permalink / raw)
  To: lm-sensors

Hi Andrew,

Adding back Steven and the lm-sensors list...

On Fri, 5 Mar 2010 11:53:42 -0800, Andrew Morton wrote:
> So you're OK with the patch as-is?

I did not review it. And testing it doesn't seem positive. First of
all, I get the following in my logs after loading the driver:

 (null): not a tmp102

Which suggests the use of an uninitialized device struct. Also, the
detection fails early, I don't think the detection routine works.
Looking at the code, it doesn't seem to correspond to the TMP102
register map at all (assuming the dump I got from Steven is really from
a TMP102) Steven, did you ever test it? Honestly, I don't think it
makes sense to have a detect routine for this chip, given that it lacks
identification registers. We relied on ugly detection quirks for the
LM75 only because that chip was very popular on PC motherboards at one
point in time. For devices used on embedded designs and which are
always enumerated, we don't need detection routines.

Then, using the tmp102 driver on the dump sent by Steven produces the
following "sensors" output:

tmp102-i2c-3-48
Adapter: SMBus stub driver
temp1:        +2.6°C  (high = +15.0°C, hyst =  +9.0°C)  

These values are suspiciously low and smell like the wrong base unit is
used (1/100 °C instead of 1/1000 °C). Quick code examination seems to
confirm this.

So, no, I am not OK with the patch as-is, it needs more work.

-- 
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] 18+ messages in thread

* Re: [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature
  2010-02-04  1:23 ` Steven King
                   ` (3 preceding siblings ...)
  (?)
@ 2010-03-06 16:16 ` Steven King
  -1 siblings, 0 replies; 18+ messages in thread
From: Steven King @ 2010-03-06 16:16 UTC (permalink / raw)
  To: lm-sensors

On Saturday 06 March 2010 12:35:21 Jean Delvare wrote:
> Hi Andrew,
>
> Adding back Steven and the lm-sensors list...
>
> On Fri, 5 Mar 2010 11:53:42 -0800, Andrew Morton wrote:
> > So you're OK with the patch as-is?
>
> I did not review it. And testing it doesn't seem positive. First of
> all, I get the following in my logs after loading the driver:
>
>  (null): not a tmp102
>
> Which suggests the use of an uninitialized device struct. Also, the
> detection fails early, I don't think the detection routine works.
> Looking at the code, it doesn't seem to correspond to the TMP102
> register map at all (assuming the dump I got from Steven is really from
> a TMP102) Steven, did you ever test it? Honestly, I don't think it
> makes sense to have a detect routine for this chip, given that it lacks
> identification registers. We relied on ugly detection quirks for the
> LM75 only because that chip was very popular on PC motherboards at one
> point in time. For devices used on embedded designs and which are
> always enumerated, we don't need detection routines.

For my specific use the part is connected to an embedded system and is always 
enumerated; as lm-sensors doesnt build for this target I wasnt aware of any 
way to test the detection code.  I certainly wouldnt have any problem with 
removing the detection routine entirely...

> Then, using the tmp102 driver on the dump sent by Steven produces the
> following "sensors" output:
>
> tmp102-i2c-3-48
> Adapter: SMBus stub driver
> temp1:        +2.6°C  (high = +15.0°C, hyst =  +9.0°C)
>
> These values are suspiciously low and smell like the wrong base unit is
> used (1/100 °C instead of 1/1000 °C). Quick code examination seems to
> confirm this.

Doh!  My bad.

> So, no, I am not OK with the patch as-is, it needs more work.

Okay, so besides removing the detect routine, incorporating Andrew's patch and 
fixing the base for the temperature conversion, was there anything else I 
need to do for v2?

-- 
Steven King -- sfking at fdwdc dot com

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

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

* Re: [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature
  2010-02-04  1:23 ` Steven King
                   ` (4 preceding siblings ...)
  (?)
@ 2010-03-07 12:23 ` Jean Delvare
  -1 siblings, 0 replies; 18+ messages in thread
From: Jean Delvare @ 2010-03-07 12:23 UTC (permalink / raw)
  To: lm-sensors

Hi Steven,

On Sat, 6 Mar 2010 08:16:54 -0800, Steven King wrote:
> On Saturday 06 March 2010 12:35:21 Jean Delvare wrote:
> > I did not review it. And testing it doesn't seem positive. First of
> > all, I get the following in my logs after loading the driver:
> >
> >  (null): not a tmp102
> >
> > Which suggests the use of an uninitialized device struct. Also, the
> > detection fails early, I don't think the detection routine works.
> > Looking at the code, it doesn't seem to correspond to the TMP102
> > register map at all (assuming the dump I got from Steven is really from
> > a TMP102) Steven, did you ever test it? Honestly, I don't think it
> > makes sense to have a detect routine for this chip, given that it lacks
> > identification registers. We relied on ugly detection quirks for the
> > LM75 only because that chip was very popular on PC motherboards at one
> > point in time. For devices used on embedded designs and which are
> > always enumerated, we don't need detection routines.
> 
> For my specific use the part is connected to an embedded system and is always 
> enumerated; as lm-sensors doesnt build for this target I wasnt aware of any 

Out of curiosity, why is lm-sensors not building? What is missing?

> way to test the detection code.  I certainly wouldnt have any problem with 
> removing the detection routine entirely...

I'm fine with this.

> > Then, using the tmp102 driver on the dump sent by Steven produces the
> > following "sensors" output:
> >
> > tmp102-i2c-3-48
> > Adapter: SMBus stub driver
> > temp1:        +2.6°C  (high = +15.0°C, hyst =  +9.0°C)
> >
> > These values are suspiciously low and smell like the wrong base unit is
> > used (1/100 °C instead of 1/1000 °C). Quick code examination seems to
> > confirm this.
> 
> Doh!  My bad.
> 
> > So, no, I am not OK with the patch as-is, it needs more work.
> 
> Okay, so besides removing the detect routine, incorporating Andrew's patch and 
> fixing the base for the temperature conversion, was there anything else I 
> need to do for v2?

Nothing spotted by my quick look, but I didn't actually review your
code. If you post an updated version of your patch, I could review 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] 18+ messages in thread

* Re: [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature
  2010-02-04  1:23 ` Steven King
                   ` (5 preceding siblings ...)
  (?)
@ 2010-03-14  3:29 ` Steven King
  -1 siblings, 0 replies; 18+ messages in thread
From: Steven King @ 2010-03-14  3:29 UTC (permalink / raw)
  To: lm-sensors

On Sunday 07 March 2010 04:23:38 Jean Delvare wrote:
> Hi Steven,

Hi Jean,

> >
> > For my specific use the part is connected to an embedded system and is
> > always enumerated; as lm-sensors doesnt build for this target I wasnt
> > aware of any
>
> Out of curiosity, why is lm-sensors not building? What is missing?

The target is nommu (coldfire) and the build failed with a bunch of
'ERROR: reloc type R_68K_32 is not supported for PIC'.  Probably trivial to 
fix but I havent had the chance to look at it yet.

>
> Nothing spotted by my quick look, but I didn't actually review your
> code. If you post an updated version of your patch, I could review it.

Great!  I'll get an updated patch out right away.


-- 
Steven King -- sfking at fdwdc dot com

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

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

end of thread, other threads:[~2010-03-14  3:29 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-04  1:23 [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature sensor Steven King
2010-02-04  1:23 ` Steven King
2010-02-04 18:22 ` [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature Andrew Morton
2010-02-04 18:22   ` [PATCH] hwmon: driver for TI tmp102 temperature sensor Andrew Morton
2010-02-04 21:17   ` [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature Steven King
2010-02-04 21:17     ` [PATCH] hwmon: driver for TI tmp102 temperature sensor Steven King
2010-02-04 21:26     ` [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature Andrew Morton
2010-02-04 21:26       ` [PATCH] hwmon: driver for TI tmp102 temperature sensor Andrew Morton
2010-02-04 18:37 ` [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature Jean Delvare
2010-02-04 18:37   ` [PATCH] hwmon: driver for TI tmp102 temperature sensor Jean Delvare
2010-02-04 21:57   ` [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature Steven King
2010-02-04 21:57     ` [PATCH] hwmon: driver for TI tmp102 temperature sensor Steven King
2010-02-05  8:12     ` [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature Jean Delvare
2010-02-05  8:12       ` [PATCH] hwmon: driver for TI tmp102 temperature sensor Jean Delvare
2010-03-06  8:35 ` [lm-sensors] [PATCH] hwmon: driver for TI tmp102 temperature Jean Delvare
2010-03-06 16:16 ` Steven King
2010-03-07 12:23 ` Jean Delvare
2010-03-14  3:29 ` Steven King

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.