aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorJean Delvare <khali@linux-fr.org>2006-08-13 17:46:44 -0400
committerGreg Kroah-Hartman <gregkh@suse.de>2006-09-26 18:38:51 -0400
commit7a8d29cec7a53cf1a29dc5055aa9d1fa0f95830f (patch)
treed7be7f4fe5909b34fb4ca1587bc6a981c7c0b67b /Documentation
parent6c805d2ce9d910ea915d7dbe4aed0a91f138be07 (diff)
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')
-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
6types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and 6types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and
7(r/w) word data. 7(r/w) word data.
8 8
9You need to provide a chip address as a module parameter when loading
10this driver, which will then only react to SMBus commands to this address.
11
9No hardware is needed nor associated with this module. It will accept write 12No hardware is needed nor associated with this module. It will accept write
10quick commands to all addresses; it will respond to the other commands (also 13quick commands to one address; it will respond to the other commands (also
11to all addresses) by reading from or writing to an array in memory. It will 14to one address) by reading from or writing to an array in memory. It will
12also spam the kernel logs for every command it handles. 15also spam the kernel logs for every command it handles.
13 16
14A pointer register with auto-increment is implemented for all byte 17A pointer register with auto-increment is implemented for all byte
@@ -21,6 +24,11 @@ The typical use-case is like this:
21 3. load the target sensors chip driver module 24 3. load the target sensors chip driver module
22 4. observe its behavior in the kernel log 25 4. observe its behavior in the kernel log
23 26
27PARAMETERS:
28
29int chip_addr:
30 The SMBus address to emulate a chip at.
31
24CAVEATS: 32CAVEATS:
25 33
26There are independent arrays for byte/data and word/data commands. Depending 34There 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
33chips) this module will not work well - although it could be extended to 41chips) this module will not work well - although it could be extended to
34support that pretty easily. 42support that pretty easily.
35 43
44Only one chip address is supported - although this module could be
45extended to support more.
46
36If you spam it hard enough, printk can be lossy. This module really wants 47If you spam it hard enough, printk can be lossy. This module really wants
37something like relayfs. 48something like relayfs.
38 49