Some small bugfixes and enhancements.
Documentation/hwmon/jc42 | 21 +++++++++++++++------
drivers/hwmon/Kconfig | 11 ++++++-----
drivers/hwmon/jc42.c | 35 ++++++++++++++++++++++++++++++-----
3 files changed, 51 insertions(+), 16 deletions(-)
In set_temp_crit_hyst(), make the variable 'val' have the correct
type for strict_strtoul().
Signed-off-by: Clemens Ladisch <[email protected]>
---
drivers/hwmon/jc42.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hwmon/jc42.c
+++ b/drivers/hwmon/jc42.c
@@ -332,7 +332,7 @@ static ssize_t set_temp_crit_hyst(struct
{
struct i2c_client *client = to_i2c_client(dev);
struct jc42_data *data = i2c_get_clientdata(client);
- long val;
+ unsigned long val;
int diff, hyst;
int err;
int ret = count;
The documentation lists standard numbers and chip names in excruciating
detail, but that's all it does. To help mere mortals in deciding
whether to enable this driver, mention what this sensor is for and in
which systems it might be found.
Also add a link to the actual JC 42.4 specification.
Signed-off-by: Clemens Ladisch <[email protected]>
---
Documentation/hwmon/jc42 | 9 +++++++--
drivers/hwmon/Kconfig | 11 ++++++-----
2 files changed, 13 insertions(+), 7 deletions(-)
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -455,13 +455,14 @@ config SENSORS_JZ4740
called jz4740-hwmon.
config SENSORS_JC42
- tristate "JEDEC JC42.4 compliant temperature sensors"
+ tristate "JEDEC JC42.4 compliant memory module temperature sensors"
depends on I2C
help
- If you say yes here you get support for Jedec JC42.4 compliant
- temperature sensors. Support will include, but not be limited to,
- ADT7408, CAT34TS02,, CAT6095, MAX6604, MCP9805, MCP98242, MCP98243,
- MCP9843, SE97, SE98, STTS424, TSE2002B3, and TS3000B3.
+ If you say yes here, you get support for JEDEC JC42.4 compliant
+ temperature sensors, which are used on many DDR3 memory modules for
+ mobile devices and servers. Support will include, but not be limited
+ to, ADT7408, CAT34TS02, CAT6095, MAX6604, MCP9805, MCP98242, MCP98243,
+ MCP9843, SE97, SE98, STTS424(E), TSE2002B3, and TS3000B3.
This driver can also be built as a module. If so, the module
will be called jc42.
--- a/Documentation/hwmon/jc42
+++ b/Documentation/hwmon/jc42
@@ -51,7 +51,8 @@ Supported chips:
* JEDEC JC 42.4 compliant temperature sensor chips
Prefix: 'jc42'
Addresses scanned: I2C 0x18 - 0x1f
- Datasheet: -
+ Datasheet:
+ http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf
Author:
Guenter Roeck <[email protected]>
@@ -60,7 +61,11 @@ Author:
Description
-----------
-This driver implements support for JEDEC JC 42.4 compliant temperature sensors.
+This driver implements support for JEDEC JC 42.4 compliant temperature sensors,
+which are used on many DDR3 memory modules for mobile devices and servers. Some
+systems use the sensor to prevent memory overheating by automatically throttling
+the memory controller.
+
The driver auto-detects the chips listed above, but can be manually instantiated
to support other JC 42.4 compliant chips.
On systems where the temperature sensor is actually used, the BIOS is
likely to have locked the alarm registers. In that case, all writes
through the corresponding sysfs files would be silently ignored.
To prevent this, detect the locks and make the affected sysfs files
read-only.
Signed-off-by: Clemens Ladisch <[email protected]>
---
Documentation/hwmon/jc42 | 12 ++++++++----
drivers/hwmon/jc42.c | 33 +++++++++++++++++++++++++++++----
2 files changed, 37 insertions(+), 8 deletions(-)
--- a/Documentation/hwmon/jc42
+++ b/Documentation/hwmon/jc42
@@ -86,15 +86,19 @@ limits. The chip supports only a single
which applies to all limits. This register can be written by writing into
temp1_crit_hyst. Other hysteresis attributes are read-only.
+If the BIOS has configured the sensor for automatic temperature management, it
+is likely that it has locked the registers, i.e., that the temperature limits
+cannot be changed.
+
Sysfs entries
-------------
temp1_input Temperature (RO)
-temp1_min Minimum temperature (RW)
-temp1_max Maximum temperature (RW)
-temp1_crit Critical high temperature (RW)
+temp1_min Minimum temperature (RO or RW)
+temp1_max Maximum temperature (RO or RW)
+temp1_crit Critical high temperature (RO or RW)
-temp1_crit_hyst Critical hysteresis temperature (RW)
+temp1_crit_hyst Critical hysteresis temperature (RO or RW)
temp1_max_hyst Maximum hysteresis temperature (RO)
temp1_min_alarm Temperature low alarm
--- a/drivers/hwmon/jc42.c
+++ b/drivers/hwmon/jc42.c
@@ -53,6 +53,8 @@ static const unsigned short normal_i2c[]
/* Configuration register defines */
#define JC42_CFG_CRIT_ONLY (1 << 2)
+#define JC42_CFG_TCRIT_LOCK (1 << 6)
+#define JC42_CFG_EVENT_LOCK (1 << 7)
#define JC42_CFG_SHUTDOWN (1 << 8)
#define JC42_CFG_HYST_SHIFT 9
#define JC42_CFG_HYST_MASK 0x03
@@ -380,14 +382,14 @@ static ssize_t show_alarm(struct device
static DEVICE_ATTR(temp1_input, S_IRUGO,
show_temp_input, NULL);
-static DEVICE_ATTR(temp1_crit, S_IWUSR | S_IRUGO,
+static DEVICE_ATTR(temp1_crit, S_IRUGO,
show_temp_crit, set_temp_crit);
-static DEVICE_ATTR(temp1_min, S_IWUSR | S_IRUGO,
+static DEVICE_ATTR(temp1_min, S_IRUGO,
show_temp_min, set_temp_min);
-static DEVICE_ATTR(temp1_max, S_IWUSR | S_IRUGO,
+static DEVICE_ATTR(temp1_max, S_IRUGO,
show_temp_max, set_temp_max);
-static DEVICE_ATTR(temp1_crit_hyst, S_IWUSR | S_IRUGO,
+static DEVICE_ATTR(temp1_crit_hyst, S_IRUGO,
show_temp_crit_hyst, set_temp_crit_hyst);
static DEVICE_ATTR(temp1_max_hyst, S_IRUGO,
show_temp_max_hyst, NULL);
@@ -412,8 +414,31 @@ static struct attribute *jc42_attributes
NULL
};
+static mode_t jc42_attribute_mode(struct kobject *kobj,
+ struct attribute *attr, int index)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct jc42_data *data = i2c_get_clientdata(client);
+ unsigned int config = data->config;
+ bool readonly;
+
+ if (attr == &dev_attr_temp1_crit.attr)
+ readonly = config & JC42_CFG_TCRIT_LOCK;
+ else if (attr == &dev_attr_temp1_min.attr ||
+ attr == &dev_attr_temp1_max.attr)
+ readonly = config & JC42_CFG_EVENT_LOCK;
+ else if (attr == &dev_attr_temp1_crit_hyst.attr)
+ readonly = config & (JC42_CFG_EVENT_LOCK | JC42_CFG_TCRIT_LOCK);
+ else
+ readonly = true;
+
+ return S_IRUGO | (readonly ? 0 : S_IWUSR);
+}
+
static const struct attribute_group jc42_group = {
.attrs = jc42_attributes,
+ .is_visible = jc42_attribute_mode,
};
/* Return 0 if detection is successful, -ENODEV otherwise */
Hi Clemens,
On Wed, Feb 16, 2011 at 08:02:38AM -0500, Clemens Ladisch wrote:
> On systems where the temperature sensor is actually used, the BIOS is
> likely to have locked the alarm registers. In that case, all writes
> through the corresponding sysfs files would be silently ignored.
>
> To prevent this, detect the locks and make the affected sysfs files
> read-only.
>
> Signed-off-by: Clemens Ladisch <[email protected]>
> ---
> Documentation/hwmon/jc42 | 12 ++++++++----
> drivers/hwmon/jc42.c | 33 +++++++++++++++++++++++++++++----
> 2 files changed, 37 insertions(+), 8 deletions(-)
>
> --- a/Documentation/hwmon/jc42
> +++ b/Documentation/hwmon/jc42
> @@ -86,15 +86,19 @@ limits. The chip supports only a single
> which applies to all limits. This register can be written by writing into
> temp1_crit_hyst. Other hysteresis attributes are read-only.
>
> +If the BIOS has configured the sensor for automatic temperature management, it
> +is likely that it has locked the registers, i.e., that the temperature limits
> +cannot be changed.
> +
> Sysfs entries
> -------------
>
> temp1_input Temperature (RO)
> -temp1_min Minimum temperature (RW)
> -temp1_max Maximum temperature (RW)
> -temp1_crit Critical high temperature (RW)
> +temp1_min Minimum temperature (RO or RW)
> +temp1_max Maximum temperature (RO or RW)
> +temp1_crit Critical high temperature (RO or RW)
>
> -temp1_crit_hyst Critical hysteresis temperature (RW)
> +temp1_crit_hyst Critical hysteresis temperature (RO or RW)
> temp1_max_hyst Maximum hysteresis temperature (RO)
>
> temp1_min_alarm Temperature low alarm
> --- a/drivers/hwmon/jc42.c
> +++ b/drivers/hwmon/jc42.c
> @@ -53,6 +53,8 @@ static const unsigned short normal_i2c[]
>
> /* Configuration register defines */
> #define JC42_CFG_CRIT_ONLY (1 << 2)
> +#define JC42_CFG_TCRIT_LOCK (1 << 6)
> +#define JC42_CFG_EVENT_LOCK (1 << 7)
> #define JC42_CFG_SHUTDOWN (1 << 8)
> #define JC42_CFG_HYST_SHIFT 9
> #define JC42_CFG_HYST_MASK 0x03
> @@ -380,14 +382,14 @@ static ssize_t show_alarm(struct device
>
> static DEVICE_ATTR(temp1_input, S_IRUGO,
> show_temp_input, NULL);
> -static DEVICE_ATTR(temp1_crit, S_IWUSR | S_IRUGO,
> +static DEVICE_ATTR(temp1_crit, S_IRUGO,
> show_temp_crit, set_temp_crit);
> -static DEVICE_ATTR(temp1_min, S_IWUSR | S_IRUGO,
> +static DEVICE_ATTR(temp1_min, S_IRUGO,
> show_temp_min, set_temp_min);
> -static DEVICE_ATTR(temp1_max, S_IWUSR | S_IRUGO,
> +static DEVICE_ATTR(temp1_max, S_IRUGO,
> show_temp_max, set_temp_max);
>
> -static DEVICE_ATTR(temp1_crit_hyst, S_IWUSR | S_IRUGO,
> +static DEVICE_ATTR(temp1_crit_hyst, S_IRUGO,
> show_temp_crit_hyst, set_temp_crit_hyst);
> static DEVICE_ATTR(temp1_max_hyst, S_IRUGO,
> show_temp_max_hyst, NULL);
> @@ -412,8 +414,31 @@ static struct attribute *jc42_attributes
> NULL
> };
>
> +static mode_t jc42_attribute_mode(struct kobject *kobj,
> + struct attribute *attr, int index)
> +{
> + struct device *dev = container_of(kobj, struct device, kobj);
> + struct i2c_client *client = to_i2c_client(dev);
> + struct jc42_data *data = i2c_get_clientdata(client);
> + unsigned int config = data->config;
> + bool readonly;
> +
> + if (attr == &dev_attr_temp1_crit.attr)
> + readonly = config & JC42_CFG_TCRIT_LOCK;
You are assigning a non-bool to a bool. I can see that recent C compilers
do the right thing, but I am not sure if that is always the case.
So I would prefer
readonly = !!(config & JC42_CFG_TCRIT_LOCK));
Same for the assignments below. I can make that change if you are ok with it.
> + else if (attr == &dev_attr_temp1_min.attr ||
> + attr == &dev_attr_temp1_max.attr)
> + readonly = config & JC42_CFG_EVENT_LOCK;
> + else if (attr == &dev_attr_temp1_crit_hyst.attr)
> + readonly = config & (JC42_CFG_EVENT_LOCK | JC42_CFG_TCRIT_LOCK);
> + else
> + readonly = true;
> +
> + return S_IRUGO | (readonly ? 0 : S_IWUSR);
> +}
> +
> static const struct attribute_group jc42_group = {
> .attrs = jc42_attributes,
> + .is_visible = jc42_attribute_mode,
> };
>
> /* Return 0 if detection is successful, -ENODEV otherwise */
>
> _______________________________________________
> lm-sensors mailing list
> [email protected]
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
On Wed, Feb 16, 2011 at 08:01:49AM -0500, Clemens Ladisch wrote:
> In set_temp_crit_hyst(), make the variable 'val' have the correct
> type for strict_strtoul().
>
> Signed-off-by: Clemens Ladisch <[email protected]>
Applied.
Thanks,
Guenter
On Wed, Feb 16, 2011 at 08:02:08AM -0500, Clemens Ladisch wrote:
> The documentation lists standard numbers and chip names in excruciating
> detail, but that's all it does. To help mere mortals in deciding
> whether to enable this driver, mention what this sensor is for and in
> which systems it might be found.
>
> Also add a link to the actual JC 42.4 specification.
>
> Signed-off-by: Clemens Ladisch <[email protected]>
Applied.
Thanks,
Guenter
Guenter Roeck wrote:
> On Wed, Feb 16, 2011 at 08:02:38AM -0500, Clemens Ladisch wrote:
> > + readonly = config & JC42_CFG_TCRIT_LOCK;
>
> You are assigning a non-bool to a bool. I can see that recent C compilers
> do the right thing, but I am not sure if that is always the case.
> So I would prefer
> readonly = !!(config & JC42_CFG_TCRIT_LOCK));
>
> Same for the assignments below. I can make that change if you are ok with it.
I cannot imagine how a compiler could get this wrong even if it tried
to, but if you think so, go ahead. :)
Regards,
Clemens
On Wed, Feb 16, 2011 at 10:11:35AM -0500, Clemens Ladisch wrote:
> Guenter Roeck wrote:
> > On Wed, Feb 16, 2011 at 08:02:38AM -0500, Clemens Ladisch wrote:
> > > + readonly = config & JC42_CFG_TCRIT_LOCK;
> >
> > You are assigning a non-bool to a bool. I can see that recent C compilers
> > do the right thing, but I am not sure if that is always the case.
> > So I would prefer
> > readonly = !!(config & JC42_CFG_TCRIT_LOCK);
> >
> > Same for the assignments below. I can make that change if you are ok with it.
>
> I cannot imagine how a compiler could get this wrong even if it tried
> to, but if you think so, go ahead. :)
>
I don't know. Maybe I am just paranoid. Using !! is how I usually see it done.
Is it really needed ? No idea. Better safe than sorry...
Applied with above changes.
Thanks,
Guenter
Guenter Roeck wrote:
> On Wed, Feb 16, 2011 at 10:11:35AM -0500, Clemens Ladisch wrote:
> > Guenter Roeck wrote:
> > > On Wed, Feb 16, 2011 at 08:02:38AM -0500, Clemens Ladisch wrote:
> > > > + readonly = config & JC42_CFG_TCRIT_LOCK;
> > >
> > > You are assigning a non-bool to a bool. I can see that recent C compilers
> > > do the right thing, but I am not sure if that is always the case.
> > > So I would prefer
> > > readonly = !!(config & JC42_CFG_TCRIT_LOCK);
> > >
> > > Same for the assignments below. I can make that change if you are ok with it.
> >
> > I cannot imagine how a compiler could get this wrong even if it tried
> > to, but if you think so, go ahead. :)
>
> I don't know. Maybe I am just paranoid. Using !! is how I usually see it done.
Usually, !! is used to convert non-zero to the _integer_ 1. With
a compiler that implements bool, this conversion is already implied.
On older compilers, someone might be tempted to do "#define bool int",
but this is not an issue with the compilers required by Linux.
Regards,
Clemens
On Wed, Feb 16, 2011 at 10:38:38AM -0500, Clemens Ladisch wrote:
> Guenter Roeck wrote:
> > On Wed, Feb 16, 2011 at 10:11:35AM -0500, Clemens Ladisch wrote:
> > > Guenter Roeck wrote:
> > > > On Wed, Feb 16, 2011 at 08:02:38AM -0500, Clemens Ladisch wrote:
> > > > > + readonly = config & JC42_CFG_TCRIT_LOCK;
> > > >
> > > > You are assigning a non-bool to a bool. I can see that recent C compilers
> > > > do the right thing, but I am not sure if that is always the case.
> > > > So I would prefer
> > > > readonly = !!(config & JC42_CFG_TCRIT_LOCK);
> > > >
> > > > Same for the assignments below. I can make that change if you are ok with it.
> > >
> > > I cannot imagine how a compiler could get this wrong even if it tried
> > > to, but if you think so, go ahead. :)
> >
> > I don't know. Maybe I am just paranoid. Using !! is how I usually see it done.
>
> Usually, !! is used to convert non-zero to the _integer_ 1. With
> a compiler that implements bool, this conversion is already implied.
> On older compilers, someone might be tempted to do "#define bool int",
> but this is not an issue with the compilers required by Linux.
>
I looked up other drivers, and they do the same, so I'll declare it safe
and apply your patch without modification.
Thanks,
Guenter