I2C: lm87 driver ported to Linux 2.6

Hi Greg,

This is my port of the lm87 driver to Linux 2.6. It is based on the preliminary work of Jeff Oliver. I then significantly improved the code, added functionality, tested the whole thing on a real motherboard, fixed a couple remaining bugs, and here we are.

I'll port a number of improvements and fixes back to the 2.4 version of the driver after lm_sensors 2.8.8 is released (i.e. soon).

Please apply,
thanks.

@@ -169,6 +169,17 @@
 	  This driver can also be built as a module.  If so, the module
 	  will be called lm85.
 
+config SENSORS_LM87
+	tristate "National Semiconductor LM87"
+	depends on I2C && EXPERIMENTAL
+	select I2C_SENSOR
+	help
+	  If you say yes here you get support for National Semiconductor LM87
+	  sensor chips.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called lm87.
+
 config SENSORS_LM90
 	tristate "National Semiconductor LM90 and compatibles"
 	depends on I2C

@@ -21,6 +21,7 @@
 obj-$(CONFIG_SENSORS_LM80)	+= lm80.o
 obj-$(CONFIG_SENSORS_LM83)	+= lm83.o
 obj-$(CONFIG_SENSORS_LM85)	+= lm85.o
+obj-$(CONFIG_SENSORS_LM87)	+= lm87.o
 obj-$(CONFIG_SENSORS_LM90)	+= lm90.o
 obj-$(CONFIG_SENSORS_MAX1619)	+= max1619.o
 obj-$(CONFIG_SENSORS_PCF8574)	+= pcf8574.o

Jean Delvare
http://khali.linux-fr.org/

Sure, send it on.

Let's see what the patch looks like.

thanks,

greg k-h

Applied, thanks.

greg k-h

Jean,

Do you guys want drivers for other i2c devices? I have a driver that I was working on for Phillips PCA9555 i2c to gpio device. So you think it would be something people would be interested in?

Also, I dont think that the version of the i2c eeprom driver had the code to allow writing to the eeprom. I added to code for writing to the driver for my purposes. Would anyone like that code?

Jeff Oliver
[email protected]

What kind of driver is it? The PCA9555 could possibly be used for SMBus multiplexing, which we are precisely discussing these days. Or maybe your driver simply offers a user-space interface to the GPIO pins?

The lack of write support is mainly a choice made a long time ago. Messing with a memory module EEPROM can make it useless, and we didn't want people to do that. What do you need this for? At any rate, I think it would be safer if the write support wasn't usable by default. It could be a module parameter, or an additional file in sysfs (e.g. readonly, default to 1). Yet another approach would be to to try to identify the kind of eeprom we are dealing with, and to disallow write access in any case if the EEPROM is a memory module one.

Anyway, as Greg said, a loot at your code will still be interesting; we'll see where we want to go then.

Thanks,
Jean