1MODULE: i2c-stub
2 3DESCRIPTION:
4 5This module is a very simple fake I2C/SMBus driver. It implements five
6types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w)
7word data, and (r/w) I2C block data.
8 9You need to provide chip addresses as a module parameter when loading this
10driver, which will then only react to SMBus commands to these addresses.
11 12No hardware is needed nor associated with this module. It will accept write
13quick commands to the specified addresses; it will respond to the other
14commands (also to the specified addresses) by reading from or writing to
15arrays in memory. It will also spam the kernel logs for every command it
16handles.
17 18A pointer register with auto-increment is implemented for all byte
19operations. This allows for continuous byte reads like those supported by
20EEPROMs, among others.
21 22The typical use-case is like this:
23 1. load this module
24 2. use i2cset (from the i2c-tools project) to pre-load some data
25 3. load the target chip driver module
26 4. observe its behavior in the kernel log
27 28There's a script named i2c-stub-from-dump in the i2c-tools package which
29can load register values automatically from a chip dump.
30 31PARAMETERS:
32 33int chip_addr[10]:
34 The SMBus addresses to emulate chips at.
35 36unsigned long functionality:
37 Functionality override, to disable some commands. See I2C_FUNC_*
38 constants in <linux/i2c.h> for the suitable values. For example,
39 value 0x1f0000 would only enable the quick, byte and byte data
40 commands.
41 42CAVEATS:
43 44If your target driver polls some byte or word waiting for it to change, the
45stub could lock it up. Use i2cset to unlock it.
46 47If the hardware for your driver has banked registers (e.g. Winbond sensors
48chips) this module will not work well - although it could be extended to
49support that pretty easily.
50 51If you spam it hard enough, printk can be lossy. This module really wants
52something like relayfs.
53 54