Skip to contentSkip to conversation

hwmon: (jc42) Add I2C_CLASS_HWMON to detection class

RFC PATCH In review Alison Schofield 2 participants 4 messages Jul 4, 2016 Hardware monitoring

lore
Share & tools
lore
#0 lore raw

RFC PATCH 1/1 hwmon: (jc42) Add I2C_CLASS_HWMON to detection class

In 2011, commit 774466add7c810fd7e4c8bcf41995b6799608880 changed the detection class of these chips to I2C_CLASS_SPD based on this
premise: "makes more sense because these chips always live on memory modules"

Today these chips have applications beyond memory modules.

Add I2C_CLASS_HWMON as an additional detection class to allow detection by hwmon class i2c adapters.

Alternative is to replace the SPD w HWMON class, but that carries risk for existing usage.

---
 drivers/hwmon/jc42.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/jc42.c +1 -1
index 9887d32..1537ba0 100644
@@ -538,7 +538,7 @@ static const struct i2c_device_id jc42_id[] = {
 MODULE_DEVICE_TABLE(i2c, jc42_id);
 
 static struct i2c_driver jc42_driver = {
-	.class		= I2C_CLASS_SPD,
+	.class		= I2C_CLASS_SPD | I2C_CLASS_HWMON,
 	.driver = {
 		.name	= "jc42",
 		.pm = JC42_DEV_PM_OPS,
Signature · 1 line
2.1.4
maintainer
#1 lore raw
Quoted 7 lines · Alison Schofield

In 2011, commit 774466add7c810fd7e4c8bcf41995b6799608880 changed the detection class of these chips to I2C_CLASS_SPD based on this
premise: "makes more sense because these chips always live on memory modules"

Today these chips have applications beyond memory modules.

Do you have a specific example ?

Quoted 3 lines

Add I2C_CLASS_HWMON as an additional detection class to allow detection by hwmon class i2c adapters.

Practical impact should be limited, though. Most adapters have both I2C_CLASS_HWMON and I2C_CLASS_SPD flags set. Besides the Diolan adapters, which are experimental in nature anyway (and where it actually might make sense to add I2C_CLASS_SPD), do you have an example where a JC-42 compatible chip is used with an adapter which does not have I2C_CLASS_SPD set in its flags ?

Quoted 3 lines

Alternative is to replace the SPD w HWMON class, but that carries risk for existing usage.

Yes, the driver would stop working on adapters which only have I2C_CLASS_SPD set. There are only two of those, but those two presumably _do_ have memory modules connected.

Guenter

Quoted 20 lines
---
  drivers/hwmon/jc42.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/jc42.c +1 -1
index 9887d32..1537ba0 100644
@@ -538,7 +538,7 @@ static const struct i2c_device_id jc42_id[] = {
  MODULE_DEVICE_TABLE(i2c, jc42_id);
 
  static struct i2c_driver jc42_driver = {
-	.class		= I2C_CLASS_SPD,
+	.class		= I2C_CLASS_SPD | I2C_CLASS_HWMON,
  	.driver = {
  		.name	= "jc42",
  		.pm = JC42_DEV_PM_OPS,
#2 lore raw
Quoted 10 lines · Guenter Roeck
Quoted 7 lines · Alison Schofield

In 2011, commit 774466add7c810fd7e4c8bcf41995b6799608880 changed the detection class of these chips to I2C_CLASS_SPD based on this
premise: "makes more sense because these chips always live on memory modules"

Today these chips have applications beyond memory modules.

Do you have a specific example ?

The mcp9808 is popular among hobbyists and makers in projects that monitor everything from their fish pond to their wine cellar. Beyond that I'm just referring to Microchips datasheet and marketing words saying that they target it for a wide range of apps beyond memory devices. I guess the chance of one of them trying to use it, with a Linux driver, and caring about auto detect are pretty slim.

As you've guessed, I changed the Diolan for my purposes. I just found it odd that jc42 was the only driver in hwmon, without I2C_CLASS_HWMON, so I thought it was worth a look and rethink.

So, no, nothing broken, nothing suspected incompatible.

alisons

Quoted 42 lines
Quoted 4 lines

Add I2C_CLASS_HWMON as an additional detection class to allow detection by hwmon class i2c adapters.

Practical impact should be limited, though. Most adapters have both I2C_CLASS_HWMON and I2C_CLASS_SPD flags set. Besides the Diolan adapters, which are experimental in nature anyway (and where it actually might make sense to add I2C_CLASS_SPD), do you have an example where a JC-42 compatible chip is used with an adapter which does not have I2C_CLASS_SPD set in its flags ?

Quoted 3 lines

Alternative is to replace the SPD w HWMON class, but that carries risk for existing usage.

Yes, the driver would stop working on adapters which only have I2C_CLASS_SPD set. There are only two of those, but those two presumably _do_ have memory modules connected.

Guenter

Quoted 20 lines
---
 drivers/hwmon/jc42.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/jc42.c +1 -1
index 9887d32..1537ba0 100644
@@ -538,7 +538,7 @@ static const struct i2c_device_id jc42_id[] = {
 MODULE_DEVICE_TABLE(i2c, jc42_id);
 
 static struct i2c_driver jc42_driver = {
-	.class		= I2C_CLASS_SPD,
+	.class		= I2C_CLASS_SPD | I2C_CLASS_HWMON,
 	.driver = {
 		.name	= "jc42",
 		.pm = JC42_DEV_PM_OPS,
maintainer
#3 lore raw
Quoted 10 lines · Alison Schofield
Quoted 9 lines · Guenter Roeck
Quoted 7 lines · Alison Schofield

In 2011, commit 774466add7c810fd7e4c8bcf41995b6799608880 changed the detection class of these chips to I2C_CLASS_SPD based on this
premise: "makes more sense because these chips always live on memory modules"

Today these chips have applications beyond memory modules.

Quoted 8 lines
Quoted 1 line

Do you have a specific example ?

The mcp9808 is popular among hobbyists and makers in projects that monitor everything from their fish pond to their wine cellar. Beyond that I'm just referring to Microchips datasheet and marketing words saying that they target it for a wide range of apps beyond memory devices. I guess the chance of one of them trying to use it, with a Linux driver, and caring about auto detect are pretty slim.

A better example would be the MCP9085, which is officially JC42.4 compliant but also suggested for use as general purpose temperature sensor in its datasheet.

I'll add your patch to -next.

Thanks,
Guenter

Quoted 56 lines

As you've guessed, I changed the Diolan for my purposes. I just found it odd that jc42 was the only driver in hwmon, without I2C_CLASS_HWMON, so I thought it was worth a look and rethink.

So, no, nothing broken, nothing suspected incompatible.

alisons

Quoted 34 lines
Quoted 4 lines

Add I2C_CLASS_HWMON as an additional detection class to allow detection by hwmon class i2c adapters.

Practical impact should be limited, though. Most adapters have both I2C_CLASS_HWMON and I2C_CLASS_SPD flags set. Besides the Diolan adapters, which are experimental in nature anyway (and where it actually might make sense to add I2C_CLASS_SPD), do you have an example where a JC-42 compatible chip is used with an adapter which does not have I2C_CLASS_SPD set in its flags ?

Quoted 3 lines

Alternative is to replace the SPD w HWMON class, but that carries risk for existing usage.

Yes, the driver would stop working on adapters which only have I2C_CLASS_SPD set. There are only two of those, but those two presumably _do_ have memory modules connected.

Guenter

Quoted 13 lines
---
  drivers/hwmon/jc42.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/jc42.c +0 -0
index 9887d32..1537ba0 100644
@@ -538,7 +538,7 @@ static const struct i2c_device_id jc42_id[] = {
  MODULE_DEVICE_TABLE(i2c, jc42_id);
 
Quoted 8 lines

drivers/hwmon/jc42.c static const struct i2c_device_id jc42_id[] = { · line 544

Quoted 7 lines
drivers/hwmon/jc42.c +1 -1
  static struct i2c_driver jc42_driver = {
-	.class		= I2C_CLASS_SPD,
+	.class		= I2C_CLASS_SPD | I2C_CLASS_HWMON,
  	.driver = {
  		.name	= "jc42",
  		.pm = JC42_DEV_PM_OPS,

--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html