---

yaml
---
r: 108628
b: refs/heads/master
c: 6f088f1
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: f0af7245f1725fdc39b32b59c20500448437ddbe
+refs/heads/master: 6f088f1d215be5250582b974f83f0e3aa6ad3a28

trunk/Documentation/DocBook/videobook.tmpl

@@ -1648,7 +1648,7 @@ static struct video_buffer capture_fb;
 
   <chapter id="pubfunctions">
      <title>Public Functions Provided</title>
-!Edrivers/media/video/v4l2-dev.c
+!Edrivers/media/video/videodev.c
   </chapter>
 
 </book>

trunk/Documentation/DocBook/z8530book.tmpl

@@ -69,6 +69,12 @@
 	device to be used as both a tty interface and as a synchronous 
 	controller is a project for Linux post the 2.4 release
   </para>
+  <para>
+	The support code handles most common card configurations and
+	supports running both Cisco HDLC and Synchronous PPP. With extra
+	glue the frame relay and X.25 protocols can also be used with this
+	driver.
+  </para>
   </chapter>
 
   <chapter id="Driver_Modes">
@@ -173,27 +179,35 @@
   <para>
 	If you wish to use the network interface facilities of the driver,
 	then you need to attach a network device to each channel that is
-	present and in use. In addition to use the generic HDLC
+	present and in use. In addition to use the SyncPPP and Cisco HDLC
 	you need to follow some additional plumbing rules. They may seem 
 	complex but a look at the example hostess_sv11 driver should
 	reassure you.
   </para>
   <para>
 	The network device used for each channel should be pointed to by
-	the netdevice field of each channel. The hdlc-&gt; priv field of the
+	the netdevice field of each channel. The dev-&gt; priv field of the
 	network device points to your private data - you will need to be
-	able to find your private data from this.
+	able to find your ppp device from this. In addition to use the
+	sync ppp layer the private data must start with a void * pointer
+	to the syncppp structures.
   </para>
   <para>
 	The way most drivers approach this particular problem is to
 	create a structure holding the Z8530 device definition and
-	put that into the private field of the network device. The
-	network device fields of the channels then point back to the
-	network devices.
+	put that and the syncppp pointer into the private field of
+	the network device. The network device fields of the channels
+	then point back to the network devices. The ppp_device can also
+	be put in the private structure conveniently.
   </para>
   <para>
-	If you wish to use the generic HDLC then you need to register
-	the HDLC device.
+	If you wish to use the synchronous ppp then you need to attach
+	the syncppp layer to the network device. You should do this before
+	you register the network device. The
+	<function>sppp_attach</function> requires that the first void *
+	pointer in your private data is pointing to an empty struct
+	ppp_device. The function fills in the initial data for the
+	ppp/hdlc layer.
   </para>
   <para>
 	Before you register your network device you will also need to
@@ -300,10 +314,10 @@
 	buffer in sk_buff format and queues it for transmission. The
 	caller must provide the entire packet with the exception of the
 	bitstuffing and CRC. This is normally done by the caller via
-	the generic HDLC interface layer. It returns 0 if the buffer has been
-	queued and non zero values for queue full. If the function accepts
-	the buffer it becomes property of the Z8530 layer and the caller
-	should not free it.
+	the syncppp interface layer. It returns 0 if the buffer has been 
+        queued and non zero values  for queue full. If the function accepts 
+	the buffer it becomes property of the Z8530 layer and the caller 
+	should not free it. 
   </para>
   <para>
 	The function <function>z8530_get_stats</function> returns a pointer

trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt

@@ -13,21 +13,6 @@ Introduction
   data-sheet/users manual to find out the complete list.
 
 
-GPIOLIB
--------
-
-  With the event of the GPIOLIB in drivers/gpio, support for some
-  of the GPIO functions such as reading and writing a pin will
-  be removed in favour of this common access method.
-
-  Once all the extant drivers have been converted, the functions
-  listed below will be removed (they may be marked as __deprecated
-  in the near future).
-
-  - s3c2410_gpio_getpin
-  - s3c2410_gpio_setpin
-
-
 Headers
 -------
 

trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt

@@ -8,10 +8,9 @@ Introduction
 
   The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
   by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
-  S3C2412, S3C2413, S3C2440, S3C2442 and S3C2443 devices are supported.
-
-  Support for the S3C2400 and S3C24A0 series are in progress.
+  S3C2412, S3C2413, S3C2440 and S3C2442 devices are supported.
 
+  Support for the S3C2400 series is in progress.
 
 Configuration
 -------------
@@ -39,22 +38,6 @@ Layout
   Register, kernel and platform data definitions are held in the
   arch/arm/mach-s3c2410 directory./include/mach
 
-arch/arm/plat-s3c24xx:
-
-  Files in here are either common to all the s3c24xx family,
-  or are common to only some of them with names to indicate this
-  status. The files that are not common to all are generally named
-  with the initial cpu they support in the series to ensure a short
-  name without any possibility of confusion with newer devices.
-
-  As an example, initially s3c244x would cover s3c2440 and s3c2442, but
-  with the s3c2443 which does not share many of the same drivers in
-  this directory, the name becomes invalid. We stick to s3c2440-<x>
-  to indicate a driver that is s3c2440 and s3c2442 compatible.
-
-  This does mean that to find the status of any given SoC, a number
-  of directories may need to be searched.
-
 
 Machines
 --------
@@ -176,17 +159,6 @@ NAND
   For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt
 
 
-SD/MMC
-------
-
-  The SD/MMC hardware pre S3C2443 is supported in the current
-  kernel, the driver is drivers/mmc/host/s3cmci.c and supports
-  1 and 4 bit SD or MMC cards.
-
-  The SDIO behaviour of this driver has not been fully tested. There is no
-  current support for hardware SDIO interrupts.
-
-
 Serial
 ------
 
@@ -206,9 +178,6 @@ GPIO
   The core contains support for manipulating the GPIO, see the
   documentation in GPIO.txt in the same directory as this file.
 
-  Newer kernels carry GPIOLIB, and support is being moved towards
-  this with some of the older support in line to be removed.
-
 
 Clock Management
 ----------------

trunk/Documentation/cciss.txt

@@ -112,18 +112,27 @@ Hot plug support for SCSI tape drives
 
 Hot plugging of SCSI tape drives is supported, with some caveats.
 The cciss driver must be informed that changes to the SCSI bus
-have been made.  This may be done via the /proc filesystem.
-For example:
+have been made, in addition to and prior to informing the SCSI 
+mid layer.  This may be done via the /proc filesystem.  For example:
 
 	echo "rescan" > /proc/scsi/cciss0/1
 
-This causes the driver to query the adapter about changes to the
-physical SCSI buses and/or fibre channel arbitrated loop and the
+This causes the adapter to query the adapter about changes to the 
+physical SCSI buses and/or fibre channel arbitrated loop and the 
 driver to make note of any new or removed sequential access devices
 or medium changers.  The driver will output messages indicating what 
 devices have been added or removed and the controller, bus, target and 
-lun used to address the device.  It then notifies the SCSI mid layer
-of these changes.
+lun used to address the device.  Once this is done, the SCSI mid layer 
+can be informed of changes to the virtual SCSI bus which the driver 
+presents to it in the usual way. For example: 
+
+	echo scsi add-single-device 3 2 1 0 > /proc/scsi/scsi
+
+to add a device on controller 3, bus 2, target 1, lun 0.   Note that
+the driver makes an effort to preserve the devices positions
+in the virtual SCSI bus, so if you are only moving tape drives 
+around on the same adapter and not adding or removing tape drives 
+from the adapter, informing the SCSI mid layer may not be necessary.
 
 Note that the naming convention of the /proc filesystem entries 
 contains a number in addition to the driver name.  (E.g. "cciss0" 

trunk/Documentation/hwmon/dme1737

@@ -10,10 +10,6 @@ Supported chips:
     Prefix: 'sch311x'
     Addresses scanned: none, address read from Super-I/O config space
     Datasheet: http://www.nuhorizons.com/FeaturedProducts/Volume1/SMSC/311x.pdf
-  * SMSC SCH5027
-    Prefix: 'sch5027'
-    Addresses scanned: I2C 0x2c, 0x2d, 0x2e
-    Datasheet: Provided by SMSC upon request and under NDA
 
 Authors:
     Juerg Haefliger <juergh@gmail.com>
@@ -31,31 +27,33 @@ Module Parameters
 			following boards:
 			- VIA EPIA SN18000
 
+Note that there is no need to use this parameter if the driver loads without
+complaining. The driver will say so if it is necessary.
+
 
 Description
 -----------
 
 This driver implements support for the hardware monitoring capabilities of the
-SMSC DME1737 and Asus A8000 (which are the same), SMSC SCH5027, and SMSC
-SCH311x Super-I/O chips. These chips feature monitoring of 3 temp sensors
-temp[1-3] (2 remote diodes and 1 internal), 7 voltages in[0-6] (6 external and
-1 internal) and up to 6 fan speeds fan[1-6]. Additionally, the chips implement
-up to 5 PWM outputs pwm[1-3,5-6] for controlling fan speeds both manually and
+SMSC DME1737 and Asus A8000 (which are the same) and SMSC SCH311x Super-I/O
+chips. These chips feature monitoring of 3 temp sensors temp[1-3] (2 remote
+diodes and 1 internal), 7 voltages in[0-6] (6 external and 1 internal) and up
+to 6 fan speeds fan[1-6]. Additionally, the chips implement up to 5 PWM
+outputs pwm[1-3,5-6] for controlling fan speeds both manually and
 automatically.
 
-For the DME1737, A8000 and SCH5027, fan[1-2] and pwm[1-2] are always present.
-Fan[3-6] and pwm[3,5-6] are optional features and their availability depends on
-the configuration of the chip. The driver will detect which features are
-present during initialization and create the sysfs attributes accordingly.
+For the DME1737 and A8000, fan[1-2] and pwm[1-2] are always present. Fan[3-6]
+and pwm[3,5-6] are optional features and their availability depends on the
+configuration of the chip. The driver will detect which features are present
+during initialization and create the sysfs attributes accordingly.
 
 For the SCH311x, fan[1-3] and pwm[1-3] are always present and fan[4-6] and
 pwm[5-6] don't exist.
 
-The hardware monitoring features of the DME1737, A8000, and SCH5027 are only
-accessible via SMBus, while the SCH311x only provides access via the ISA bus.
-The driver will therefore register itself as an I2C client driver if it detects
-a DME1737, A8000, or SCH5027 and as a platform driver if it detects a SCH311x
-chip.
+The hardware monitoring features of the DME1737 and A8000 are only accessible
+via SMBus, while the SCH311x only provides access via the ISA bus. The driver
+will therefore register itself as an I2C client driver if it detects a DME1737
+or A8000 and as a platform driver if it detects a SCH311x chip.
 
 
 Voltage Monitoring
@@ -66,7 +64,6 @@ scaling resistors. The values returned by the driver therefore reflect true
 millivolts and don't need scaling. The voltage inputs are mapped as follows
 (the last column indicates the input ranges):
 
-DME1737, A8000:
 	in0: +5VTR	(+5V standby)		0V - 6.64V
 	in1: Vccp	(processor core)	0V - 3V
 	in2: VCC	(internal +3.3V)	0V - 4.38V
@@ -75,24 +72,6 @@ DME1737, A8000:
 	in5: VTR	(+3.3V standby)		0V - 4.38V
 	in6: Vbat	(+3.0V)			0V - 4.38V
 
-SCH311x:
-	in0: +2.5V				0V - 6.64V
-	in1: Vccp	(processor core)	0V - 2V
-	in2: VCC	(internal +3.3V)	0V - 4.38V
-	in3: +5V				0V - 6.64V
-	in4: +12V				0V - 16V
-	in5: VTR	(+3.3V standby)		0V - 4.38V
-	in6: Vbat	(+3.0V)			0V - 4.38V
-
-SCH5027:
-	in0: +5VTR	(+5V standby)		0V - 6.64V
-	in1: Vccp	(processor core)	0V - 3V
-	in2: VCC	(internal +3.3V)	0V - 4.38V
-	in3: V2_IN				0V - 1.5V
-	in4: V1_IN				0V - 1.5V
-	in5: VTR	(+3.3V standby)		0V - 4.38V
-	in6: Vbat	(+3.0V)			0V - 4.38V
-
 Each voltage input has associated min and max limits which trigger an alarm
 when crossed.
 

trunk/Documentation/hwmon/it87

@@ -6,14 +6,12 @@ Supported chips:
     Prefix: 'it87'
     Addresses scanned: from Super I/O config space (8 I/O ports)
     Datasheet: Publicly available at the ITE website
-               http://www.ite.com.tw/product_info/file/pc/IT8705F_V.0.4.1.pdf
+               http://www.ite.com.tw/
   * IT8712F
     Prefix: 'it8712'
     Addresses scanned: from Super I/O config space (8 I/O ports)
     Datasheet: Publicly available at the ITE website
-               http://www.ite.com.tw/product_info/file/pc/IT8712F_V0.9.1.pdf
-               http://www.ite.com.tw/product_info/file/pc/Errata%20V0.1%20for%20IT8712F%20V0.9.1.pdf
-               http://www.ite.com.tw/product_info/file/pc/IT8712F_V0.9.3.pdf
+               http://www.ite.com.tw/
   * IT8716F/IT8726F
     Prefix: 'it8716'
     Addresses scanned: from Super I/O config space (8 I/O ports)
@@ -92,13 +90,14 @@ upper VID bits share their pins with voltage inputs (in5 and in6) so you
 can't have both on a given board.
 
 The IT8716F, IT8718F and later IT8712F revisions have support for
-2 additional fans. The additional fans are supported by the driver.
+2 additional fans. They are supported by the driver for the IT8716F and
+IT8718F but not for the IT8712F
 
 The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional
 16-bit tachometer counters for fans 1 to 3. This is better (no more fan
 clock divider mess) but not compatible with the older chips and
-revisions. The 16-bit tachometer mode is enabled by the driver when one
-of the above chips is detected.
+revisions. For now, the driver only uses the 16-bit mode on the
+IT8716F and IT8718F.
 
 The IT8726F is just bit enhanced IT8716F with additional hardware
 for AMD power sequencing. Therefore the chip will appear as IT8716F

trunk/Documentation/hwmon/w83627hf

@@ -40,6 +40,10 @@ Module Parameters
   (default is 1)
   Use 'init=0' to bypass initializing the chip.
   Try this if your computer crashes when you load the module.
+* reset: int
+  (default is 0)
+  The driver used to reset the chip on load, but does no more. Use
+  'reset=1' to restore the old behavior. Report if you need to do this.
 
 Description
 -----------

trunk/Documentation/hwmon/w83791d

@@ -22,7 +22,6 @@ Credits:
 
 Additional contributors:
     Sven Anders <anders@anduras.de>
-    Marc Hulsman <m.hulsman@tudelft.nl>
 
 Module Parameters
 -----------------
@@ -68,8 +67,9 @@ on until the temperature falls below the Hysteresis value.
 
 Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
 triggered if the rotation speed has dropped below a programmable limit. Fan
-readings can be divided by a programmable divider (1, 2, 4, 8, 16,
-32, 64 or 128 for all fans) to give the readings more range or accuracy.
+readings can be divided by a programmable divider (1, 2, 4, 8 for fan 1/2/3
+and 1, 2, 4, 8, 16, 32, 64 or 128 for fan 4/5) to give the readings more
+range or accuracy.
 
 Voltage sensors (also known as IN sensors) report their values in millivolts.
 An alarm is triggered if the voltage has crossed a programmable minimum

trunk/Documentation/video4linux/gspca.txt

@@ -226,7 +226,6 @@ sonixj		0c45:6130	Sonix Pccam
 sonixj		0c45:6138	Sn9c120 Mo4000
 sonixj		0c45:613b	Surfer SN-206
 sonixj		0c45:613c	Sonix Pccam168
-sonixj		0c45:6143	Sonix Pccam168
 sunplus		0d64:0303	Sunplus FashionCam DXG
 etoms		102c:6151	Qcam Sangha CIF
 etoms		102c:6251	Qcam xxxxxx VGA