7 files changed, 89 insertions, 51 deletions

diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index fde4420e3f75..3bd958360159 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 06b4be3ef6d8..1405fb69984c 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/pca9539 b/Documentation/i2c/chips/pca9539
index c4fce6a13537..1d81c530c4a5 100644
--- a/Documentation/i2c/chips/pca9539
+++ b/Documentation/i2c/chips/pca9539
@@ -1,6 +1,9 @@
 Kernel driver pca9539
 =====================
 
+NOTE: this driver is deprecated and will be dropped soon, use
+drivers/gpio/pca9539.c instead.
+
 Supported chips:
   * Philips PCA9539
     Prefix: 'pca9539'
diff --git a/Documentation/i2c/chips/pcf8575 b/Documentation/i2c/chips/pcf8575
new file mode 100644
index 000000000000..25f5698a61cf
--- /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 89e69ad3436c..0d8be1c20c16 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/summary b/Documentation/i2c/summary
index 003c7319b8c7..13ab076dcd92 100644
--- a/Documentation/i2c/summary
+++ b/Documentation/i2c/summary
@@ -1,5 +1,3 @@
-This is an explanation of what i2c is, and what is supported in this package.
-
 I2C and SMBus
 =============
 
@@ -33,52 +31,17 @@ When we talk about I2C, we use the following terms:
             Client
 
 An Algorithm driver contains general code that can be used for a whole class
-of I2C adapters. Each specific adapter driver depends on one algorithm
-driver.
+of I2C adapters. Each specific adapter driver either depends on one algorithm
+driver, or includes its own implementation.
 
 A Driver driver (yes, this sounds ridiculous, sorry) contains the general
 code to access some type of device. Each detected device gets its own
 data in the Client structure. Usually, Driver and Client are more closely
 integrated than Algorithm and Adapter.
 
-For a given configuration, you will need a driver for your I2C bus (usually
-a separate Adapter and Algorithm driver), and drivers for your I2C devices
-(usually one driver for each device). There are no I2C device drivers
-in this package. See the lm_sensors project http://www.lm-sensors.nu
-for device drivers.
+For a given configuration, you will need a driver for your I2C bus, and
+drivers for your I2C devices (usually one driver for each device).
 
 At this time, Linux only operates I2C (or SMBus) in master mode; you can't
 use these APIs to make a Linux system behave as a slave/device, either to
 speak a custom protocol or to emulate some other device.
-
-
-Included Bus Drivers
-====================
-Note that only stable drivers are patched into the kernel by 'mkpatch'.
-
-
-Base modules
-------------
-
-i2c-core: The basic I2C code, including the /proc/bus/i2c* interface
-i2c-dev:  The /dev/i2c-* interface
-i2c-proc: The /proc/sys/dev/sensors interface for device (client) drivers
-
-Algorithm drivers
------------------
-
-i2c-algo-bit:    A bit-banging algorithm
-i2c-algo-pcf:    A PCF 8584 style algorithm
-i2c-algo-ibm_ocp: An algorithm for the I2C device in IBM 4xx processors (NOT BUILT BY DEFAULT)
-
-Adapter drivers
----------------
-
-i2c-elektor:     Elektor ISA card (uses i2c-algo-pcf)
-i2c-elv:         ELV parallel port adapter (uses i2c-algo-bit)
-i2c-pcf-epp:     PCF8584 on a EPP parallel port (uses i2c-algo-pcf) (NOT mkpatched)
-i2c-philips-par: Philips style parallel port adapter (uses i2c-algo-bit)
-i2c-adap-ibm_ocp: IBM 4xx processor I2C device (uses i2c-algo-ibm_ocp) (NOT BUILT BY DEFAULT)
-i2c-pport:       Primitive parallel port adapter (uses i2c-algo-bit)
-i2c-velleman:    Velleman K8000 parallel port adapter (uses i2c-algo-bit)
-
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index 2c170032bf37..bfb0a5520817 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;