Merge nuts.davemloft.net:/disk1/BK/network-2.6

into nuts.davemloft.net:/disk1/BK/net-2.6

16 files changed, 628 insertions, 684 deletions

diff --git a/Documentation/Changes b/Documentation/Changes
index 22ec89259ee998..c056d65b1a30df 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -223,6 +223,11 @@ If you are running v0.1.17 or earlier, you should upgrade to
 version v0.99.0 or higher. Running old versions may cause problems
 with programs using shared memory.
 
+udev
+----
+udev is a userspace application for populating /dev dynamically with
+only entries for devices actually present. udev replaces devfs.
+
 Networking
 ==========
 
@@ -368,6 +373,10 @@ Powertweak
 ----------
 o  <http://powertweak.sourceforge.net/>
 
+udev
+----
+o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html>
+
 Networking
 **********
 
@@ -399,4 +408,3 @@ NFS-Utils
 ---------
 o  <http://nfs.sourceforge.net/>
 
-
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index ef66fdda129f2a..97a30ce957ad86 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -105,6 +105,15 @@ KAO -->
      </sect1>
   </chapter>
 
+  <chapter id="debugfs">
+     <title>The debugfs filesystem</title>
+ 
+     <sect1><title>debugfs interface</title>
+!Efs/debugfs/inode.c
+!Efs/debugfs/file.c
+     </sect1>
+  </chapter>
+
   <chapter id="vfs">
      <title>The Linux VFS</title>
      <sect1><title>The Directory Cache</title>
diff --git a/Documentation/aoe/aoe.txt b/Documentation/aoe/aoe.txt
new file mode 100644
index 00000000000000..ce84de72bf5f4e
--- /dev/null
+++ b/Documentation/aoe/aoe.txt
@@ -0,0 +1,75 @@
+The EtherDrive (R) HOWTO for users of 2.6 kernels is found at ...
+
+  http://www.coraid.com/support/linux/EtherDrive-2.6-HOWTO.html
+
+  It has many tips and hints!
+
+CREATING DEVICE NODES
+
+  Users of udev should find device nodes created automatically.  Two
+  scripts are provided in Documentation/aoe as examples of static
+  device node creation for using the aoe driver.
+
+    rm -rf /dev/etherd
+    sh Documentation/aoe/mkdevs.sh /dev/etherd
+
+  ... or to make just one shelf's worth of block device nodes ...
+
+    sh Documentation/aoe/mkshelf.sh /dev/etherd 0
+
+  There is also an autoload script that shows how to edit
+  /etc/modprobe.conf to ensure that the aoe module is loaded when
+  necessary.
+
+USING DEVICE NODES
+
+  "cat /dev/etherd/err" blocks, waiting for error diagnostic output,
+  like any retransmitted packets.
+
+  "echo eth2 eth4 > /dev/etherd/interfaces" tells the aoe driver to
+  limit ATA over Ethernet traffic to eth2 and eth4.  AoE traffic from
+  untrusted networks should be ignored as a matter of security.
+
+  "echo > /dev/etherd/discover" tells the driver to find out what AoE
+  devices are available.
+
+  The block devices are named like this:
+
+	e{shelf}.{slot}
+	e{shelf}.{slot}p{part}
+
+  ... so that "e0.2" is the third blade from the left (slot 2) in the
+  first shelf (shelf address zero).  That's the whole disk.  The first
+  partition on that disk would be "e0.2p1".
+
+USING SYSFS
+
+  Each aoe block device in /sys/block has the extra attributes of
+  state, mac, and netif.  The state attribute is "up" when the device
+  is ready for I/O and "down" if detected but unusable.  The
+  "down,closewait" state shows that the device is still open and
+  cannot come up again until it has been closed.
+
+  The mac attribute is the ethernet address of the remote AoE device.
+  The netif attribute is the network interface on the localhost
+  through which we are communicating with the remote AoE device.
+
+  There is a script in this directory that formats this information
+  in a convenient way.
+
+  root@makki linux# sh Documentation/aoe/status.sh 
+    device                 mac       netif           state
+      e6.0        0010040010c6        eth0              up
+      e6.1        001004001067        eth0              up
+      e6.2        001004001068        eth0              up
+      e6.3        001004001065        eth0              up
+      e6.4        001004001066        eth0              up
+      e6.5        0010040010c7        eth0              up
+      e6.6        0010040010c8        eth0              up
+      e6.7        0010040010c9        eth0              up
+      e6.8        0010040010ca        eth0              up
+      e6.9        0010040010cb        eth0              up
+      e9.0        001004000020        eth1              up
+      e9.5        001004000025        eth1              up
+      e9.9        001004000029        eth1              up
+
diff --git a/Documentation/aoe/autoload.sh b/Documentation/aoe/autoload.sh
new file mode 100644
index 00000000000000..78dad1334c6fc9
--- /dev/null
+++ b/Documentation/aoe/autoload.sh
@@ -0,0 +1,17 @@
+#!/bin/sh
+# set aoe to autoload by installing the
+# aliases in /etc/modprobe.conf
+
+f=/etc/modprobe.conf
+
+if test ! -r $f || test ! -w $f; then
+	echo "cannot configure $f for module autoloading" 1>&2
+	exit 1
+fi
+
+grep major-152 $f >/dev/null
+if [ $? = 1 ]; then
+	echo alias block-major-152 aoe >> $f
+	echo alias char-major-152 aoe >> $f
+fi
+
diff --git a/Documentation/aoe/mkdevs.sh b/Documentation/aoe/mkdevs.sh
new file mode 100644
index 00000000000000..fa007699c636a3
--- /dev/null
+++ b/Documentation/aoe/mkdevs.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+
+n_shelves=10
+
+if test "$#" != "1"; then
+	echo "Usage: sh mkdevs.sh {dir}" 1>&2
+	exit 1
+fi
+dir=$1
+
+MAJOR=152
+
+echo "Creating AoE devnode files in $dir ..."
+
+set -e
+
+mkdir -p $dir
+
+# (Status info is in sysfs.  See status.sh.)
+# rm -f $dir/stat
+# mknod -m 0400 $dir/stat c $MAJOR 1
+rm -f $dir/err
+mknod -m 0400 $dir/err c $MAJOR 2
+rm -f $dir/discover
+mknod -m 0200 $dir/discover c $MAJOR 3
+rm -f $dir/interfaces
+mknod -m 0200 $dir/interfaces c $MAJOR 4
+
+i=0
+while test $i -lt $n_shelves; do
+	sh -xc "sh `dirname $0`/mkshelf.sh $dir $i"
+	i=`expr $i + 1`
+done
diff --git a/Documentation/aoe/mkshelf.sh b/Documentation/aoe/mkshelf.sh
new file mode 100644
index 00000000000000..ba8c9a8ec0826f
--- /dev/null
+++ b/Documentation/aoe/mkshelf.sh
@@ -0,0 +1,23 @@
+#! /bin/sh
+
+if test "$#" != "2"; then
+	echo "Usage: sh mkshelf.sh {dir} {shelfaddress}" 1>&2
+	exit 1
+fi
+dir=$1
+shelf=$2
+MAJOR=152
+
+set -e
+
+minor=`echo 10 \* $shelf \* 16 | bc`
+for slot in `seq 0 9`; do
+	for part in `seq 0 15`; do
+		name=e$shelf.$slot
+		test "$part" != "0" && name=${name}p$part
+		rm -f $dir/$name
+		mknod -m 0660 $dir/$name b $MAJOR $minor
+
+		minor=`expr $minor + 1`
+	done
+done
diff --git a/Documentation/aoe/status.sh b/Documentation/aoe/status.sh
new file mode 100644
index 00000000000000..7b8c8a7f8bd6f6
--- /dev/null
+++ b/Documentation/aoe/status.sh
@@ -0,0 +1,15 @@
+# collate and present sysfs information about AoE storage
+
+set -e
+format="%8s\t%12s\t%8s\t%8s\n"
+
+printf "$format" device mac netif state
+
+for d in `ls -d /sys/block/etherd* | grep -v p`; do
+	dev=`echo "$d" | sed 's/.*!//'`
+	printf "$format" \
+		"$dev" \
+		"`cat \"$d/mac\"`" \
+		"`cat \"$d/netif\"`" \
+		"`cat \"$d/state\"`"
+done | sort
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
new file mode 100644
index 00000000000000..eb555b0bc844c1
--- /dev/null
+++ b/Documentation/feature-removal-schedule.txt
@@ -0,0 +1,26 @@
+The following is a list of files and features that are going to be
+removed in the kernel source tree.  Every entry should contain what
+exactly is going away, why it is happening, and who is going to be doing
+the work.  When the feature is removed from the kernel, it should also
+be removed from this file.
+
+---------------------------
+
+What:	devfs
+When:	July 2005
+Files:	fs/devfs/*, include/linux/devfs_fs*.h and assorted devfs
+	function calls throughout the kernel tree
+Why:	It has been unmaintained for a number of years, has unfixable
+	races, contains a naming policy within the kernel that is
+	against the LSB, and can be replaced by using udev.
+Who:	Greg Kroah-Hartman <greg@kroah.com>
+
+---------------------------
+
+What:	/proc/sys/cpu and the sysctl interface to cpufreq (2.4.x interfaces)
+When:	January 2005
+Files:	drivers/cpufreq/: cpufreq_userspace.c, proc_intf.c
+	function calls throughout the kernel tree
+Why:	Deprecated, has been replaced/superseded by (what?)....
+Who:	Dominik Brodowski <linux@brodo.de>
+
diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt
new file mode 100644
index 00000000000000..e97d024eae77e5
--- /dev/null
+++ b/Documentation/filesystems/sysfs-pci.txt
@@ -0,0 +1,88 @@
+Accessing PCI device resources through sysfs
+
+sysfs, usually mounted at /sys, provides access to PCI resources on platforms
+that support it.  For example, a given bus might look like this:
+
+     /sys/devices/pci0000:17
+     |-- 0000:17:00.0
+     |   |-- class
+     |   |-- config
+     |   |-- detach_state
+     |   |-- device
+     |   |-- irq
+     |   |-- local_cpus
+     |   |-- resource
+     |   |-- resource0
+     |   |-- resource1
+     |   |-- resource2
+     |   |-- rom
+     |   |-- subsystem_device
+     |   |-- subsystem_vendor
+     |   `-- vendor
+     `-- detach_state
+
+The topmost element describes the PCI domain and bus number.  In this case,
+the domain number is 0000 and the bus number is 17 (both values are in hex).
+This bus contains a single function device in slot 0.  The domain and bus
+numbers are reproduced for convenience.  Under the device directory are several
+files, each with their own function.
+
+       file		   function
+       ----		   --------
+       class		   PCI class (ascii, ro)
+       config		   PCI config space (binary, rw)
+       detach_state	   connection status (bool, rw)
+       device		   PCI device (ascii, ro)
+       irq		   IRQ number (ascii, ro)
+       local_cpus	   nearby CPU mask (cpumask, ro)
+       resource		   PCI resource host addresses (ascii, ro)
+       resource0..N	   PCI resource N, if present (binary, mmap)
+       rom		   PCI ROM resource, if present (binary, ro)
+       subsystem_device	   PCI subsystem device (ascii, ro)
+       subsystem_vendor	   PCI subsystem vendor (ascii, ro)
+       vendor		   PCI vendor (ascii, ro)
+
+  ro - read only file
+  rw - file is readable and writable
+  mmap - file is mmapable
+  ascii - file contains ascii text
+  binary - file contains binary data
+  cpumask - file contains a cpumask type
+
+The read only files are informational, writes to them will be ignored.
+Writable files can be used to perform actions on the device (e.g. changing
+config space, detaching a device).  mmapable files are available via an
+mmap of the file at offset 0 and can be used to do actual device programming
+from userspace.  Note that some platforms don't support mmapping of certain
+resources, so be sure to check the return value from any attempted mmap.
+
+Accessing legacy resources through sysfs
+
+Legacy I/O port and ISA memory resources are also provided in sysfs if the
+underlying platform supports them.  They're located in the PCI class heirarchy,
+e.g.
+
+	/sys/class/pci_bus/0000:17/
+	|-- bridge -> ../../../devices/pci0000:17
+	|-- cpuaffinity
+	|-- legacy_io
+	`-- legacy_mem
+
+The legacy_io file is a read/write file that can be used by applications to
+do legacy port I/O.  The application should open the file, seek to the desired
+port (e.g. 0x3e8) and do a read or a write of 1, 2 or 4 bytes.  The legacy_mem
+file should be mmapped with an offset corresponding to the memory offset
+desired, e.g. 0xa0000 for the VGA frame buffer.  The application can then
+simply dereference the returned pointer (after checking for errors of course)
+to access legacy memory space.
+
+Supporting PCI access on new platforms
+
+In order to support PCI resource mapping as described above, Linux platform
+code must define HAVE_PCI_MMAP and provide a pci_mmap_page_range function.
+Platforms are free to only support subsets of the mmap functionality, but
+useful return codes should be provided.
+
+Legacy resources are protected by the HAVE_PCI_LEGACY define.  Platforms
+wishing to support legacy functionality should define it and provide
+pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions.
\ No newline at end of file
diff --git a/Documentation/i2c/chips/smsc47b397.txt b/Documentation/i2c/chips/smsc47b397.txt
new file mode 100644
index 00000000000000..389edae7f8df7c
--- /dev/null
+++ b/Documentation/i2c/chips/smsc47b397.txt
@@ -0,0 +1,146 @@
+November 23, 2004
+
+The following specification describes the SMSC LPC47B397-NC sensor chip
+(for which there is no public datasheet available).  This document was
+provided by Craig Kelly (In-Store Broadcast Network) and edited/corrected
+by Mark M. Hoffman <mhoffman@lightlink.com>.
+
+* * * * *
+
+Methods for detecting the HP SIO and reading the thermal data on a dc7100.
+
+The thermal information on the dc7100 is contained in the SIO Hardware Monitor
+(HWM).  The information is accessed through an index/data pair.  The index/data
+pair is located at the HWM Base Address + 0 and the HWM Base Address + 1.  The
+HWM Base address can be obtained from Logical Device 8, registers 0x60 (MSB)
+and 0x61 (LSB).  Currently we are using 0x480 for the HWM Base Address and
+0x480 and 0x481 for the index/data pair.
+
+Reading temperature information.
+The temperature information is located in the following registers:
+Temp1		0x25	(Currently, this reflects the CPU temp on all systems).
+Temp2		0x26
+Temp3		0x27
+Temp4		0x80
+
+Programming Example
+The following is an example of how to read the HWM temperature registers:
+MOV	DX,480H
+MOV	AX,25H
+OUT	DX,AL
+MOV	DX,481H
+IN	AL,DX
+
+AL contains the data in hex, the temperature in Celsius is the decimal
+equivalent.
+
+Ex: If AL contains 0x2A, the temperature is 42 degrees C.
+
+Reading tach information.
+The fan speed information is located in the following registers:
+		LSB	MSB
+Tach1		0x28	0x29	(Currently, this reflects the CPU
+				fan speed on all systems).
+Tach2		0x2A	0x2B
+Tach3		0x2C	0x2D
+Tach4		0x2E	0x2F
+
+Important!!!
+Reading the tach LSB locks the tach MSB.
+The LSB Must be read first.
+
+How to convert the tach reading to RPM.
+The tach reading (TCount) is given by:  (Tach MSB * 256) + (Tach LSB)
+The SIO counts the number of 90kHz (11.111us) pulses per revolution.
+RPM = 60/(TCount * 11.111us)
+
+Example:
+Reg 0x28 = 0x9B
+Reg 0x29 = 0x08
+
+TCount = 0x89B = 2203
+
+RPM = 60 / (2203 * 11.11111 E-6) = 2451 RPM
+
+Obtaining the SIO version.
+
+CONFIGURATION SEQUENCE
+To program the configuration registers, the following sequence must be followed:
+1. Enter Configuration Mode
+2. Configure the Configuration Registers
+3. Exit Configuration Mode.
+
+Enter Configuration Mode
+To place the chip into the Configuration State The config key (0x55) is written
+to the CONFIG PORT (0x2E). 
+
+Configuration Mode
+In configuration mode, the INDEX PORT is located at the CONFIG PORT address and
+the DATA PORT is at INDEX PORT address + 1.
+
+The desired configuration registers are accessed in two steps: 
+a.	Write the index of the Logical Device Number Configuration Register
+	(i.e., 0x07) to the INDEX PORT and then write the number of the
+	desired logical device to the DATA PORT.
+
+b.	Write the address of the desired configuration register within the
+	logical device to the INDEX PORT and then write or read the config-
+	uration register through the DATA PORT.  
+
+Note: If accessing the Global Configuration Registers, step (a) is not required.
+
+Exit Configuration Mode
+To exit the Configuration State the write 0xAA to the CONFIG PORT (0x2E).
+The chip returns to the RUN State.  (This is important).
+
+Programming Example
+The following is an example of how to read the SIO Device ID located at 0x20
+
+; ENTER CONFIGURATION MODE   
+MOV	DX,02EH
+MOV	AX,055H
+OUT	DX,AL
+; GLOBAL CONFIGURATION  REGISTER 
+MOV	DX,02EH
+MOV	AL,20H
+OUT	DX,AL 
+; READ THE DATA
+MOV	DX,02FH
+IN	AL,DX
+; EXIT CONFIGURATION MODE     
+MOV	DX,02EH
+MOV	AX,0AAH
+OUT	DX,AL
+
+The registers of interest for identifying the SIO on the dc7100 are Device ID
+(0x20) and Device Rev  (0x21).
+
+The Device ID will read 0X6F
+The Device Rev currently reads 0x01
+
+Obtaining the HWM Base Address.
+The following is an example of how to read the HWM Base Address located in
+Logical Device 8.
+
+; ENTER CONFIGURATION MODE   
+MOV	DX,02EH
+MOV	AX,055H
+OUT	DX,AL
+; CONFIGURE REGISTER CRE0,   
+; LOGICAL DEVICE 8           
+MOV	DX,02EH
+MOV	AL,07H
+OUT	DX,AL ;Point to LD# Config Reg
+MOV	DX,02FH
+MOV	AL, 08H
+OUT	DX,AL;Point to Logical Device 8
+;
+MOV	DX,02EH 
+MOV	AL,60H
+OUT	DX,AL	; Point to HWM Base Addr MSB
+MOV	DX,02FH
+IN	AL,DX	; Get MSB of HWM Base Addr
+; EXIT CONFIGURATION MODE     
+MOV	DX,02EH
+MOV	AX,0AAH
+OUT	DX,AL
diff --git a/Documentation/i2c/i2c-old-porting b/Documentation/i2c/i2c-old-porting
deleted file mode 100644
index 158dfe550a3f77..00000000000000
--- a/Documentation/i2c/i2c-old-porting
+++ /dev/null
@@ -1,626 +0,0 @@
-I2C Conversion Guide for I2C-old to the current I2C API
-July 2002
-For Linux Kernel v2.5.x
-Frank Davis <fdavis@si.rr.com>
--------------------------------------------------------
-
-There exists several kernel drivers that are using an old version of the I2C
-API. These drivers need to be converted to the current (kernel 2.5.x) version.
-The following document provides a guideline to make the appropriate changes to
-the affected drivers. There maybe slight modifications to this guide that are 
-specific to the driver you are working on. If you see {driver_name}, replace 
-that with the respective name of the driver, such as saa7110.c , {driver_name} 
-= saa7110.
-
--------------------------------------------------------
-
-Step 1: Include the right header file
- 
-Perform the following change within the driver
- 
-#include <linux/i2c-old.h> --> #include <linux/i2c.h>
-
-Step 2: Add and set the i2c modes
-
-Add the following code near the top of the driver
-
-static unsigned short normal_i2c[] = {34>>1, I2C_CLIENT_END };
-static unsigned short normal_i2c_range[] = { I2C_CLIENT_END };
-static unsigned short probe[2] = { I2C_CLIENT_END , I2C_CLIENT_END };
-static unsigned short probe_range[2] = { I2C_CLIENT_END , I2C_CLIENT_END };	
-static unsigned short ignore[2] = { I2C_CLIENT_END , I2C_CLIENT_END };
-static unsigned short ignore_range[2] = { I2C_CLIENT_END, I2C_CLIENT_END };
-static unsigned short force[2] = { I2C_CLIENT_END , I2C_CLIENT_END };
-
-static struct i2c_client_address_data addr_data  = {
-	normal_i2c , normal_i2c_range,
-	probe , probe_range,
-	ignore , ignore_range,
-	force
-};
-
-static struct i2c_client client_template;
-
-Step 3: Modify the driver info struct
-
-Within the struct for the driver , such as struct {driver_name}  ,  make the 
-following change ,
-struct i2c_bus *bus --> struct i2c_client *client
-
-Make changes where this change affects references within the file.
-
-Add a semaphore to the driver struct (as above)
-
-struct semaphore lock 
-
-Step 5: Remove specific read and write functions
-
-Remove the driver specific write and read functions, usually in the form:
-{driver_name}_write , {driver_name}_read , {driver_name}_write_block , etc.
-
-Step 6: Update the write and read functions for the current I2C API
-
-Replace all references of {driver_name}_write with i2c_smbus_write_byte_data
-Replace all references of {driver_name}_read with i2c_smbus_read_byte_data or
-i2c_smbus_read_byte , depending on args passed in.
-
-** Ensure that these functions pass in the i2c_client *client , NOT the
-decoder/encoder that was passed in the driver specific write and read
-functions. 
- 
-Step 7: Modify the driver's attach function
-
-Change the driver attach function prototype :
-{driver_name}_attach(struct i2c_device *device) --> {driver_name}_attach(struct 
-i2c_adapter *adap, int addr , unsigned short flags, int kind)
-
-Create a i2c_client client...
-Add the following (where "decoder" is a reference to a struct for the driver
-info:
-
-struct i2c_client *client;
-client = kmalloc(sizeof(*client), GFP_KERNEL);
-if(client == NULL)
-	return -ENOMEM;
-client_template.adapter = adap;
-client_template.addr  = addr;
-memcpy(client, &client_template, sizeof(*client));
-strcpy(client->name , "{driver_name}");
-decoder->client = client;
-client->data = decoder;
-decoder->addr = addr;
-
-Towards the end of the function, add:
-
-init_MUTEX(&decoder->lock);
-i2c_attach_client(client);
-
-
-Step 8: Modify the driver's detach function
-
-Change the driver detach function prototype :
-{driver_name}_detach(struct i2c_device *device) --> {driver_name}_detach(struct 
-i2c_client *client)
-
-In the beginning of the detach function, add:
-i2c_detach_client(client);
-
-Towards the end of the detach function, add:
-kfree(client->data);
-kfree(client);
-
-Step 9: Modify the driver's command function
-
-Change the driver command function prototype :
-
-Step 10: Add the probe function after the driver's attach function.
-
-Add the following code:
-
-static int {driver_name}_probe(struct i2c_adapter *adap)
-{
-	return i2c_probe(adap, &addr_data, {driver_name}_attach);
-
-}
-
-Step 11: Modify the driver's i2c_driver
-
-Find the i2c_driver , such as
-static struct i2c_driver i2c_driver_saa7110
-It is usually located towards the end of the driver 
-Replace the values from I2C_DRIVERID_{something} to {driver_name}_attach, and 
-add the following
-I2C_DRIVERID_{driver_name} , // verify by looking in include/linux/i2c-id.h 
-I2C_DF_NOTIFY,
-{driver_name}_probe, 
-....
-
-Step 12: Adding the i2c_client 
-
-Add the i2c_client to the driver. Add the following code:
-
-static struct i2c_client client_template = {
-	"{driver_name}_client",
-	-1,
-	0,
-	0,
-	NULL,
-	{i2c_driver reference}
-};
-
-Step 13: Registering and Unregistering
-
-Replace i2c_register_driver with i2c_add_driver
-Replace i2c_unregister_driver with i2c_del_driver
-
--------------------------------------------------------
-
-Example:
-
-The following patch provides the i2c coversion patch for the saa7110 driver
-based on the above guide (for clarity).
-
-
---- drivers/media/video/saa7110.c.old	Fri Jun 28 10:22:52 2002
-+++ drivers/media/video/saa7110.c	Thu Jul  4 16:51:08 2002
-@@ -26,7 +26,7 @@
- #include <asm/io.h>
- #include <asm/uaccess.h>
- 
--#include <linux/i2c-old.h>
-+#include <linux/i2c.h>
- #include <linux/videodev.h>
- #include "linux/video_decoder.h"
- 
-@@ -37,13 +37,31 @@
- 
- #define	I2C_SAA7110		0x9C	/* or 0x9E */
- 
-+#define IF_NAME	"saa7110"
- #define	I2C_DELAY		10	/* 10 us or 100khz */
- 
-+static unsigned short normal_i2c[] = {34>>1, I2C_CLIENT_END };
-+static unsigned short normal_i2c_range[] = { I2C_CLIENT_END };
-+static unsigned short probe[2] = { I2C_CLIENT_END, I2C_CLIENT_END };
-+static unsigned short probe_range[2] = { I2C_CLIENT_END, I2C_CLIENT_END };
-+static unsigned short ignore[2] = { I2C_CLIENT_END, I2C_CLIENT_END };
-+static unsigned short ignore_range[2] = { I2C_CLIENT_END, I2C_CLIENT_END };
-+static unsigned short force[2] = { I2C_CLIENT_END, I2C_CLIENT_END };
-+
-+static struct i2c_client_address_data addr_data = {
-+	normal_i2c, normal_i2c_range,
-+	probe, probe_range,
-+	ignore, ignore_range,
-+	force
-+};
-+
-+static struct i2c_client client_template;
-+
- struct saa7110 {
--	struct	i2c_bus	*bus;
-+	struct i2c_client *client;
- 	int		addr;
- 	unsigned char	reg[36];
--
-+	struct semaphore lock;
- 	int		norm;
- 	int		input;
- 	int		enable;
-@@ -54,67 +72,10 @@
- };
- 
- /* ----------------------------------------------------------------------- */
--/* I2C support functions						   */
--/* ----------------------------------------------------------------------- */
--static
--int saa7110_write(struct saa7110 *decoder, unsigned char subaddr, unsigned char data)
--{
--	int ack;
--
--	LOCK_I2C_BUS(decoder->bus);
--	i2c_start(decoder->bus);
--	i2c_sendbyte(decoder->bus, decoder->addr, I2C_DELAY);
--	i2c_sendbyte(decoder->bus, subaddr, I2C_DELAY);
--	ack = i2c_sendbyte(decoder->bus, data, I2C_DELAY);
--	i2c_stop(decoder->bus);
--	decoder->reg[subaddr] = data;
--	UNLOCK_I2C_BUS(decoder->bus);
--	return ack;
--}
--
--static
--int saa7110_write_block(struct saa7110* decoder, unsigned const char *data, unsigned int len)
--{
--	unsigned subaddr = *data;
--
--	LOCK_I2C_BUS(decoder->bus);
--        i2c_start(decoder->bus);
--        i2c_sendbyte(decoder->bus,decoder->addr,I2C_DELAY);
--	while (len-- > 0) {
--                if (i2c_sendbyte(decoder->bus,*data,0)) {
--                        i2c_stop(decoder->bus);
--                        UNLOCK_I2C_BUS(decoder->bus);
--                        return -EAGAIN;
--                }
--		decoder->reg[subaddr++] = *data++;
--        }
--	i2c_stop(decoder->bus);
--	UNLOCK_I2C_BUS(decoder->bus);
--
--	return 0;
--}
--
--static
--int saa7110_read(struct saa7110* decoder)
--{
--	int data;
--
--	LOCK_I2C_BUS(decoder->bus);
--	i2c_start(decoder->bus);
--	i2c_sendbyte(decoder->bus, decoder->addr, I2C_DELAY);
--	i2c_start(decoder->bus);
--	i2c_sendbyte(decoder->bus, decoder->addr | 1, I2C_DELAY);
--	data = i2c_readbyte(decoder->bus, 1);
--	i2c_stop(decoder->bus);
--	UNLOCK_I2C_BUS(decoder->bus);
--	return data;
--}
--
--/* ----------------------------------------------------------------------- */
- /* SAA7110 functions							   */
- /* ----------------------------------------------------------------------- */
- static
--int saa7110_selmux(struct i2c_device *device, int chan)
-+int saa7110_selmux(struct i2c_client *client, int chan)
- {
- static	const unsigned char modes[9][8] = {
- /* mode 0 */	{ 0x00, 0xD9, 0x17, 0x40, 0x03, 0x44, 0x75, 0x16 },
-@@ -126,61 +87,59 @@
- /* mode 6 */	{ 0x80, 0x59, 0x17, 0x42, 0xA3, 0x44, 0x75, 0x12 },
- /* mode 7 */	{ 0x80, 0x9A, 0x17, 0xB1, 0x13, 0x60, 0xB5, 0x14 },
- /* mode 8 */	{ 0x80, 0x3C, 0x27, 0xC1, 0x23, 0x44, 0x75, 0x21 } };
--	struct saa7110* decoder = device->data;
- 	const unsigned char* ptr = modes[chan];
- 
--	saa7110_write(decoder,0x06,ptr[0]);	/* Luminance control	*/
--	saa7110_write(decoder,0x20,ptr[1]);	/* Analog Control #1	*/
--	saa7110_write(decoder,0x21,ptr[2]);	/* Analog Control #2	*/
--	saa7110_write(decoder,0x22,ptr[3]);	/* Mixer Control #1	*/
--	saa7110_write(decoder,0x2C,ptr[4]);	/* Mixer Control #2	*/
--	saa7110_write(decoder,0x30,ptr[5]);	/* ADCs gain control	*/
--	saa7110_write(decoder,0x31,ptr[6]);	/* Mixer Control #3	*/
--	saa7110_write(decoder,0x21,ptr[7]);	/* Analog Control #2	*/
-+	i2c_smbus_write_byte_data(client,0x06,ptr[0]);	/* Luminance control	*/
-+	i2c_smbus_write_byte_data(client,0x20,ptr[1]);	/* Analog Control #1	*/
-+	i2c_smbus_write_byte_data(client,0x21,ptr[2]);	/* Analog Control #2	*/
-+	i2c_smbus_write_byte_data(client,0x22,ptr[3]);	/* Mixer Control #1	*/
-+	i2c_smbus_write_byte_data(client,0x2C,ptr[4]);	/* Mixer Control #2	*/
-+	i2c_smbus_write_byte_data(client,0x30,ptr[5]);	/* ADCs gain control	*/
-+	i2c_smbus_write_byte_data(client,0x31,ptr[6]);	/* Mixer Control #3	*/
-+	i2c_smbus_write_byte_data(client,0x21,ptr[7]);	/* Analog Control #2	*/
- 
- 	return 0;
- }
- 
- static
--int determine_norm(struct i2c_device* dev)
-+int determine_norm(struct i2c_client* client)
- {
--	struct	saa7110* decoder = dev->data;
- 	int	status;
- 
- 	/* mode changed, start automatic detection */
--	status = saa7110_read(decoder);
-+	status = i2c_smbus_read_byte(client);
- 	if ((status & 3) == 0) {
--		saa7110_write(decoder,0x06,0x80);
-+		i2c_smbus_write_byte_data(client,0x06,0x80);
- 		if (status & 0x20) {
--			DEBUG(printk(KERN_INFO "%s: norm=bw60\n",dev->name));
--			saa7110_write(decoder,0x2E,0x81);
-+			DEBUG(printk(KERN_INFO "%s: norm=bw60\n",adp->name));
-+			i2c_smbus_write_byte_data(client,0x2E,0x81);
- 			return VIDEO_MODE_NTSC;
- 		}
--		DEBUG(printk(KERN_INFO "%s: norm=bw50\n",dev->name));
--		saa7110_write(decoder,0x2E,0x9A);
-+		DEBUG(printk(KERN_INFO "%s: norm=bw50\n",adp->name));
-+		i2c_smbus_write_byte_data(client,0x2E,0x9A);
- 		return VIDEO_MODE_PAL;
- 	}
- 
--	saa7110_write(decoder,0x06,0x00);
-+	i2c_smbus_write_byte_data(client,0x06,0x00);
- 	if (status & 0x20) {	/* 60Hz */
--		DEBUG(printk(KERN_INFO "%s: norm=ntsc\n",dev->name));
--		saa7110_write(decoder,0x0D,0x06);
--		saa7110_write(decoder,0x11,0x2C);
--		saa7110_write(decoder,0x2E,0x81);
-+		DEBUG(printk(KERN_INFO "%s: norm=ntsc\n",adp->name));
-+		i2c_smbus_write_byte_data(client,0x0D,0x06);
-+		i2c_smbus_write_byte_data(client,0x11,0x2C);
-+		i2c_smbus_write_byte_data(client,0x2E,0x81);
- 		return VIDEO_MODE_NTSC;
- 	}
- 
- 	/* 50Hz -> PAL/SECAM */
--	saa7110_write(decoder,0x0D,0x06);
--	saa7110_write(decoder,0x11,0x59);
--	saa7110_write(decoder,0x2E,0x9A);
-+	i2c_smbus_write_byte_data(client,0x0D,0x06);
-+	i2c_smbus_write_byte_data(client,0x11,0x59);
-+	i2c_smbus_write_byte_data(client,0x2E,0x9A);
- 
- 	mdelay(150);	/* pause 150 ms */
- 
--	status = saa7110_read(decoder);
-+	status = i2c_smbus_read_byte(client);
- 	if ((status & 0x03) == 0x01) {
- 		DEBUG(printk(KERN_INFO "%s: norm=secam\n",dev->name));
--		saa7110_write(decoder,0x0D,0x07);
-+		i2c_smbus_write_byte_data(client,0x0D,0x07);
- 		return VIDEO_MODE_SECAM;
- 	}
- 	DEBUG(printk(KERN_INFO "%s: norm=pal\n",dev->name));
-@@ -188,7 +147,7 @@
- }
- 
- static
--int saa7110_attach(struct i2c_device *device)
-+int saa7110_attach(struct i2c_adapter *adap, int  addr, unsigned short flags, int kind)
- {
- static	const unsigned char initseq[] = {
- 	     0, 0x4C, 0x3C, 0x0D, 0xEF, 0xBD, 0xF0, 0x00, 0x00,
-@@ -198,20 +157,28 @@
- 		0xD9, 0x17, 0x40, 0x41, 0x80, 0x41, 0x80, 0x4F,
- 		0xFE, 0x01, 0xCF, 0x0F, 0x03, 0x01, 0x81, 0x03,
- 		0x40, 0x75, 0x01, 0x8C, 0x03};
--	struct	saa7110*	decoder;
-+	struct	saa7110	*decoder;
-+	struct i2c_client *client;
- 	int			rv;
--
--	device->data = decoder = kmalloc(sizeof(struct saa7110), GFP_KERNEL);
--	if (device->data == 0)
-+	client=kmalloc(sizeof(*client), GFP_KERNEL);
-+	if(client == NULL) 
- 		return -ENOMEM;
--
-+	client_template.adapter = adap;
-+	client_template.addr = addr;
-+	memcpy(client, &client_template, sizeof(*client));
-+
-+	decoder = kmalloc(sizeof(*decoder), GFP_KERNEL);
-+	if (decoder == NULL) {
-+		kfree(client);
-+		return -ENOMEM;
-+		}
- 
- 	/* clear our private data */
--	memset(decoder, 0, sizeof(struct saa7110));
--	strcpy(device->name, "saa7110");
--	decoder->bus = device->bus;
--	decoder->addr = device->addr;
-+	memset(decoder, 0, sizeof(*decoder));
-+	strcpy(client->name, IF_NAME);
-+	decoder->client = client;
-+	client->data = decoder;
-+	decoder->addr = addr;
- 	decoder->norm = VIDEO_MODE_PAL;
- 	decoder->input = 0;
- 	decoder->enable = 1;
-@@ -220,40 +187,52 @@
- 	decoder->hue = 32768;
- 	decoder->sat = 32768;
- 
--	rv = saa7110_write_block(decoder, initseq, sizeof(initseq));
-+	rv = i2c_master_send(client, initseq, sizeof(initseq));
- 	if (rv < 0)
--		printk(KERN_ERR "%s_attach: init status %d\n", device->name, rv);
-+		printk(KERN_ERR "%s_attach: init status %d\n", client->name, rv);
- 	else {
--		saa7110_write(decoder,0x21,0x16);
--		saa7110_write(decoder,0x0D,0x04);
--		DEBUG(printk(KERN_INFO "%s_attach: chip version %x\n", device->name, saa7110_read(decoder)));
--		saa7110_write(decoder,0x0D,0x06);
-+		i2c_smbus_write_byte_data(client,0x21,0x16);
-+		i2c_smbus_write_byte_data(client,0x0D,0x04);
-+		DEBUG(printk(KERN_INFO "%s_attach: chip version %x\n", client->name, i2c_smbus_read_byte(client)));
-+		i2c_smbus_write_byte_data(client,0x0D,0x06);
- 	}
- 
-+	init_MUTEX(&decoder->lock);
-+	i2c_attach_client(client);
- 	/* setup and implicit mode 0 select has been performed */
- 	return 0;
- }
- 
-+static 
-+int saa7110_probe(struct i2c_adapter *adap) 
-+{
-+	return i2c_probe(adap, &addr_data, saa7110_attach);
-+}
-+
- static
--int saa7110_detach(struct i2c_device *device)
-+int saa7110_detach(struct i2c_client *client)
- {
--	struct saa7110* decoder = device->data;
-+	struct saa7110* decoder = client->data;
- 
--	DEBUG(printk(KERN_INFO "%s_detach\n",device->name));
-+	i2c_detach_client(client);
-+
-+	DEBUG(printk(KERN_INFO "%s_detach\n",client->name));
- 
- 	/* stop further output */
--	saa7110_write(decoder,0x0E,0x00);
-+	i2c_smbus_write_byte_data(client,0x0E,0x00);
- 
--	kfree(device->data);
-+	kfree(decoder);
-+	kfree(client);
- 
- 	return 0;
- }
- 
- static
--int saa7110_command(struct i2c_device *device, unsigned int cmd, void *arg)
-+int saa7110_command(struct i2c_client *client, unsigned int cmd, void *arg)
- {
--	struct saa7110* decoder = device->data;
-+	struct saa7110* decoder = client->data;
- 	int	v;
- 
- 	switch (cmd) {
-@@ -272,11 +251,11 @@
- 
- 	 case DECODER_GET_STATUS:
- 		{
--			struct saa7110* decoder = device->data;
-+			struct saa7110* decoder = client->data;
- 			int status;
- 			int res = 0;
- 
--			status = i2c_read(device->bus,device->addr|1);
-+			status = i2c_smbus_read_byte(client);
- 			if (status & 0x40)
- 				res |= DECODER_STATUS_GOOD;
- 			if (status & 0x03)
-@@ -301,26 +280,26 @@
- 		v = *(int*)arg;
- 		if (decoder->norm != v) {
- 			decoder->norm = v;
--			saa7110_write(decoder, 0x06, 0x00);
-+			i2c_smbus_write_byte_data(client, 0x06, 0x00);
- 			switch (v) {
- 			 case VIDEO_MODE_NTSC:
--				saa7110_write(decoder, 0x0D, 0x06);
--				saa7110_write(decoder, 0x11, 0x2C);
--				saa7110_write(decoder, 0x30, 0x81);
--				saa7110_write(decoder, 0x2A, 0xDF);
-+				i2c_smbus_write_byte_data(client, 0x0D, 0x06);
-+				i2c_smbus_write_byte_data(client, 0x11, 0x2C);
-+				i2c_smbus_write_byte_data(client, 0x30, 0x81);
-+				i2c_smbus_write_byte_data(client, 0x2A, 0xDF);
- 				break;
- 			 case VIDEO_MODE_PAL:
--				saa7110_write(decoder, 0x0D, 0x06);
--				saa7110_write(decoder, 0x11, 0x59);
--				saa7110_write(decoder, 0x2E, 0x9A);
-+				i2c_smbus_write_byte_data(client, 0x0D, 0x06);
-+				i2c_smbus_write_byte_data(client, 0x11, 0x59);
-+				i2c_smbus_write_byte_data(client, 0x2E, 0x9A);
- 				break;
- 			 case VIDEO_MODE_SECAM:
--				saa7110_write(decoder, 0x0D, 0x07);
--				saa7110_write(decoder, 0x11, 0x59);
--				saa7110_write(decoder, 0x2E, 0x9A);
-+				i2c_smbus_write_byte_data(client, 0x0D, 0x07);
-+				i2c_smbus_write_byte_data(client, 0x11, 0x59);
-+				i2c_smbus_write_byte_data(client, 0x2E, 0x9A);
- 				break;
- 			 case VIDEO_MODE_AUTO:
--				*(int*)arg = determine_norm(device);
-+				*(int*)arg = determine_norm(client);
- 				break;
- 			 default:
- 				return -EPERM;
-@@ -334,7 +313,7 @@
- 			return -EINVAL;
- 		if (decoder->input != v) {
- 			decoder->input = v;
--			saa7110_selmux(device, v);
-+			saa7110_selmux(client, v);
- 		}
- 		break;
- 
-@@ -349,7 +328,7 @@
- 		v = *(int*)arg;
- 		if (decoder->enable != v) {
- 			decoder->enable = v;
--			saa7110_write(decoder,0x0E, v ? 0x18 : 0x00);
-+			i2c_smbus_write_byte_data(client,0x0E, v ? 0x18 : 0x00);
- 		}
- 		break;
- 
-@@ -360,22 +339,22 @@
- 			if (decoder->bright != pic->brightness) {
- 				/* We want 0 to 255 we get 0-65535 */
- 				decoder->bright = pic->brightness;
--				saa7110_write(decoder, 0x19, decoder->bright >> 8);
-+				i2c_smbus_write_byte_data(client, 0x19, decoder->bright >> 8);
- 			}
- 			if (decoder->contrast != pic->contrast) {
- 				/* We want 0 to 127 we get 0-65535 */
- 				decoder->contrast = pic->contrast;
--				saa7110_write(decoder, 0x13, decoder->contrast >> 9);
-+				i2c_smbus_write_byte_data(client, 0x13, decoder->contrast >> 9);
- 			}
- 			if (decoder->sat != pic->colour) {
- 				/* We want 0 to 127 we get 0-65535 */
- 				decoder->sat = pic->colour;
--				saa7110_write(decoder, 0x12, decoder->sat >> 9);
-+				i2c_smbus_write_byte_data(client, 0x12, decoder->sat >> 9);
- 			}
- 			if (decoder->hue != pic->hue) {
- 				/* We want -128 to 127 we get 0-65535 */
- 				decoder->hue = pic->hue;
--				saa7110_write(decoder, 0x07, (decoder->hue>>8)-128);
-+				i2c_smbus_write_byte_data(client, 0x07, (decoder->hue>>8)-128);
- 			}
- 		}
- 		break;
-@@ -383,7 +362,7 @@
- 	 case DECODER_DUMP:
- 		for (v=0; v<34; v+=16) {
- 			int j;
--			DEBUG(printk(KERN_INFO "%s: %03x\n",device->name,v));
-+			DEBUG(printk(KERN_INFO "%s: %03x\n",client->name,v));
- 			for (j=0; j<16; j++) {
- 				DEBUG(printk(KERN_INFO " %02x",decoder->reg[v+j]));
- 			}
-@@ -402,24 +381,30 @@
- 
- static struct i2c_driver i2c_driver_saa7110 =
- {
--	"saa7110",			/* name */
--
--	I2C_DRIVERID_VIDEODECODER,	/* in i2c.h */
--	I2C_SAA7110, I2C_SAA7110+1,	/* Addr range */
--
--	saa7110_attach,
--	saa7110_detach,
--	saa7110_command
-+	.owner		= THIS_MODULE,
-+	.name		= IF_NAME,
-+	.id		= I2C_DRIVERID_SAA7110,
-+	.flags		= I2C_DF_NOTIFY,
-+	.attach_adapter	= saa7110_probe,
-+	.detach_adapter	= saa7110_detach,
-+	.command	= saa7110_command,
- };
-+static struct i2c_client client_template = {
-+	"saa7110_client",
-+	-1,
-+	0,
-+	0,
-+	NULL,
-+	&i2c_driver_saa7110
-+};
- 
- static int saa7110_init(void)
- {
--	return i2c_register_driver(&i2c_driver_saa7110);
-+	return i2c_add_driver(&i2c_driver_saa7110);
- }
- 
- static void saa7110_exit(void)
- {
--	i2c_unregister_driver(&i2c_driver_saa7110);
-+	i2c_del_driver(&i2c_driver_saa7110);
- }
- 
- 
- 
-
diff --git a/Documentation/i2c/i2c-stub b/Documentation/i2c/i2c-stub
index 2626ba926e4db8..d6dcb138abf510 100644
--- a/Documentation/i2c/i2c-stub
+++ b/Documentation/i2c/i2c-stub
@@ -2,14 +2,19 @@ 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.
+This module is a very simple fake I2C/SMBus driver.  It implements four
+types of SMBus commands: write quick, (r/w) byte, (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.
 
+A pointer register with auto-increment is implemented for all byte
+operations.  This allows for continuous byte reads like those supported by
+EEPROMs, among others.
+
 The typical use-case is like this:
 	1. load this module
 	2. use i2cset (from lm_sensors project) to pre-load some data
diff --git a/Documentation/moxa-smartio b/Documentation/moxa-smartio
index 6a13b8e2aab4ea..fe24ecc6372e6b 100644
--- a/Documentation/moxa-smartio
+++ b/Documentation/moxa-smartio
@@ -1,13 +1,3 @@
-***NOTE*** - The driver included in the kernel is not maintained by Moxa.  They
-have a version 1.8 driver available from:
-
-http://www.moxa.com
-
-that works with 2.6 kernels.  Currently, Moxa has no plans to have their updated
-driver merged into the kernel.
-
-James Nelson <james4765@gmail.com> - 12-12-2004
-
 =============================================================================
 
 	MOXA Smartio Family Device Driver Ver 1.1 Installation Guide
diff --git a/Documentation/stable_api_nonsense.txt b/Documentation/stable_api_nonsense.txt
index c33c99c5100ccc..3cea1387527785 100644
--- a/Documentation/stable_api_nonsense.txt
+++ b/Documentation/stable_api_nonsense.txt
@@ -9,7 +9,7 @@ realize that this article describes the _in kernel_ interfaces, not the
 kernel to userspace interfaces.  The kernel to userspace interface is
 the one that application programs use, the syscall interface.  That
 interface is _very_ stable over time, and will not break.  I have old
-programs that were built on a pre 0.9something kernel that still works
+programs that were built on a pre 0.9something kernel that still work
 just fine on the latest 2.6 kernel release.  This interface is the one
 that users and application programmers can count on being stable.
 
@@ -167,7 +167,7 @@ up by the person who did the kernel change in the first place.  This
 ensures that your driver is always buildable, and works over time, with
 very little effort on your part.
 
-The very good side affects of having your driver in the main kernel tree
+The very good side effects of having your driver in the main kernel tree
 are:
   - The quality of the driver will rise as the maintenance costs (to the
     original developer) will decrease.
diff --git a/Documentation/usb/sn9c102.txt b/Documentation/usb/sn9c102.txt
index 18ceabdb36e41a..53a978fdd69cfb 100644
--- a/Documentation/usb/sn9c102.txt
+++ b/Documentation/usb/sn9c102.txt
@@ -11,16 +11,17 @@ Index
 1.  Copyright
 2.  Disclaimer
 3.  License
-4.  Overview
-5.  Driver installation
+4.  Overview and features
+5.  Module dependencies
 6.  Module loading
 7.  Module parameters
 8.  Optional device control through "sysfs"
 9.  Supported devices
-10. How to add support for new image sensors
+10. How to add plug-in's for new image sensors
 11. Notes for V4L2 application developers
-12. Contact information
-13. Credits
+12. Video frame formats
+13. Contact information
+14. Credits
 
 
 1. Copyright
@@ -51,16 +52,18 @@ along with this program; if not, write to the Free Software
 Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 
 
-4. Overview
-===========
+4. Overview and features
+========================
 This driver attempts to support the video and audio streaming capabilities of
-the devices mounting the SONiX SN9C101, SN9C102 and SN9C103 (or SUI-102) PC
-Camera Controllers.
+the devices mounting the SONiX SN9C101, SN9C102 and SN9C103 PC Camera
+Controllers.
 
 It's worth to note that SONiX has never collaborated with the author during the
 development of this project, despite several requests for enough detailed
 specifications of the register tables, compression engine and video data format
-of the above chips.
+of the above chips. Nevertheless, these informations are no longer necessary,
+becouse all the aspects related to these chips are known and have been
+described in detail in this documentation.
 
 The driver relies on the Video4Linux2 and USB core modules. It has been
 designed to run properly on SMP systems as well.
@@ -79,15 +82,16 @@ Some of the features of the driver are:
   pixel area of image sensor;
 - image downscaling with arbitrary scaling factors from 1, 2 and 4 in both
   directions (see "Notes for V4L2 application developers" paragraph);
-- two different video formats for uncompressed or compressed data (see also
-  "Notes for V4L2 application developers" paragraph);
+- two different video formats for uncompressed or compressed data in low or
+  high compression quality (see also "Notes for V4L2 application developers"
+  and "Video frame formats" paragraphs);
 - full support for the capabilities of many of the possible image sensors that
   can be connected to the SN9C10x bridges, including, for istance, red, green,
   blue and global gain adjustments and exposure (see "Supported devices"
   paragraph for details);
 - use of default color settings for sunlight conditions;
-- dynamic I/O interface for both SN9C10x and image sensor control (see
-  "Optional device control through 'sysfs'" paragraph);
+- dynamic I/O interface for both SN9C10x and image sensor control and
+  monitoring (see "Optional device control through 'sysfs'" paragraph);
 - dynamic driver control thanks to various module parameters (see "Module
   parameters" paragraph);
 - up to 64 cameras can be handled at the same time; they can be connected and
@@ -177,7 +181,7 @@ Default:        2
 -------------------------------------------------------------------------------
 
 
-8. Optional device control through "sysfs"
+8. Optional device control through "sysfs" [1]
 ==========================================
 It is possible to read and write both the SN9C10x and the image sensor
 registers by using the "sysfs" filesystem interface.
@@ -195,9 +199,9 @@ There are other four entries in the directory above for each registered camera:
 SN9C10x bridge, while the other two control the sensor chip. "reg" and
 "i2c_reg" hold the values of the current register index where the following
 reading/writing operations are addressed at through "val" and "i2c_val". Their
-use is not intended for end-users, unless you know what you are doing. Note
-that "i2c_reg" and "i2c_val" won't be created if the sensor does not actually
-support the standard I2C protocol. Also, remember that you must be logged in as
+use is not intended for end-users. Note that "i2c_reg" and "i2c_val" won't be
+created if the sensor does not actually support the standard I2C protocol or
+its registers are not 8-bit long. Also, remember that you must be logged in as
 root before writing to them.
 
 As an example, suppose we were to want to read the value contained in the
@@ -216,7 +220,48 @@ Now let's set the green gain's register of the SN9C101 or SN9C102 chips to 2:
 	[root@localhost #] echo 2 > val
 
 Note that the SN9C10x always returns 0 when some of its registers are read.
-To avoid race conditions, all the I/O accesses to the files are serialized.
+To avoid race conditions, all the I/O accesses to the above files are
+serialized.
+
+The sysfs interface also provides the "frame_header" entry, which exports the
+frame header of the most recent requested and captured video frame. The header
+is 12-bytes long and is appended to every video frame by the SN9C10x
+controllers. As an example, this additional information can be used by the user
+application for implementing auto-exposure features via software. 
+
+The following table describes the frame header:
+
+Byte #  Value         Description
+------  -----         -----------
+0x00    0xFF          Frame synchronisation pattern.
+0x01    0xFF          Frame synchronisation pattern.
+0x02    0x00          Frame synchronisation pattern.
+0x03    0xC4          Frame synchronisation pattern.
+0x04    0xC4          Frame synchronisation pattern.
+0x05    0x96          Frame synchronisation pattern.
+0x06    0x00 or 0x01  Unknown meaning. The exact value depends on the chip.
+0x07    0xXX          Variable value, whose bits are ff00uzzc, where ff is a
+                      frame counter, u is unknown, zz is a size indicator
+                      (00 = VGA, 01 = SIF, 10 = QSIF) and c stands for
+                      "compression enabled" (1 = yes, 0 = no).
+0x08    0xXX          Brightness sum inside Auto-Exposure area (low-byte).
+0x09    0xXX          Brightness sum inside Auto-Exposure area (high-byte).
+                      For a pure white image, this number will be equal to 500
+                      times the area of the specified AE area. For images
+                      that are not pure white, the value scales down according
+                      to relative whiteness.
+0x0A    0xXX          Brightness sum outside Auto-Exposure area (low-byte).
+0x0B    0xXX          Brightness sum outside Auto-Exposure area (high-byte).
+                      For a pure white image, this number will be equal to 125
+                      times the area outside of the specified AE area. For
+                      images that are not pure white, the value scales down
+                      according to relative whiteness.
+
+The AE area (sx, sy, ex, ey) in the active window can be set by programming the
+registers 0x1c, 0x1d, 0x1e and 0x1f of the SN9C10x controllers, where one unit
+corresponds to 32 pixels.
+
+[1] The frame header has been documented by Bertrik Sikken.
 
 
 9. Supported devices
@@ -275,8 +320,10 @@ kernel messages will always tell you whether this is the case:
 
 Model       Manufacturer
 -----       ------------
-PAS106B     PixArt Imaging Inc.
-PAS202BCB   PixArt Imaging Inc.
+HV7131D     Hynix Semiconductor, Inc.
+MI-0343     Micron Technology, Inc.
+PAS106B     PixArt Imaging, Inc.
+PAS202BCB   PixArt Imaging, Inc.
 TAS5110C1B  Taiwan Advanced Sensor Corporation
 TAS5130D1B  Taiwan Advanced Sensor Corporation
 
@@ -295,15 +342,15 @@ appreciated. Non-available hardware won't be supported by the author of this
 driver.
 
 
-10. How to add support for new image sensors
-============================================
-It should be easy to write code for new sensors by using the small API that I
-have created for this purpose, which is present in "sn9c102_sensor.h"
+10. How to add plug-in's for new image sensors
+==============================================
+It should be easy to write plug-in's for new sensors by using the small API
+that has been created for this purpose, which is present in "sn9c102_sensor.h"
 (documentation is included there). As an example, have a look at the code in
 "sn9c102_pas106b.c", which uses the mentioned interface.
 
-At the moment, possible unsupported image sensors are: HV7131x series (VGA),
-MI03x series (VGA), OV7620 (VGA), OV7630 (VGA), CIS-VF10 (VGA).
+At the moment, possible unsupported image sensors are: CIS-VF10 (VGA),
+OV7620 (VGA), OV7630 (VGA).
 
 
 11. Notes for V4L2 application developers
@@ -332,29 +379,98 @@ scaling factor is restored to 1.
 This driver supports two different video formats: the first one is the "8-bit
 Sequential Bayer" format and can be used to obtain uncompressed video data
 from the device through the current I/O method, while the second one provides
-"raw" compressed video data (without the initial and final frame headers). The
-compression quality may vary from 0 to 1 and can be selected or queried thanks
-to the VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP V4L2 ioctl's. For maximum
-flexibility, the default active video format depends on how the image sensor
-being used is initialized (as described in the documentation of the API for the
-image sensors supplied by this driver).
+"raw" compressed video data (without frame headers not related to the
+compressed data). The compression quality may vary from 0 to 1 and can be
+selected or queried thanks to the VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP V4L2
+ioctl's. For maximum flexibility, both the default active video format and the
+default compression quality depend on how the image sensor being used is
+initialized (as described in the documentation of the API for the image sensors
+supplied by this driver).
 
 
-12. Contact information
+12. Video frame formats [1]
+=======================
+The SN9C10x PC Camera Controllers can send images in two possible video
+formats over the USB: either native "Sequential RGB Bayer" or Huffman
+compressed. The latter is used to achieve high frame rates. The current video
+format may be selected or queried from the user application by calling the
+VIDIOC_S_FMT or VIDIOC_G_FMT ioctl's, as described in the V4L2 API
+specifications.
+
+The name "Sequential Bayer" indicates the organization of the red, green and
+blue pixels in one video frame. Each pixel is associated with a 8-bit long
+value and is disposed in memory according to the pattern shown below:
+
+B[0]   G[1]    B[2]    G[3]    ...   B[m-2]         G[m-1]
+G[m]   R[m+1]  G[m+2]  R[m+2]  ...   G[2m-2]        R[2m-1] 
+...
+...                                  B[(n-1)(m-2)]  G[(n-1)(m-1)]
+...                                  G[n(m-2)]      R[n(m-1)]
+
+The above matrix also represents the sequential or progressive read-out mode of
+the (n, m) Bayer color filter array used in many CCD/CMOS image sensors.
+
+One compressed video frame consists of a bitstream that encodes for every R, G,
+or B pixel the difference between the value of the pixel itself and some
+reference pixel value. Pixels are organised in the Bayer pattern and the Bayer
+sub-pixels are tracked individually and alternatingly. For example, in the
+first line values for the B and G1 pixels are alternatingly encoded, while in
+the second line values for the G2 and R pixels are alternatingly encoded.
+
+The pixel reference value is calculated as follows:
+- the 4 top left pixels are encoded in raw uncompressed 8-bit format;
+- the value in the top two rows is the value of the pixel left of the current
+  pixel;
+- the value in the left column is the value of the pixel above the current
+  pixel;
+- for all other pixels, the reference value is the average of the value of the
+  pixel on the left and the value of the pixel above the current pixel;
+- there is one code in the bitstream that specifies the value of a pixel
+  directly (in 4-bit resolution);
+- pixel values need to be clamped inside the range [0..255] for proper
+  decoding.
+
+The algorithm purely describes the conversion from compressed Bayer code used
+in the SN9C10x chips to uncompressed Bayer. Additional steps are required to
+convert this to a color image (i.e. a color interpolation algorithm).
+ 
+The following Huffman codes have been found:
+0: +0 (relative to reference pixel value) 
+100: +4
+101: -4?
+1110xxxx: set absolute value to xxxx.0000 
+1101: +11
+1111: -11
+11001: +20
+110000: -20
+110001: ??? - these codes are apparently not used
+
+[1] The Huffman compression algorithm has been reverse-engineered and
+    documented by Bertrik Sikken.
+
+
+13. Contact information
 =======================
-I may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
+The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
 
-I can accept GPG/PGP encrypted e-mail. My GPG key ID is 'FCE635A4'.
-My public 1024-bit key should be available at any keyserver; the fingerprint
-is: '88E8 F32F 7244 68BA 3958  5D40 99DA 5D2A FCE6 35A4'.
+GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is
+'FCE635A4'; the public 1024-bit key should be available at any keyserver;
+the fingerprint is: '88E8 F32F 7244 68BA 3958  5D40 99DA 5D2A FCE6 35A4'.
 
 
-13. Credits
+14. Credits
 ===========
-I would thank the following persons:
+Many thanks to following persons for their contribute (listed in alphabetical
+order):
 
-- Stefano Mozzi, who donated 45 EU;
 - Luca Capello for the donation of a webcam;
-- Mizuno Takafumi for the donation of a webcam;
+- Joao Rodrigo Fuzaro, Joao Limirio, Claudio Filho and Caio Begotti for the
+  donation of a webcam;
 - Carlos Eduardo Medaglia Dyonisio, who added the support for the PAS202BCB
-  image sensor.
+  image sensor;
+- Stefano Mozzi, who donated 45 EU;
+- Bertrik Sikken, who reverse-engineered and documented the Huffman compression
+  algorithm used in the SN9C10x controllers and implemented the first decoder;
+- Mizuno Takafumi for the donation of a webcam;
+- An "anonymous" donator (who didn't want his name to be revealed) for the
+  donation of a webcam.
diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic
new file mode 100644
index 00000000000000..eace3046a8582b
--- /dev/null
+++ b/Documentation/w1/w1.generic
@@ -0,0 +1,19 @@
+Any w1 device must be connected to w1 bus master device - for example
+ds9490 usb device or w1-over-GPIO or RS232 converter.
+Driver for w1 bus master must provide several functions(you can find
+them in struct w1_bus_master definition in w1.h) which then will be
+called by w1 core to send various commands over w1 bus(by default it is
+reset and search commands). When some device is found on the bus, w1 core
+checks if driver for it's family is loaded.
+If driver is loaded w1 core creates new w1_slave object and registers it
+in the system(creates some generic sysfs files(struct w1_family_ops in
+w1_family.h), notifies any registered listener and so on...).
+It is device driver's business to provide any communication method
+upstream.
+For example w1_therm driver(ds18?20 thermal sensor family driver)
+provides temperature reading function which is bound to ->rbin() method
+of the above w1_family_ops structure.
+w1_smem - driver for simple 64bit memory cell provides ID reading
+method.
+
+You can call above methods by reading appropriate sysfs files.