* [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.