Skip to contentSkip to conversation

I2C/SMBus stub for driver testing

PATCH New Mark M. Hoffman 2 participants 4 messages May 19, 2005

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 I2C/SMBus stub for driver testing

Hi Greg:

Quoted 2 lines · Greg KH
Quoted 2 lines
Quoted 2 lines

Why not? It looks useful to me. Care to send me a patch adding this to the main kernel tree?

Quoted 1 line · Mark M. Hoffman

Later today, sure.

Well here it is, one day later because I really didn't want to do this with printk. I spent some time looking around and relayfs seems like a good fit. Do you think relayfs will ever get merged? Meanwhile...

* * * * *

This patch, applied to 2.6.9-rc1, adds an I2C/SMBus test stub that is useful for developing sensors drivers.

Documentation/i2c/i2c-stub +33 -0
diff -Nru linux-2.6.9-rc1/Documentation/i2c/i2c-stub linux-2.6.9-rc1-mmh/Documentation/i2c/i2c-stub
@@ -0,0 +1,33 @@
+MODULE: i2c-stub
+
+DESCRIPTION:
+
+This module is a very simple fake I2C/SMBus driver.  It implements three
+types of SMBus commands: write quick, (r/w) byte data, and (r/w) word data.
+
+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
+also spam the kernel logs for every command it handles.
+
+The typical use-case is like this:
+	1. load this module
+	2. use i2cset (from lm_sensors project) to pre-load some data
+	3. load the target sensors chip driver module
+	4. observe its behavior in the kernel log
+
+CAVEATS:
+
+There are independent arrays for byte/data and word/data commands.  Depending
+on if/how a target driver mixes them, you'll need to be careful.
+
+If your target driver polls some byte or word waiting for it to change, the
+stub could lock it up.  Use i2cset to unlock it.
+
+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.
+
+If you spam it hard enough, printk can be lossy.  This module really wants
+something like relayfs.
+
drivers/i2c/busses/i2c-stub.c +125 -0

125 lines not on this page · raw message

drivers/i2c/busses/Kconfig +13 -0
diff -Nru linux-2.6.9-rc1/drivers/i2c/busses/Kconfig linux-2.6.9-rc1-mmh/drivers/i2c/busses/Kconfig
@@ -376,6 +376,19 @@
 	  This driver can also be built as a module.  If so, the module
 	  will be called i2c-sis96x.
 
+config I2C_STUB
+	tristate "I2C/SMBus Test Stub"
+	depends on I2C && EXPERIMENTAL && 'm'
+	default 'n'
+	help
+	  This module may be useful to developers of SMBus client drivers,
+	  especially for certain kinds of sensor chips.
+
+	  If you do build this module, be sure to read the notes and warnings
+	  in Documentation/i2c/i2c-stub.
+
+	  If you don't know what to do here, definitely say N.
+
 config I2C_VIA
 	tristate "VIA 82C586B"
 	depends on I2C && PCI && EXPERIMENTAL
drivers/i2c/busses/Makefile +1 -0
diff -Nru linux-2.6.9-rc1/drivers/i2c/busses/Makefile linux-2.6.9-rc1-mmh/drivers/i2c/busses/Makefile
@@ -30,6 +30,7 @@
 obj-$(CONFIG_I2C_SIS5595)	+= i2c-sis5595.o
 obj-$(CONFIG_I2C_SIS630)	+= i2c-sis630.o
 obj-$(CONFIG_I2C_SIS96X)	+= i2c-sis96x.o
+obj-$(CONFIG_I2C_STUB)		+= i2c-stub.o
 obj-$(CONFIG_I2C_VIA)		+= i2c-via.o
 obj-$(CONFIG_I2C_VIAPRO)	+= i2c-viapro.o
 obj-$(CONFIG_I2C_VOODOO3)	+= i2c-voodoo3.o
Signature · 2 lines
Mark M. Hoffman
[email protected]
Applied
#1 lore raw

PATCH 1/1 I2C/SMBus stub for driver testing

Quoted 6 lines · Mark M. Hoffman

Hi Greg:

Quoted 2 lines · Greg KH
Quoted 2 lines
Quoted 2 lines

Why not? It looks useful to me. Care to send me a patch adding this to the main kernel tree?

Quoted 6 lines
Quoted 1 line · Mark M. Hoffman

Later today, sure.

Well here it is, one day later because I really didn't want to do this with printk. I spent some time looking around and relayfs seems like a good fit. Do you think relayfs will ever get merged? Meanwhile...

No, I don't think relayfs will ever get merged, although it is a nice solution searching for a problem :)

Applied, thanks.

greg k-h

#2 lore raw

PATCH 1/1 I2C/SMBus stub for driver testing

In reply to Mark M. Hoffman

Hi Greg:

Quoted 4 lines · Mark M. Hoffman
Quoted 3 lines

Well here it is, one day later because I really didn't want to do this with printk. I spent some time looking around and relayfs seems like a good fit. Do you think relayfs will ever get merged? Meanwhile...

Quoted 2 lines · Greg KH

No, I don't think relayfs will ever get merged, although it is a nice solution searching for a problem :)

I.e. I should use netlink for this? But isn't netlink unreliable, at least in theory? Or do you have some other mechanism in mind? I would appreciate some advice...

Regards,

Signature · 2 lines
Mark M. Hoffman
[email protected]
#3 lore raw

PATCH 1/1 I2C/SMBus stub for driver testing

In reply to Mark M. Hoffman
Quoted 7 lines · Mark M. Hoffman

Hi Greg:

Quoted 4 lines · Mark M. Hoffman
Quoted 3 lines

Well here it is, one day later because I really didn't want to do this with printk. I spent some time looking around and relayfs seems like a good fit. Do you think relayfs will ever get merged? Meanwhile...

Quoted 7 lines
Quoted 2 lines · Greg KH

No, I don't think relayfs will ever get merged, although it is a nice solution searching for a problem :)

I.e. I should use netlink for this? But isn't netlink unreliable, at least in theory? Or do you have some other mechanism in mind? I would appreciate some advice...

Nah, I don't think netlink would work all too well either.

I need to do something like this for usb, and I was starting to look into a plain socket-like interface, much like the ethernet tap tools use. But I haven't gotten very far yet, sorry.

greg k-h