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>
types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and
(r/w) word data.
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
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
also spam the kernel logs for every command it handles.
A pointer register with auto-increment is implemented for all byte
3. load the target sensors chip driver module
4. observe its behavior in the kernel log
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
CAVEATS:
There are independent arrays for byte/data and word/data commands. Depending
chips) this module will not work well - although it could be extended to
support that pretty easily.
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.
If you spam it hard enough, printk can be lossy. This module really wants
something like relayfs.
#include <linux/errno.h>
#include <linux/i2c.h>
#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];
static u8 stub_pointer;
static u8 stub_bytes[256];
static u16 stub_words[256];
+ if (addr != chip_addr)
+ return -ENODEV;
+
switch (size) {
case I2C_SMBUS_QUICK:
switch (size) {
case I2C_SMBUS_QUICK:
static int __init i2c_stub_init(void)
{
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);
}
return i2c_add_adapter(&stub_adapter);
}