---

yaml
---
r: 4791
b: refs/heads/master
c: 514604c
h: refs/heads/master
i:
  4789: ab6adbb
  4787: 97a3126
  4783: a21e9d3
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 1e279dd855d15b72364b4103f872d67d8592647e
+refs/heads/master: 514604c6d1779c55d3e97dc4e9a71c117c1ccbcd

trunk/Documentation/i2c/chips/max6875

@@ -2,10 +2,10 @@ Kernel driver max6875
 =====================
 
 Supported chips:
-  * Maxim MAX6874, MAX6875
-    Prefix: 'max6875'
+  * Maxim max6874, max6875
+    Prefixes: 'max6875'
     Addresses scanned: 0x50, 0x52
-    Datasheet:
+    Datasheets:
         http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf
 
 Author: Ben Gardner <bgardner@wabtec.com>
@@ -23,26 +23,14 @@ Module Parameters
 Description
 -----------
 
-The Maxim MAX6875 is an EEPROM-programmable power-supply sequencer/supervisor.
+The MAXIM max6875 is a EEPROM-programmable power-supply sequencer/supervisor.
 It provides timed outputs that can be used as a watchdog, if properly wired.
 It also provides 512 bytes of user EEPROM.
 
-At reset, the MAX6875 reads the configuration EEPROM into its configuration
+At reset, the max6875 reads the configuration eeprom into its configuration
 registers.  The chip then begins to operate according to the values in the
 registers.
 
-The Maxim MAX6874 is a similar, mostly compatible device, with more intputs
-and outputs:
-
-             vin     gpi    vout
-MAX6874        6       4       8
-MAX6875        4       3       5
-
-MAX6874 chips can have four different addresses (as opposed to only two for
-the MAX6875). The additional addresses (0x54 and 0x56) are not probed by
-this driver by default, but the probe module parameter can be used if
-needed.
-
 See the datasheet for details on how to program the EEPROM.
 
 

trunk/Documentation/i2c/dev-interface

@@ -14,12 +14,9 @@ C example
 =========
 
 So let's say you want to access an i2c adapter from a C program. The
-first thing to do is "#include <linux/i2c-dev.h>". Please note that
-there are two files named "i2c-dev.h" out there, one is distributed
-with the Linux kernel and is meant to be included from kernel
-driver code, the other one is distributed with lm_sensors and is
-meant to be included from user-space programs. You obviously want
-the second one here.
+first thing to do is `#include <linux/i2c.h>" and "#include <linux/i2c-dev.h>. 
+Yes, I know, you should never include kernel header files, but until glibc 
+knows about i2c, there is not much choice.
 
 Now, you have to decide which adapter you want to access. You should
 inspect /sys/class/i2c-dev/ to decide this. Adapter numbers are assigned
@@ -81,7 +78,7 @@ Full interface description
 ==========================
 
 The following IOCTLs are defined and fully supported 
-(see also i2c-dev.h):
+(see also i2c-dev.h and i2c.h):
 
 ioctl(file,I2C_SLAVE,long addr)
   Change slave address. The address is passed in the 7 lower bits of the
@@ -100,10 +97,10 @@ ioctl(file,I2C_PEC,long select)
 ioctl(file,I2C_FUNCS,unsigned long *funcs)
   Gets the adapter functionality and puts it in *funcs.
 
-ioctl(file,I2C_RDWR,struct i2c_rdwr_ioctl_data *msgset)
+ioctl(file,I2C_RDWR,struct i2c_ioctl_rdwr_data *msgset)
 
   Do combined read/write transaction without stop in between.
-  The argument is a pointer to a struct i2c_rdwr_ioctl_data {
+  The argument is a pointer to a struct i2c_ioctl_rdwr_data {
 
       struct i2c_msg *msgs;  /* ptr to array of simple messages */
       int nmsgs;             /* number of messages to exchange */

trunk/Documentation/i2c/writing-clients

@@ -27,6 +27,7 @@ address.
 static struct i2c_driver foo_driver = {
 	.owner		= THIS_MODULE,
 	.name		= "Foo version 2.3 driver",
+	.id		= I2C_DRIVERID_FOO, /* from i2c-id.h, optional */
 	.flags		= I2C_DF_NOTIFY,
 	.attach_adapter	= &foo_attach_adapter,
 	.detach_client	= &foo_detach_client,
@@ -36,6 +37,12 @@ static struct i2c_driver foo_driver = {
 The name can be chosen freely, and may be upto 40 characters long. Please
 use something descriptive here.
 
+If used, the id should be a unique ID. The range 0xf000 to 0xffff is
+reserved for local use, and you can use one of those until you start
+distributing the driver, at which time you should contact the i2c authors
+to get your own ID(s). Note that most of the time you don't need an ID
+at all so you can just omit it.
+
 Don't worry about the flags field; just put I2C_DF_NOTIFY into it. This
 means that your driver will be notified when new adapters are found.
 This is almost always what you want.

trunk/Documentation/kernel-parameters.txt

@@ -37,7 +37,7 @@ restrictions referred to are that the relevant option is valid if:
 	IA-32	IA-32 aka i386 architecture is enabled.
 	IA-64	IA-64 architecture is enabled.
 	IOSCHED	More than one I/O scheduler is enabled.
-	IP_PNP	IP DHCP, BOOTP, or RARP is enabled.
+	IP_PNP	IP DCHP, BOOTP, or RARP is enabled.
 	ISAPNP	ISA PnP code is enabled.
 	ISDN	Appropriate ISDN support is enabled.
 	JOY	Appropriate joystick support is enabled.

trunk/Documentation/pcmcia/driver-changes.txt

@@ -1,13 +1,6 @@
 This file details changes in 2.6 which affect PCMCIA card driver authors:
 
-* event handler initialization in struct pcmcia_driver (as of 2.6.13)
-   The event handler is notified of all events, and must be initialized
-   as the event() callback in the driver's struct pcmcia_driver.
-
-* pcmcia/version.h should not be used (as of 2.6.13)
-   This file will be removed eventually.
-
-* in-kernel device<->driver matching (as of 2.6.13)
+* in-kernel device<->driver matching
    PCMCIA devices and their correct drivers can now be matched in
    kernelspace. See 'devicetable.txt' for details.
 

trunk/Documentation/usb/sn9c102.txt

@@ -297,7 +297,6 @@ Vendor ID  Product ID
 0x0c45     0x602a
 0x0c45     0x602b
 0x0c45     0x602c
-0x0c45     0x602d
 0x0c45     0x6030
 0x0c45     0x6080
 0x0c45     0x6082
@@ -334,7 +333,6 @@ Model       Manufacturer
 -----       ------------
 HV7131D     Hynix Semiconductor, Inc.
 MI-0343     Micron Technology, Inc.
-OV7630      OmniVision Technologies, Inc.
 PAS106B     PixArt Imaging, Inc.
 PAS202BCB   PixArt Imaging, Inc.
 TAS5110C1B  Taiwan Advanced Sensor Corporation
@@ -472,11 +470,9 @@ order):
 - Luca Capello for the donation of a webcam;
 - Joao Rodrigo Fuzaro, Joao Limirio, Claudio Filho and Caio Begotti for the
   donation of a webcam;
-- Jon Hollstrom for the donation of a webcam;
 - Carlos Eduardo Medaglia Dyonisio, who added the support for the PAS202BCB
   image sensor;
 - Stefano Mozzi, who donated 45 EU;
-- Andrew Pearce for the donation of a webcam;
 - 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;

trunk/Documentation/usb/usbmon.txt

@@ -101,13 +101,6 @@ Here is the list of words, from left to right:
   or 3 and 2 positions, correspondingly.
 - URB Status. This field makes no sense for submissions, but is present
   to help scripts with parsing. In error case, it contains the error code.
-  In case of a setup packet, it contains a Setup Tag. If scripts read a number
-  in this field, the proceed to read Data Length. Otherwise, they read
-  the setup packet before reading the Data Length.
-- Setup packet, if present, consists of 5 words: one of each for bmRequestType,
-  bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0.
-  These words are safe to decode if Setup Tag was 's'. Otherwise, the setup
-  packet was present, but not captured, and the fields contain filler.
 - Data Length. This is the actual length in the URB.
 - Data tag. The usbmon may not always capture data, even if length is nonzero.
   Only if tag is '=', the data words are present.
@@ -132,31 +125,25 @@ class ParsedLine {
 			String data_str = st.nextToken();
 			int len = data_str.length() / 2;
 			int i;
-			int b;	// byte is signed, apparently?! XXX
 			for (i = 0; i < len; i++) {
-				// data[data_len] = Byte.parseByte(
-				//     data_str.substring(i*2, i*2 + 2),
-				//     16);
-				b = Integer.parseInt(
-				     data_str.substring(i*2, i*2 + 2),
-				     16);
-				if (b >= 128)
-					b *= -1;
-				data[data_len] = (byte) b;
+				data[data_len] = Byte.parseByte(
+				    data_str.substring(i*2, i*2 + 2),
+				    16);
 				data_len++;
 			}
 		}
 	}
 }
 
-This format may be changed in the future.
+This format is obviously deficient. For example, the setup packet for control
+transfers is not delivered. This will change in the future.
 
 Examples:
 
-An input control transfer to get a port status.
+An input control transfer to get a port status:
 
-d5ea89a0 3575914555 S Ci:001:00 s a3 00 0000 0003 0004 4 <
-d5ea89a0 3575914560 C Ci:001:00 0 4 = 01050000
+d74ff9a0 2640288196 S Ci:001:00 -115 4 <
+d74ff9a0 2640288202 C Ci:001:00 0 4 = 01010100
 
 An output bulk transfer to send a SCSI command 0x5E in a 31-byte Bulk wrapper
 to a storage device at address 5:

trunk/Documentation/video4linux/CARDLIST.bttv

@@ -1,4 +1,4 @@
-card=0 -  *** UNKNOWN/GENERIC ***
+card=0 -  *** UNKNOWN/GENERIC *** 
 card=1 - MIRO PCTV
 card=2 - Hauppauge (bt848)
 card=3 - STB, Gateway P/N 6000699 (bt848)

trunk/Documentation/video4linux/CARDLIST.cx88

@@ -27,5 +27,3 @@ card=25 - Digital-Logic MICROSPACE Entertainment Center (MEC)
 card=26 - IODATA GV/BCTV7E
 card=27 - PixelView PlayTV Ultra Pro (Stereo)
 card=28 - DViCO FusionHDTV 3 Gold-T
-card=29 - ADS Tech Instant TV DVB-T PCI
-card=30 - TerraTec Cinergy 1400 DVB-T