---

yaml
---
r: 108132
b: refs/heads/master
c: e2205a1
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 13fa00a8780885edcdf0bc53b81e5d0fec71119a
+refs/heads/master: e2205a156f4dd727097f7f492bf03aa8920b0071

trunk/Documentation/00-INDEX

@@ -89,8 +89,6 @@ cciss.txt
 	- info, major/minor #'s for Compaq's SMART Array Controllers.
 cdrom/
 	- directory with information on the CD-ROM drivers that Linux has.
-cli-sti-removal.txt
-	- cli()/sti() removal guide.
 computone.txt
 	- info on Computone Intelliport II/Plus Multiport Serial Driver.
 connector/

trunk/Documentation/DocBook/s390-drivers.tmpl

@@ -100,7 +100,7 @@
       the hardware structures represented here, please consult the Principles
       of Operation.
     </para>
-!Iinclude/asm-s390/cio.h
+!Iarch/s390/include/asm/cio.h
     </sect1>
     <sect1 id="ccwdev">
      <title>ccw devices</title>
@@ -114,7 +114,7 @@
       ccw device structure. Device drivers must not bypass those functions
       or strange side effects may happen.
     </para>
-!Iinclude/asm-s390/ccwdev.h
+!Iarch/s390/include/asm/ccwdev.h
 !Edrivers/s390/cio/device.c
 !Edrivers/s390/cio/device_ops.c
     </sect1>
@@ -125,7 +125,7 @@
 	measurement data which is made available by the channel subsystem
 	for each channel attached device.
   </para>
-!Iinclude/asm-s390/cmb.h
+!Iarch/s390/include/asm/cmb.h
 !Edrivers/s390/cio/cmf.c
     </sect1>
   </chapter>
@@ -142,7 +142,7 @@
   </para>
    <sect1 id="ccwgroupdevices">
     <title>ccw group devices</title>
-!Iinclude/asm-s390/ccwgroup.h
+!Iarch/s390/include/asm/ccwgroup.h
 !Edrivers/s390/cio/ccwgroup.c
    </sect1>
   </chapter>

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/videodev.c
+!Edrivers/media/video/v4l2-dev.c
   </chapter>
 
 </book>

trunk/Documentation/DocBook/z8530book.tmpl

@@ -69,12 +69,6 @@
 	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">
@@ -179,35 +173,27 @@
   <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 SyncPPP and Cisco HDLC
+	present and in use. In addition to use the generic 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 dev-&gt; priv field of the
+	the netdevice field of each channel. The hdlc-&gt; priv field of the
 	network device points to your private data - you will need to be
-	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.
+	able to find your private data from this.
   </para>
   <para>
 	The way most drivers approach this particular problem is to
 	create a structure holding the Z8530 device definition and
-	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.
+	put that into the private field of the network device. The
+	network device fields of the channels then point back to the
+	network devices.
   </para>
   <para>
-	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.
+	If you wish to use the generic HDLC then you need to register
+	the HDLC device.
   </para>
   <para>
 	Before you register your network device you will also need to
@@ -314,10 +300,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 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. 
+	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.
   </para>
   <para>
 	The function <function>z8530_get_stats</function> returns a pointer

trunk/Documentation/arm/IXP4xx

@@ -32,7 +32,7 @@ Linux currently supports the following features on the IXP4xx chips:
 - Flash access (MTD/JFFS)
 - I2C through GPIO on IXP42x
 - GPIO for input/output/interrupts 
-  See include/asm-arm/arch-ixp4xx/platform.h for access functions.
+  See arch/arm/mach-ixp4xx/include/mach/platform.h for access functions.
 - Timers (watchdog, OS)
 
 The following components of the chips are not supported by Linux and

trunk/Documentation/arm/Interrupts

@@ -158,7 +158,7 @@ So, what's changed?
    be re-checked for pending events.  (see the Neponset IRQ handler for
    details).
 
-7. fixup_irq() is gone, as is include/asm-arm/arch-*/irq.h
+7. fixup_irq() is gone, as is arch/arm/mach-*/include/mach/irq.h
 
 Please note that this will not solve all problems - some of them are
 hardware based.  Mixing level-based and edge-based IRQs on the same

trunk/Documentation/arm/README

@@ -79,7 +79,7 @@ Machine/Platform support
   To this end, we now have arch/arm/mach-$(MACHINE) directories which are
   designed to house the non-driver files for a particular machine (eg, PCI,
   memory management, architecture definitions etc).  For all future
-  machines, there should be a corresponding include/asm-arm/arch-$(MACHINE)
+  machines, there should be a corresponding arch/arm/mach-$(MACHINE)/include/mach
   directory.
 
 
@@ -176,7 +176,7 @@ Kernel entry (head.S)
   class typically based around one or more system on a chip devices, and
   acts as a natural container around the actual implementations.  These
   classes are given directories - arch/arm/mach-<class> and
-  include/asm-arm/arch-<class> - which contain the source files to
+  arch/arm/mach-<class> - which contain the source files to/include/mach
   support the machine class.  This directories also contain any machine
   specific supporting code.
 

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

@@ -16,13 +16,13 @@ Introduction
 Headers
 -------
 
-  See include/asm-arm/arch-s3c2410/regs-gpio.h for the list
+  See arch/arm/mach-s3c2410/include/mach/regs-gpio.h for the list
   of GPIO pins, and the configuration values for them. This
-  is included by using #include <asm/arch/regs-gpio.h>
+  is included by using #include <mach/regs-gpio.h>
 
   The GPIO management functions are defined in the hardware
-  header include/asm-arm/arch-s3c2410/hardware.h which can be
-  included by #include <asm/arch/hardware.h>
+  header arch/arm/mach-s3c2410/include/mach/hardware.h which can be
+  included by #include <mach/hardware.h>
 
   A useful amount of documentation can be found in the hardware
   header on how the GPIO functions (and others) work.

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

@@ -36,7 +36,7 @@ Layout
   in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440
 
   Register, kernel and platform data definitions are held in the
-  include/asm-arm/arch-s3c2410 directory.
+  arch/arm/mach-s3c2410 directory./include/mach
 
 
 Machines

trunk/Documentation/arm/Samsung-S3C24XX/USB-Host.txt

@@ -49,7 +49,7 @@ Board Support
 Platform Data
 -------------
 
-  See linux/include/asm-arm/arch-s3c2410/usb-control.h for the
+  See arch/arm/mach-s3c2410/include/mach/usb-control.h for the
   descriptions of the platform device data. An implementation
   can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c .
 

trunk/Documentation/cciss.txt

@@ -112,27 +112,18 @@ 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, in addition to and prior to informing the SCSI 
-mid layer.  This may be done via the /proc filesystem.  For example:
+have been made.  This may be done via the /proc filesystem.
+For example:
 
 	echo "rescan" > /proc/scsi/cciss0/1
 
-This causes the adapter to query the adapter about changes to the 
-physical SCSI buses and/or fibre channel arbitrated loop and the 
+This causes the driver 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.  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.
+lun used to address the device.  It then notifies the SCSI mid layer
+of these changes.
 
 Note that the naming convention of the /proc filesystem entries 
 contains a number in addition to the driver name.  (E.g. "cciss0"