diff options
| author | Jean Delvare <khali@linux-fr.org> | 2006-08-13 17:46:44 -0400 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@suse.de> | 2006-09-26 18:38:51 -0400 |
| commit | 7a8d29cec7a53cf1a29dc5055aa9d1fa0f95830f (patch) | |
| tree | d7be7f4fe5909b34fb4ca1587bc6a981c7c0b67b /Documentation/i2c/i2c-stub | |
| parent | 6c805d2ce9d910ea915d7dbe4aed0a91f138be07 (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/i2c/i2c-stub')
| -rw-r--r-- | Documentation/i2c/i2c-stub | 15 |
1 files changed, 13 insertions, 2 deletions
diff --git a/Documentation/i2c/i2c-stub b/Documentation/i2c/i2c-stub index d6dcb138abf..9cc081e6976 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 | |||
| 6 | types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and | 6 | types 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 | ||
| 9 | You need to provide a chip address as a module parameter when loading | ||
| 10 | this driver, which will then only react to SMBus commands to this address. | ||
| 11 | |||
| 9 | No hardware is needed nor associated with this module. It will accept write | 12 | No hardware is needed nor associated with this module. It will accept write |
| 10 | quick commands to all addresses; it will respond to the other commands (also | 13 | quick commands to one address; it will respond to the other commands (also |
| 11 | to all addresses) by reading from or writing to an array in memory. It will | 14 | to one address) by reading from or writing to an array in memory. It will |
| 12 | also spam the kernel logs for every command it handles. | 15 | also spam the kernel logs for every command it handles. |
| 13 | 16 | ||
| 14 | A pointer register with auto-increment is implemented for all byte | 17 | A 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 | ||
| 27 | PARAMETERS: | ||
| 28 | |||
| 29 | int chip_addr: | ||
| 30 | The SMBus address to emulate a chip at. | ||
| 31 | |||
| 24 | CAVEATS: | 32 | CAVEATS: |
| 25 | 33 | ||
| 26 | There are independent arrays for byte/data and word/data commands. Depending | 34 | 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 | |||
| 33 | chips) this module will not work well - although it could be extended to | 41 | chips) this module will not work well - although it could be extended to |
| 34 | support that pretty easily. | 42 | support that pretty easily. |
| 35 | 43 | ||
| 44 | Only one chip address is supported - although this module could be | ||
| 45 | extended to support more. | ||
| 46 | |||
| 36 | If you spam it hard enough, printk can be lossy. This module really wants | 47 | If you spam it hard enough, printk can be lossy. This module really wants |
| 37 | something like relayfs. | 48 | something like relayfs. |
| 38 | 49 | ||
