summary refs log tree commit diff
path: root/Documentation/i2c
diff options
context:
space:
mode:
authorJean Delvare <khali@linux-fr.org>2006-08-13 23:46:44 +0200
committerGreg Kroah-Hartman <gregkh@suse.de>2006-09-26 15:38:51 -0700
commit7a8d29cec7a53cf1a29dc5055aa9d1fa0f95830f (patch)
treed7be7f4fe5909b34fb4ca1587bc6a981c7c0b67b /Documentation/i2c
parent6c805d2ce9d910ea915d7dbe4aed0a91f138be07 (diff)
downloadlinux-7a8d29cec7a53cf1a29dc5055aa9d1fa0f95830f.tar.gz
i2c-stub: Chip address as a module parameter
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@linux-fr.org>
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Diffstat (limited to 'Documentation/i2c')
-rw-r--r--Documentation/i2c/i2c-stub15
1 files changed, 13 insertions, 2 deletions
diff --git a/Documentation/i2c/i2c-stub b/Documentation/i2c/i2c-stub
index d6dcb138abf5..9cc081e69764 100644
--- a/Documentation/i2c/i2c-stub
+++ b/Documentation/i2c/i2c-stub
@@ -6,9 +6,12 @@ This module is a very simple fake I2C/SMBus driver.  It implements four
 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 @@ The typical use-case is like this:
 	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 @@ If the hardware for your driver has banked registers (e.g. Winbond sensors
 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.