Merge with Linux 2.4.0.

7 files changed, 36 insertions, 35 deletions

diff --git a/Documentation/Changes b/Documentation/Changes
index 4c0881fff..91c60eee1 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -52,7 +52,7 @@ o  Gnu C                  2.91.66                 # gcc --version
 o  Gnu make               3.77                    # make --version
 o  binutils               2.9.1.0.25              # ld -v
 o  util-linux             2.10o                   # fdformat --version
-o  modutils               2.3.21                  # insmod -V
+o  modutils               2.4.0                   # insmod -V
 o  e2fsprogs              1.19                    # tune2fs --version
 o  pcmcia-cs              3.1.21                  # cardmgr -V
 o  PPP                    2.4.0                   # pppd --version
@@ -153,7 +153,7 @@ You'll probably want to upgrade.
 Ksymoops
 --------
 
-If the unthinkable happens and your kernel oopses, you'll need a 2.3
+If the unthinkable happens and your kernel oopses, you'll need a 2.4
 version of ksymoops to decode the report; see REPORTING-BUGS in the
 root of the Linux source for more information.
 
@@ -287,11 +287,11 @@ o  <ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/util-linux-2.10o.tar.g
 
 Ksymoops
 --------
-o  <ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.3>
+o  <ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4>
 
 Modutils
 --------
-o  <ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3/modutils-2.3.21.tar.bz2>
+o  <ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.4/>
 
 Mkinitrd
 --------
diff --git a/Documentation/Configure.help b/Documentation/Configure.help
index c7924bf50..05c0930ca 100644
--- a/Documentation/Configure.help
+++ b/Documentation/Configure.help
@@ -15537,14 +15537,15 @@ CONFIG_ARIADNE
   want). The module is called ariadne.o. If you want to compile it as
   a module, say M here and read Documentation/modules.txt.
 
-Ariadne II support
+Ariadne II and X-Surf support
 CONFIG_ARIADNE2
-  If you have a Village Tronic Ariadne II Ethernet adapter, say Y.
+  This driver is for the Village Tronic Ariadne II and the Individual
+  Computers X-Surf Ethernet cards. If you have such a card, say Y.
   Otherwise, say N.
 
   This driver is also available as a module ( = code which can be
-  inserted in and removed from the running kernel whenever you
-  want). The module is called ariadne2.o. If you want to compile it as
+  inserted in and removed from the running kernel whenever you want).
+  The module will be called ariadne2.o. If you want to compile it as
   a module, say M here and read Documentation/modules.txt.
 
 A2065 support
@@ -17019,12 +17020,6 @@ CONFIG_ITANIUM_ASTEP_SPECIFIC
   with an A-step CPU.  You have an A-step CPU if the "revision" field in
   /proc/cpuinfo is 0.
 
-Enable Itanium A1-step specific code
-CONFIG_ITANIUM_A1_SPECIFIC
-  Select this option to build a kernel for an Itanium prototype system
-  with an A1-step CPU.  If you don't know whether you have an A1-step CPU,
-  you probably don't and you can answer "no" here.
-
 Enable Itanium B-step specific code
 CONFIG_ITANIUM_BSTEP_SPECIFIC
   Select this option to build a kernel for an Itanium prototype system
diff --git a/Documentation/DocBook/mousedrivers.tmpl b/Documentation/DocBook/mousedrivers.tmpl
index 5d7be51e1..f349d1c4d 100644
--- a/Documentation/DocBook/mousedrivers.tmpl
+++ b/Documentation/DocBook/mousedrivers.tmpl
@@ -335,7 +335,7 @@ static int close_mouse(struct inode *inode, struct file *file)
   <para>
     We count off a user and provided that there are still other users need 
     take no further action. The last person closing the mouse causes us to 
-    free up the interrupt. This stopps interrupts from the mouse from using 
+    free up the interrupt. This stops interrupts from the mouse from using 
     our CPU time, and lets us use <function>MOD_DEC_USE_COUNT</function> so 
     that the mouse can now be unloaded.
   </para>
@@ -404,7 +404,7 @@ static void ourmouse_interrupt(int irq, void *dev_id, struct pt_regs *regs)
     play with them.
   </para>
   <para>
-    If a change has occured we also need to wake sleeping processes, so we 
+    If a change has occurred we also need to wake sleeping processes, so we 
     add a wakeup call and a <structname>wait_queue</structname> to use when 
     we wish to await a mouse event.
   </para>
@@ -426,7 +426,7 @@ static unsigned int mouse_poll(struct file *file, poll_table *wait)
   <para>
     This is fairly standard poll code. First we add the wait queue to the 
     list of queues we want to monitor for an event. Secondly we check if an 
-    event has occured. We only have one kind of event - the 
+    event has occurred. We only have one kind of event - the 
     <varname>mouse_event</varname> flag tells us that something happened. 
     We know that this something can only be mouse data. We return the flags 
     indicating input and normal reading will succeed.
@@ -476,7 +476,7 @@ static ssize_t mouse_read(struct file *file, char *buffer,
   </para>
   <para>
     Next we wait for an event to occur. The loop is fairly standard event
-    waiting in Linux. Having checked that the event has not yet occured, we
+    waiting in Linux. Having checked that the event has not yet occurred, we
     then check if an event is pending and if not we need to sleep. 
   </para>
   <para>
@@ -488,7 +488,7 @@ static ssize_t mouse_read(struct file *file, char *buffer,
     Next we sleep until the mouse or a signal awakens us. A signal will 
     awaken us as we have used <function>wakeup_interruptible</function>. 
     This is important as it means a user can kill processes waiting for 
-    the mouse - clearly a desireable property. If we are interrupted we 
+    the mouse - clearly a desirable property. If we are interrupted we 
     exit the call and the kernel will then process signals and maybe 
     restart the call again - from the beginning.
   </para>
diff --git a/Documentation/DocBook/videobook.tmpl b/Documentation/DocBook/videobook.tmpl
index 3798fc310..8da6f47e5 100644
--- a/Documentation/DocBook/videobook.tmpl
+++ b/Documentation/DocBook/videobook.tmpl
@@ -486,7 +486,7 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
   <para>
         We copy the user supplied structure into kernel memory so we can examine it. 
         If the user has selected a tuner other than zero we reject the request. If 
-        they wanted tuner 0 then, suprisingly enough, that is the current tuner already.
+        they wanted tuner 0 then, surprisingly enough, that is the current tuner already.
   </para>
   <para>
         The next two ioctls we need to provide are to get and set the frequency of
@@ -652,7 +652,7 @@ static int current_volume=0;
   </para>
   <para>
         The VIDIOCSAUDIO ioctl allows the user to set the audio parameters in the
-        video_audio stucture. The driver does its best to honour the request.
+        video_audio structure. The driver does its best to honour the request.
   </para>
   <programlisting>
 
@@ -812,7 +812,7 @@ void cleanup_module(void)
         Chroma keying is a technique used by cards to get around this. It is an old
         television mixing trick where you mark all the areas you wish to replace
         with a single clear colour that isn't used in the image - TV people use an
-        incredibly bright blue while computing people often use a paticularly
+        incredibly bright blue while computing people often use a particularly
         virulent purple. Bright blue occurs on the desktop. Anyone with virulent
         purple windows has another problem besides their TV overlay.
   </para>
@@ -1259,7 +1259,7 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
    </row><row>
         <entry>VIDEO_MODE_NTSC</><>NTSC (US) encoded Television</entry>
    </row><row>
-        <entry>VIDEO_MODE_SECAM</><>SECAM (French) Televison </entry>
+        <entry>VIDEO_MODE_SECAM</><>SECAM (French) Television </entry>
    </row><row>
         <entry>VIDEO_MODE_AUTO</><>Automatic switching, or format does not
                                 matter</entry>
@@ -1269,7 +1269,7 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
     </table>
     <para>
         The corresponding VIDIOCSCHAN ioctl allows a user to change channel and to
-        request the norm is changed - for exaple to switch between a PAL or an NTSC
+        request the norm is changed - for example to switch between a PAL or an NTSC
         format camera.
   </para>
   <programlisting>
@@ -1332,7 +1332,7 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
         it make a best effort attempt.
   </para>
   <para>
-        Our depth is 24, as this is in bits. We will be returing RGB24 format. This
+        Our depth is 24, as this is in bits. We will be returning RGB24 format. This
         has one byte of red, then one of green, then one of blue. This then repeats
         for every other pixel in the image. The other common formats the interface 
         defines are
diff --git a/Documentation/DocBook/z8530book.tmpl b/Documentation/DocBook/z8530book.tmpl
index 364c9126d..d9b6cd3af 100644
--- a/Documentation/DocBook/z8530book.tmpl
+++ b/Documentation/DocBook/z8530book.tmpl
@@ -57,7 +57,7 @@
       <title>Introduction</title>
   <para>
 	The Z85x30 family synchronous/asynchronous controller chips are
-	used on a larg number of cheap network interface cards. The
+	used on a large number of cheap network interface cards. The
 	kernel provides a core interface layer that is designed to make
 	it easy to provide WAN services using this chip.
   </para>
@@ -124,7 +124,7 @@
 	for allocating the interrupt line. The interrupt handler should be
 	set to <function>z8530_interrupt</function>. The device id should
 	be set to the z8530_dev structure pointer. Whether the interrupt can
-	be shared or not is board dependant, and up to you to initialise.
+	be shared or not is board dependent, and up to you to initialise.
   </para>
   <para>
 	The structure holds two channel structures. 
@@ -143,19 +143,19 @@
   </para>
   <para>
 	Repeat the same operation with the B channel if your chip has
-	both channels wired to something useful. This isnt always the
+	both channels wired to something useful. This isn't always the
 	case. If it is not wired then the I/O values do not matter, but
 	you must initialise chanB.dev.
   </para>
   <para>
 	If your board has DMA facilities then initialise the txdma and
 	rxdma fields for the relevant channels. You must also allocate the
-	ISA DMA channels and do any neccessary board level initialisation
+	ISA DMA channels and do any necessary board level initialisation
 	to configure them. The low level driver will do the Z8530 and
 	DMA controller programming but not board specific magic.
   </para>
   <para>
-	Having intialised the device you can then call
+	Having initialised the device you can then call
 	<function>z8530_init</function>. This will probe the chip and 
 	reset it into a known state. An identification sequence is then
 	run to identify the chip type. If the checks fail to pass the
@@ -167,7 +167,7 @@
   <para>
 	Once you have called z8530_init you can also make use of the utility
 	function <function>z8530_describe</function>. This provides a 
-	consistant reporting format for the Z8530 devices, and allows all
+	consistent reporting format for the Z8530 devices, and allows all
 	the drivers to provide consistent reporting.
   </para>
   </chapter>
@@ -191,7 +191,7 @@
 	to the syncppp structures.
   </para>
   <para>
-	The way most drivers approach this paticular problem is to
+	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
@@ -330,7 +330,7 @@
   <para>
 	The Z8530 driver is written to be portable. In DMA mode it makes
 	assumptions about the use of ISA DMA. These are probably warranted
-	in most cases as the Z85230 in paticular was designed to glue to PC
+	in most cases as the Z85230 in particular was designed to glue to PC
 	type machines. The PIO mode makes no real assumptions.
   </para>
   <para>
diff --git a/Documentation/IO-mapping.txt b/Documentation/IO-mapping.txt
index ad7c21c83..ddc817346 100644
--- a/Documentation/IO-mapping.txt
+++ b/Documentation/IO-mapping.txt
@@ -1,3 +1,9 @@
+[ NOTE: The virt_to_bus() and bus_to_virt() functions have been
+	superseded by the functionality provided by the PCI DMA
+	interface (see Documentation/DMA-mapping.txt).  They continue
+	to be documented below for historical purposes, but new code
+	must not use them. --davidm 00/12/12 ]
+
 [ This is a mail message in response to a query on IO mapping, thus the
   strange format for a "document" ]
 
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt
index a7b22b4c2..b7365d1e0 100644
--- a/Documentation/rtc.txt
+++ b/Documentation/rtc.txt
@@ -56,7 +56,7 @@ whatever) then the kernel will keep its hands off the RTC, allowing you
 exclusive access to the device for your applications.
 
 The alarm and/or interrupt frequency are programmed into the RTC via
-various ioctl(2) calls as listed in ./include/linux/mc146818rtc.h
+various ioctl(2) calls as listed in ./include/linux/rtc.h
 Rather than write 50 pages describing the ioctl() and so on, it is
 perhaps more useful to include a small test program that demonstrates
 how to use them, and demonstrates the features of the driver. This is
@@ -81,7 +81,7 @@ that will be using this driver.
  */
 
 #include <stdio.h>
-#include <linux/mc146818rtc.h>
+#include <linux/rtc.h>
 #include <sys/ioctl.h>
 #include <sys/time.h>
 #include <sys/types.h>