5 files changed, 82 insertions, 10 deletions
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index fde4420e3f7..3bd95836015 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -17,9 +17,8 @@ Supported adapters:
    Datasheets: Publicly available at the Intel website
 
 Authors: 
-	Frodo Looijaard <frodol@dds.nl>, 
-	Philip Edelbrock <phil@netroedge.com>, 
 	Mark Studebaker <mdsxyz123@yahoo.com>
+	Jean Delvare <khali@linux-fr.org>
 
 
 Module Parameters
@@ -62,7 +61,7 @@ Not supported.
 I2C Block Read Support
 ----------------------
 
-Not supported at the moment.
+I2C block read is supported on the 82801EB (ICH5) and later chips.
 
 
 SMBus 2.0 Support
diff --git a/Documentation/i2c/busses/i2c-viapro b/Documentation/i2c/busses/i2c-viapro
index 06b4be3ef6d..1405fb69984 100644
--- a/Documentation/i2c/busses/i2c-viapro
+++ b/Documentation/i2c/busses/i2c-viapro
@@ -10,7 +10,7 @@ Supported adapters:
   * VIA Technologies, Inc. VT8231, VT8233, VT8233A
     Datasheet: available on request from VIA
 
-  * VIA Technologies, Inc. VT8235, VT8237R, VT8237A, VT8251
+  * VIA Technologies, Inc. VT8235, VT8237R, VT8237A, VT8237S, VT8251
     Datasheet: available on request and under NDA from VIA
 
   * VIA Technologies, Inc. CX700
@@ -46,6 +46,7 @@ Your lspci -n listing must show one of these :
  device 1106:3177   (VT8235)
  device 1106:3227   (VT8237R)
  device 1106:3337   (VT8237A)
+ device 1106:3372   (VT8237S)
  device 1106:3287   (VT8251)
  device 1106:8324   (CX700)
 
diff --git a/Documentation/i2c/chips/pcf8575 b/Documentation/i2c/chips/pcf8575
new file mode 100644
index 00000000000..25f5698a61c
--- /dev/null
+++ b/Documentation/i2c/chips/pcf8575
@@ -0,0 +1,72 @@
+About the PCF8575 chip and the pcf8575 kernel driver
+====================================================
+
+The PCF8575 chip is produced by the following manufacturers:
+
+  * Philips NXP
+    http://www.nxp.com/#/pip/cb=[type=product,path=50807/41735/41850,final=PCF8575_3]|pip=[pip=PCF8575_3][0]
+
+  * Texas Instruments
+    http://focus.ti.com/docs/prod/folders/print/pcf8575.html
+
+
+Some vendors sell small PCB's with the PCF8575 mounted on it. You can connect
+such a board to a Linux host via e.g. an USB to I2C interface. Examples of
+PCB boards with a PCF8575:
+
+  * SFE Breakout Board for PCF8575 I2C Expander by RobotShop
+    http://www.robotshop.ca/home/products/robot-parts/electronics/adapters-converters/sfe-pcf8575-i2c-expander-board.html
+
+  * Breakout Board for PCF8575 I2C Expander by Spark Fun Electronics
+    http://www.sparkfun.com/commerce/product_info.php?products_id=8130
+
+
+Description
+-----------
+The PCF8575 chip is a 16-bit I/O expander for the I2C bus. Up to eight of
+these chips can be connected to the same I2C bus. You can find this
+chip on some custom designed hardware, but you won't find it on PC
+motherboards.
+
+The PCF8575 chip consists of a 16-bit quasi-bidirectional port and an I2C-bus
+interface. Each of the sixteen I/O's can be independently used as an input or
+an output. To set up an I/O pin as an input, you have to write a 1 to the
+corresponding output.
+
+For more information please see the datasheet.
+
+
+Detection
+---------
+
+There is no method known to detect whether a chip on a given I2C address is
+a PCF8575 or whether it is any other I2C device. So there are two alternatives
+to let the driver find the installed PCF8575 devices:
+- Load this driver after any other I2C driver for I2C devices with addresses
+  in the range 0x20 .. 0x27.
+- Pass the I2C bus and address of the installed PCF8575 devices explicitly to
+  the driver at load time via the probe=... or force=... parameters.
+
+/sys interface
+--------------
+
+For each address on which a PCF8575 chip was found or forced the following
+files will be created under /sys:
+* /sys/bus/i2c/devices/<bus>-<address>/read
+* /sys/bus/i2c/devices/<bus>-<address>/write
+where bus is the I2C bus number (0, 1, ...) and address is the four-digit
+hexadecimal representation of the 7-bit I2C address of the PCF8575
+(0020 .. 0027).
+
+The read file is read-only. Reading it will trigger an I2C read and will hence
+report the current input state for the pins configured as inputs, and the
+current output value for the pins configured as outputs.
+
+The write file is read-write. Writing a value to it will configure all pins
+as output for which the corresponding bit is zero. Reading the write file will
+return the value last written, or -EAGAIN if no value has yet been written to
+the write file.
+
+On module initialization the configuration of the chip is not changed -- the
+chip is left in the state it was already configured in through either power-up
+or through previous I2C write actions.
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.
 
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index 2c170032bf3..bfb0a552081 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -267,9 +267,9 @@ insmod parameter of the form force_<kind>.
 Fortunately, as a module writer, you just have to define the `normal_i2c' 
 parameter. The complete declaration could look like this:
 
-  /* Scan 0x37, and 0x48 to 0x4f */
-  static unsigned short normal_i2c[] = { 0x37, 0x48, 0x49, 0x4a, 0x4b, 0x4c,
-                                         0x4d, 0x4e, 0x4f, I2C_CLIENT_END };
+  /* Scan 0x4c to 0x4f */
+  static const unsigned short normal_i2c[] = { 0x4c, 0x4d, 0x4e, 0x4f,
+                                               I2C_CLIENT_END };
 
   /* Magic definition of all other variables and things */
   I2C_CLIENT_INSMOD;