[i2c] [PATCH RFC] i2c-stub: Chip address as a module parameter

[Jean Delvare]

Hi Mark,

Running sensors-detect when i2c-stub is loaded triggers many false
positives. Sometimes a desperate user loads i2c drivers at random in the
hope it will help him/her get sensors to work on his/her system. The
subsequent sensors-detect run is very confusing [1].

[1] http://lists.lm-sensors.org/pipermail/lm-sensors/2006-August/017145.html

One way to solve the problem would be to refine all the detection
functions in sensors-detect. However, this ain't trivial.

An easier way would be to prevent i2c-stub from being loaded "at
random". Here comes a patch, very similar in spirit to what you proposed
for i2c-parport some times ago [2], which adds a mandatory parameter to
i2c-stub. This parameter is the address at which i2c-stub will emulate
a chip. This differs from the original behavior where i2c-stub would
answer to all addresses.

[2] http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e97b81ddbb8b8c72b85330ac4a454a4513dcba8a

What do you think?

i2c-stub: Chip address as a module parameter

Add a mandatory chip_addr parameter to i2c-stub. This parameter
defines to which chip address the driver will respond, instead of
reponding to all addresses as before. The idea is to prevent the
users from loading i2c-stub at random and being then confused by
the results of sensors-detect or other user-space tools.

Signed-off-by: Jean Delvare <khali at linux-fr.org>
---
 Documentation/i2c/i2c-stub    |   15 +++++++++++++--
 drivers/i2c/busses/i2c-stub.c |   19 ++++++++++++++++++-
 2 files changed, 31 insertions(+), 3 deletions(-)

--- linux-2.6.18-rc4.orig/Documentation/i2c/i2c-stub	2006-01-03 04:21:10.000000000 +0100
+++ linux-2.6.18-rc4/Documentation/i2c/i2c-stub	2006-08-12 11:36:00.000000000 +0200
@@ -6,9 +6,12 @@
 types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and
 (r/w) word data.
 
+You need to provide a chip address as a module parameter when loading
+this driver, which will then only react to SMBus commands to this address.
+
 No hardware is needed nor associated with this module.  It will accept write
-quick commands to all addresses; it will respond to the other commands (also
-to all addresses) by reading from or writing to an array in memory.  It will
+quick commands to one address; it will respond to the other commands (also
+to one address) by reading from or writing to an array in memory.  It will
 also spam the kernel logs for every command it handles.
 
 A pointer register with auto-increment is implemented for all byte
@@ -21,6 +24,11 @@
 	3. load the target sensors chip driver module
 	4. observe its behavior in the kernel log
 
+PARAMETERS:
+
+int chip_addr:
+	The SMBus address to emulate a chip at.
+
 CAVEATS:
 
 There are independent arrays for byte/data and word/data commands.  Depending
@@ -33,6 +41,9 @@
 chips) this module will not work well - although it could be extended to
 support that pretty easily.
 
+Only one chip address is supported - although this module could be
+extended to support more.
+
 If you spam it hard enough, printk can be lossy.  This module really wants
 something like relayfs.
 
--- linux-2.6.18-rc4.orig/drivers/i2c/busses/i2c-stub.c	2006-01-03 04:21:10.000000000 +0100
+++ linux-2.6.18-rc4/drivers/i2c/busses/i2c-stub.c	2006-08-12 14:28:10.000000000 +0200
@@ -27,6 +27,10 @@
 #include <linux/errno.h>
 #include <linux/i2c.h>
 
+static unsigned short chip_addr;
+module_param(chip_addr, ushort, S_IRUGO);
+MODULE_PARM_DESC(chip_addr, "Chip address (between 0x03 and 0x77)\n");
+
 static u8  stub_pointer;
 static u8  stub_bytes[256];
 static u16 stub_words[256];
@@ -37,6 +41,9 @@
 {
 	s32 ret;
 
+	if (addr != chip_addr)
+		return -ENODEV;
+
 	switch (size) {
 
 	case I2C_SMBUS_QUICK:
@@ -122,7 +129,17 @@
 
 static int __init i2c_stub_init(void)
 {
-	printk(KERN_INFO "i2c-stub loaded\n");
+	if (!chip_addr) {
+		printk(KERN_ERR "i2c-stub: Please specify a chip address\n");
+		return -ENODEV;
+	}
+	if (chip_addr < 0x03 || chip_addr > 0x77) {
+		printk(KERN_ERR "i2c-stub: Invalid chip address 0x%02x\n",
+		       chip_addr);
+		return -EINVAL;
+	}
+
+	printk(KERN_INFO "i2c-stub: Virtual chip at 0x%02x\n", chip_addr);
 	return i2c_add_adapter(&stub_adapter);
 }
 

-- 
Jean Delvare