[PATCH 0/3] hwmon: some jc42 changes

[PATCH 0/3] hwmon: some jc42 changes

[Clemens Ladisch]

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(-)

[PATCH 1/3] hwmon: (jc42) fix type mismatch

[Clemens Ladisch]

In set_temp_crit_hyst(), make the variable 'val' have the correct
type for strict_strtoul().

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
---
 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;

Re: [lm-sensors] [PATCH 1/3] hwmon: (jc42) fix type mismatch

[Guenter Roeck]

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 <clemens@ladisch.de>

Applied.

Thanks,
Guenter

[PATCH 2/3] hwmon: (jc42) more helpful documentation

[Clemens Ladisch]

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 <clemens@ladisch.de>
---
 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 <guenter.roeck@ericsson.com>
@@ -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.
 

Re: [lm-sensors] [PATCH 2/3] hwmon: (jc42) more helpful documentation

[Guenter Roeck]

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 <clemens@ladisch.de>

Applied.

Thanks,
Guenter

[PATCH 3/3] hwmon: (jc42) do not allow writing to locked registers

[Clemens Ladisch]

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 <clemens@ladisch.de>
---
 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 */

Re: [lm-sensors] [PATCH 3/3] hwmon: (jc42) do not allow writing to locked registers

[Guenter Roeck]

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 <clemens@ladisch.de>
> ---
>  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
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH 3/3] hwmon: (jc42) do not allow writing to locked registers

[Clemens Ladisch]

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

Re: [lm-sensors] [PATCH 3/3] hwmon: (jc42) do not allow writing to locked registers

[Guenter Roeck]

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

Re: [lm-sensors] [PATCH 3/3] hwmon: (jc42) do not allow writing to locked registers

[Clemens Ladisch]

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

Re: [lm-sensors] [PATCH 3/3] hwmon: (jc42) do not allow writing to locked registers

[Guenter Roeck]

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