X-Git-Url: http://pilppa.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=Documentation%2Fi2c%2Fi2c-stub;h=0d8be1c20c16b6bf96a95f42e7855d635e3a32b8;hb=0aedadf91a70a11c4a3e7c7d99b21e5528af8d5d;hp=89e69ad3436c6f62443335762797442605b1af1d;hpb=f2e1d89f9b349b3cd914b7c6ec6368632f4ad048;p=linux-2.6-omap-h63xx.git

diff --git a/Documentation/i2c/i2c-stub b/Documentation/i2c/i2c-stub
index 89e69ad3436..0d8be1c20c1 100644
--- a/Documentation/i2c/i2c-stub
+++ b/Documentation/i2c/i2c-stub
@@ -25,6 +25,9 @@ The typical use-case is like this:
 	3. load the target sensors chip driver module
 	4. observe its behavior in the kernel log
 
+There's a script named i2c-stub-from-dump in the i2c-tools package which
+can load register values automatically from a chip dump.
+
 PARAMETERS:
 
 int chip_addr[10]:
@@ -32,9 +35,6 @@ int chip_addr[10]:
 
 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.