Merge with Linux 2.4.0-test12.

31 files changed, 1277 insertions, 268 deletions

diff --git a/Documentation/Changes b/Documentation/Changes
index abcb21c64..ed3bfb602 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -185,10 +185,10 @@ PCMCIA (PC Card) support is now partially implemented in the main
 kernel source.  Pay attention when you recompile your kernel ;-).
 Also, be sure to upgrade to the latest pcmcia-cs release.
 
-Intel P6 microcode
-------------------
+Intel IA32 microcode
+--------------------
 
-A driver has been added to allow updating of Intel P6 microcode,
+A driver has been added to allow updating of Intel IA32 microcode,
 accessible as both a devfs regular file and as a normal (misc)
 character device.  If you are not using devfs you may need to:
 
@@ -199,6 +199,13 @@ chmod 0644 /dev/cpu/microcode
 as root before you can use this.  You'll probably also want to
 get the user-space microcode_ctl utility to use with this.
 
+If you have compiled the driver as a module you may need to add
+the following line:
+
+alias char-major-10-184 microcode
+
+to your /etc/modules.conf file.
+
 Networking
 ==========
 
diff --git a/Documentation/Configure.help b/Documentation/Configure.help
index 76c55c43c..fefc32bb4 100644
--- a/Documentation/Configure.help
+++ b/Documentation/Configure.help
@@ -10303,6 +10303,17 @@ CONFIG_USB_SERIAL_VISOR
   The module will be called visor.o. If you want to compile it as a
   module, say M here and read Documentation/modules.txt.
 
+USB Belkin and Paracom Single Port Serial Driver
+CONFIG_USB_SERIAL_BELKIN
+  Say Y here if you want to use a Belkin USB Serial single port
+  adaptor (F5U103 is one of the model numbers) or the Peracom single
+  port USB to serial adapter.
+
+  This code is also available as a module ( = code which can be
+  inserted in and removed from the running kernel whenever you want).
+  The module will be called belkin_sa.o.  If you want to compile it as
+  a module, say M here and read Documentation/modules.txt.
+
 USB FTDI Single Port Serial Driver
 CONFIG_USB_SERIAL_FTDI_SIO
   Say Y here if you want to use a FTDI SIO single port USB to serial
@@ -10378,11 +10389,36 @@ CONFIG_USB_SERIAL_DIGI_ACCELEPORT
   parallel port on the USB 2 appears as a third serial port on Linux.
   The Digi Acceleport USB 8 is not yet supported by this driver.
 
+  This driver works under SMP with the usb-uhci driver.  It does not
+  work under SMP with the uhci driver.
+
   This code is also available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
   The module will be called digi_acceleport.o. If you want to compile 
   it as a module, say M here and read Documentation/modules.txt.
 
+USB Empeg empeg-car Mark I/II Driver
+CONFIG_USB_SERIAL_EMPEG
+  Say Y here if you want to connect to your Empeg empeg-car Mark I/II
+  mp3 player via USB.  The driver uses a single ttyUSB{0,1,2,...}
+  device node.  See Documentation/usb/usb-serial.txt for more
+  tidbits of information.
+
+  This code is also available as a module ( = code which can be
+  inserted in and removed from the running kernel whenever you want).
+  The module will be called empeg.o. If you want to compile it as a
+  module, say M here and read Documentation/modules.txt.
+
+USB MCT Single Port Serial Driver
+CONFIG_USB_SERIAL_MCT_U232
+  Say Y here if you want to use a USB Serial single port adapter from
+  Magic Control Technology Corp. (U232 is one of the model numbers).
+
+  This code is also available as a module ( = code which can be
+  inserted in and removed from the running kernel whenever you want).
+  The module will be called mct_u232.o.  If you want to compile it as
+  a module, say M here and read Documentation/modules.txt.
+
 USB Serial Converter verbose debug
 CONFIG_USB_SERIAL_DEBUG
   Say Y here if you want verbose debug messages from the USB Serial
@@ -13412,13 +13448,24 @@ CONFIG_MIXCOMWD
   module, say M here and read Documentation/modules.txt. Most people
   will say N.
 
-/dev/cpu/microcode - Intel P6 CPU microcode support
+Toshiba Laptop support
+CONFIG_TOSHIBA
+  If you intend to run this the kernel on a Toshiba portable say yes
+  here. This adds a driver to safely access the System Management
+  Mode of the CPU on Toshiba portables. The System Management Mode
+  is used to set the BIOS and power saving options on Toshiba portables.
+
+  For information on utilities to make use of this driver see the
+  Toshiba Linux utilities website at:
+  http://www.buzzard.org.uk/toshiba/
+
+/dev/cpu/microcode - Intel IA32 CPU microcode support
 CONFIG_MICROCODE
   If you say Y here and also to "/dev file system support" in the
   'File systems' section, you will be able to update the microcode on
-  Intel processors in the P6 family, e.g. Pentium Pro, Pentium II,
-  Pentium III, Xeon etc. You will obviously need the actual microcode
-  binary data itself which is not shipped with the Linux kernel.
+  Intel processors in the IA32 family, e.g. Pentium Pro, Pentium II,
+  Pentium III, Pentium 4, Xeon etc. You will obviously need the actual 
+  microcode binary data itself which is not shipped with the Linux kernel.
 
   For latest news and information on obtaining all the required
   ingredients for this driver, check:
@@ -13427,7 +13474,9 @@ CONFIG_MICROCODE
   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 will be called microcode.o. If you want to compile it as
-  a module, say M here and read Documentation/modules.txt.
+  a module, say M here and read Documentation/modules.txt. If you use
+  modprobe or kmod you may also want to add the line
+  'alias char-major-10-184 microcode' to your /etc/modules.conf file.
 
 /dev/cpu/*/msr - Model-specific register support
 CONFIG_X86_MSR
@@ -16288,12 +16337,6 @@ CONFIG_SA1100_LART
   (also known as the LART).  See http://www.lart.tudelft.nl/ for
   information on the LART.
 
-Include support for ThinClient
-CONFIG_SA1100_THINCLIENT
-  Say Y here if you are using an Applied Data Systems Intel(R)
-  StrongARM(R) SA-1100 based Thin Client SBC.  See
-  http://www.flatpanels.com/ for information on this system.
-
 Include support for GraphicsClient
 CONFIG_SA1100_GRAPHICSCLIENT
   Say Y here if you are using an Applied Data Systems Intel(R)
@@ -16328,6 +16371,27 @@ Support ARM920
 CONFIG_CPU_ARM920
   Say Y here if you wish to include support for the ARM920 processor.
 
+Support ARM610 processor
+CONFIG_CPU_ARM6
+  Say Y here if you wish to include support for the ARM610 processor.
+
+Support ARM710 processor
+CONFIG_CPU_ARM7
+  Say Y here if you wish to include support for the ARM710 processor.
+
+Support StrongARM(R) SA-110 processor
+CONFIG_CPU_SA110
+  Say Y here if you wish to include support for the Intel(R)
+  StrongARM(R) SA-110 processor.
+
+Support ARM720 processor
+CONFIG_CPU_ARM720
+  Say Y here if you wish to include support for the ARM720 processor.
+
+Support ARM920
+CONFIG_CPU_ARM920
+  Say Y here if you wish to include support for the ARM920 processor.
+
 Math emulation
 CONFIG_NWFPE
   Say Y to include the NWFPE floating point emulator in the kernel.
@@ -16451,6 +16515,17 @@ CONFIG_SERIAL_21285_CONSOLE
   If you have enabled the serial port on the 21285 footbridge you can
   make it the console by answering Y to this option.
 
+SA1100 serial port support
+CONFIG_SERIAL_SA1100
+  If you have a machine based on a SA1100/SA1110 StrongARM CPU you can
+  enable its onboard serial port by enabling this option.
+  Please read Documentation/arm/SA1100/serial_UART for further info.
+
+Console on SA1100 serial port
+CONFIG_SERIAL_SA1100_CONSOLE
+  If you have enabled the serial port on the SA1100/SA1110 StrongARM
+  CPU you can make it the console by answering Y to this option.
+
 L7200 serial port support
 CONFIG_SERIAL_L7200
   If you have a LinkUp Systems L7200 board you can enable its two
diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt
index 0ffccdee2..b59a97dd1 100644
--- a/Documentation/DMA-mapping.txt
+++ b/Documentation/DMA-mapping.txt
@@ -341,7 +341,7 @@ to use the pci_dma_sync_*() interfaces.
 			struct my_card_header *hp;
 
 			/* Examine the header to see if we wish
-			 * to except the data.  But synchronize
+			 * to accept the data.  But synchronize
 			 * the DMA transfer with the CPU first
 			 * so that we see updated contents.
 			 */
diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl
index 8d87787ad..47fbe077e 100644
--- a/Documentation/DocBook/kernel-hacking.tmpl
+++ b/Documentation/DocBook/kernel-hacking.tmpl
@@ -846,7 +846,7 @@ foo_open (...)
    first class of operations work on <type>atomic_t</type>
 
    <filename class=headerfile>include/asm/atomic.h</filename>; this
-   contains a signed integer (at least 32 bits long), and you must use
+   contains a signed integer (at least 24 bits long), and you must use
    these functions to manipulate or read atomic_t variables.
    <function>atomic_read()</function> and
    <function>atomic_set()</function> get and set the counter,
@@ -870,8 +870,8 @@ foo_open (...)
   </para>
 
   <para>
-   The second class of atomic operations is atomic bit operations,
-   defined in
+   The second class of atomic operations is atomic bit operations on a
+   <type>long</type>, defined in
 
    <filename class=headerfile>include/asm/bitops.h</filename>.  These
    operations generally take a pointer to the bit pattern, and a bit
@@ -887,9 +887,15 @@ foo_open (...)
   
   <para>
    It is possible to call these operations with bit indices greater
-   than 31.  The resulting behavior is strange on big-endian
+   than BITS_PER_LONG.  The resulting behavior is strange on big-endian
    platforms though so it is a good idea not to do this.
   </para>
+
+  <para>
+   Note that the order of bits depends on the architecture, and in
+   particular, the bitfield passed to these operations must be at
+   least as large as a <type>long</type>.
+  </para>
  </chapter>
 
  <chapter id="symbols">
diff --git a/Documentation/DocBook/videobook.tmpl b/Documentation/DocBook/videobook.tmpl
index 2174af671..3798fc310 100644
--- a/Documentation/DocBook/videobook.tmpl
+++ b/Documentation/DocBook/videobook.tmpl
@@ -66,7 +66,7 @@
         vertical blanking data interfaces are also provided.
   </para>
   </chapter>
-  <chapter>
+  <chapter id="radio">
         <title>Radio Devices</title>
   <para>
         There are a wide variety of radio interfaces available for PC's, and these
diff --git a/Documentation/README.DAC960 b/Documentation/README.DAC960
index 88f52364b..4c0832e79 100644
--- a/Documentation/README.DAC960
+++ b/Documentation/README.DAC960
@@ -1,11 +1,11 @@
    Linux Driver for Mylex DAC960/AcceleRAID/eXtremeRAID PCI RAID Controllers
 
-			Version 2.2.8 for Linux 2.2.16
-			Version 2.4.8 for Linux 2.4.0
+			Version 2.2.9 for Linux 2.2.17
+			Version 2.4.9 for Linux 2.4.0
 
 			      PRODUCTION RELEASE
 
-				19 August 2000
+			       7 September 2000
 
 			       Leonard N. Zubkoff
 			       Dandelion Digital
@@ -203,13 +203,13 @@ ftp://ftp.mylex.com/pub/dac960/diskcomp.html.
 
 			      DRIVER INSTALLATION
 
-This distribution was prepared for Linux kernel version 2.2.16 or 2.4.0.
+This distribution was prepared for Linux kernel version 2.2.17 or 2.4.0.
 
 To install the DAC960 RAID driver, you may use the following commands,
 replacing "/usr/src" with wherever you keep your Linux kernel source tree:
 
   cd /usr/src
-  tar -xvzf DAC960-2.2.8.tar.gz (or DAC960-2.4.8.tar.gz)
+  tar -xvzf DAC960-2.2.9.tar.gz (or DAC960-2.4.9.tar.gz)
   mv README.DAC960 linux/Documentation
   mv DAC960.[ch] linux/drivers/block
   patch -p0 < DAC960.patch (if DAC960.patch is included)
diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers
index 29c597385..92a169ac2 100644
--- a/Documentation/SubmittingDrivers
+++ b/Documentation/SubmittingDrivers
@@ -6,13 +6,17 @@ Linux 2.2 and 2.4test kernel trees. Note that if you are interested in video
 card drivers you should probably talk to XFree86 (http://wwww.xfree86.org) 
 instead.
 
+Also read the Documentation/SubmittingPatches document.
+
+
 Allocating Device Numbers
 -------------------------
 
-Major and minor numbers for devices are allocated by the Linux assigned name
-and number authority (currently better known as H Peter Anvin). The
-site is http://www.lanana.org/. This also deals with allocating numbers for
-devices that are not going to be submitted to the mainstream kernel.
+Major and minor numbers for block and character devices are allocated
+by the Linux assigned name and number authority (currently better
+known as H Peter Anvin). The site is http://www.lanana.org/. This
+also deals with allocating numbers for devices that are not going to
+be submitted to the mainstream kernel.
 
 If you don't use assigned numbers then when you device is submitted it will
 get given an assigned number even if that is different from values you may
@@ -76,7 +80,8 @@ Control:	In general if there is active maintainance of a driver by
 		the author then patches will be redirected to them unless 
 		they are totally obvious and without need of checking.
 		If you want to be the contact and update point for the
-		driver it is a good idea to state this in the comments.
+		driver it is a good idea to state this in the comments,
+		and include an entry in MAINTAINERS for your driver.
 
 What Criteria Do Not Determine Acceptance
 -----------------------------------------
@@ -97,7 +102,8 @@ Resources
 ---------
 
 Linux kernel master tree:
-	ftp.kernel.org:/pub/linux/kernel/...
+	ftp.??.kernel.org:/pub/linux/kernel/...
+	?? == your country code, such as "us", "uk", "fr", etc.
 
 Linux kernel mailing list:		
 	linux-kernel@vger.kernel.org
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
new file mode 100644
index 000000000..4f48032c7
--- /dev/null
+++ b/Documentation/SubmittingPatches
@@ -0,0 +1,286 @@
+
+	How to Get Your Change Into the Linux Kernel
+		or
+	Care And Operation Of Your Linus Torvalds
+
+
+
+For a person or company who wishes to submit a change to the Linux
+kernel, the process can sometimes be daunting if you're not familiar
+with "the system."  This text is a collection of suggestions which
+can greatly increase the chances of your change being accepted.
+
+If you are submitting a driver, also read Documentation/SubmittingDrivers.
+
+
+
+--------------------------------------------
+SECTION 1 - CREATING AND SENDING YOUR CHANGE
+--------------------------------------------
+
+
+
+1) "diff -u"
+------------
+
+Use "diff -u" or "diff -urN" to create patches.
+
+All changes to the Linux kernel occur in the form of patches, as
+generated by diff(1).  When creating your patch, make sure to create it
+in "unified diff" format, as supplied by the '-u' argument to diff(1).
+Patches should be based in the root kernel source directory, not in
+any lower subdirectory.
+
+To create a patch for a single file, it is often sufficient to do:
+
+	SRCTREE= /devel/linux-2.4
+	MYFILE=  drivers/net/mydriver.c
+
+	cd $SRCTREE
+	cp $MYFILE $MYFILE.orig
+	vi $MYFILE	# make your change
+	diff -u $MYFILE.orig $MYFILE > /tmp/patch
+
+To create a patch for multiple files, you should unpack a "vanilla",
+or unmodified kernel source tree, and generate a diff against your
+own source tree.  For example:
+
+	MYSRC= /devel/linux-2.4
+
+	tar xvfz linux-2.4.0-test11.tar.gz
+	mv linux linux-vanilla
+	wget http://www.moses.uklinux.net/patches/dontdiff
+	diff -urN -X dontdiff linux-vanilla $MYSRC > /tmp/patch
+	rm -f dontdiff
+
+"dontdiff" is a list of files which are generated by the kernel during
+the build process, and should be ignored in any diff(1)-generated
+patch.  dontdiff is maintained by Tigran Aivazian <tigran@veritas.com>
+
+Make sure your patch does not include any extra files which do not
+belong in a patch submission.  Make sure to review your patch -after-
+generated it with diff(1), to ensure accuracy.
+
+
+2) Describe your changes.
+
+Describe the technical detail of the change(s) your patch includes.
+
+Be as specific as possible.  The WORST descriptions possible include
+things like "update driver X", "bug fix for driver X", or "this patch
+includes updates for subsystem X.  Please apply."
+
+If your description starts to get long, that's a sign that you probably
+need to split up your patch.  See #3, next.
+
+
+
+3) Separate your changes.
+
+Separate each logical change into its own patch.
+
+For example, if your changes include both bug fixes and performance
+enhancements for a single driver, separate those changes into two
+or more patches.  If your changes include an API update, and a new
+driver which uses that new API, separate those into two patches.
+
+On the other hand, if you make a single change to numerous files,
+group those changes into a single patch.  Thus a single logical change
+is contained within a single patch.
+
+If one patch depends on another patch in order for a change to be
+complete, that is OK.  Simply note "this patch depends on patch X"
+in your patch description.
+
+
+4) Select e-mail destination.
+
+Look through the MAINTAINERS file and the source code, and determine
+if your change applies to a specific subsystem of the kernel, with
+an assigned maintainer.  If so, e-mail that person.
+
+If no maintainer is listed, or the maintainer does not respond, send
+your patch to the primary Linux kernel developer's mailing list,
+linux-kernel@vger.kernel.org.  Most kernel developers monitor this
+e-mail list, and can comment on your changes.
+
+Linus Torvalds is the final arbiter of all changes accepted into the
+Linux kernel.  His e-mail address is torvalds@transmeta.com.  He gets
+a lot of e-mail, so typically you should do your best to -avoid- sending
+him e-mail.
+
+Patches which are bug fixes, are "obvious" changes, or similarly
+require little discussion should be sent or CC'd to Linus.  Patches
+which require discussion or do not have a clear advantage should
+usually be sent first to linux-kernel.  Only after the patch is
+discussed should the patch then be submitted to Linus.
+
+
+
+5) Select your CC (e-mail carbon copy) list.
+
+Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.
+
+Other kernel developers besides Linus need to be aware of your change,
+so that they may comment on it and offer code review and suggestions.
+linux-kernel is the primary Linux kernel developer mailing list.
+Other mailing lists are available for specific subsystems, such as
+USB, framebuffer devices, the VFS, the SCSI subsystem, etc.  See the
+MAINTAINERS file for a mailing list that relates specifically to
+your change.
+
+Even if the maintainer did not respond in step #4, make sure to ALWAYS
+copy the maintainer when you change their code.
+
+
+
+6) No MIME, no links, no compression, no attachments.  Just plain text.
+
+Linus and other kernel developers need to be able to read and comment
+on the changes you are submitting.  It is important for a kernel
+developer to be able to "quote" your changes, using standard e-mail
+tools, so that they may comment on specific portions of your code.
+
+For this reason, all patches should be submitting e-mail "inline".
+WARNING:  Be wary of your editor's word-wrap corrupting your patch,
+if you choose to cut-n-paste your patch.
+
+Do not attach the patch as a MIME attachment, compressed or not.
+Many popular e-mail applications will not always transmit a MIME
+attachment as plain text, making it impossible to comment on your
+code.  A MIME attachment also takes Linus a bit more time to process,
+decreasing the likelihood of your MIME-attached change being accepted.
+
+Exception:  If your mailer is mangling patches then someone may ask
+you to re-send them using MIME.
+
+
+
+7) E-mail size.
+
+When sending patches to Linus, always follow step #6.
+
+Large changes are not appropriate for mailing lists, and some
+maintainers.  If your patch, uncompressed, exceeds 40Kb in size,
+it is preferred that you store your patch on an Internet-accessible
+server, and provide instead a URL (link) pointing to your patch.
+
+
+
+8) Name your kernel version.
+
+It is important to note, either in the subject line or in the patch
+description, the kernel version to which this patch applies.
+
+If the patch does not apply cleanly to the latest kernel version,
+Linus will not apply it.
+
+
+
+9) Don't get discouraged.  Re-submit.
+
+After you have submitted your change, be patient and wait.  If Linus
+likes your change and applies it, it will appear in the next version
+of the kernel that he releases.
+
+However, if your change doesn't appear in the next version of the
+kernel, there could be any number of reasons.  It's YOUR job to
+narrow down those reasons, correct what was wrong, and submit your
+updated change.
+
+It is quite common for Linus to "drop" your patch without comment.
+That's the nature of the system.  If he drops your patch, it could be
+due to
+* Your patch did not apply cleanly to the latest kernel version
+* Your patch was not sufficiently discussed on linux-kernel.
+* A style issue (see section 2),
+* An e-mail formatting issue (re-read this section)
+* A technical problem with your change
+* He gets tons of e-mail, and yours got lost in the shuffle
+* You are being annoying (See Figure 1)
+
+When in doubt, solicit comments on linux-kernel mailing list.
+
+
+
+10) Include PATCH in the subject
+
+Due to high e-mail traffic to Linus, and to linux-kernel, it is common
+convention to prefix your subject line with [PATCH].  This lets Linus
+and other kernel developers more easily distinguish patches from other
+e-mail discussions.
+
+
+
+-----------------------------------
+SECTION 2 - HINTS, TIPS, AND TRICKS
+-----------------------------------
+
+This section lists many of the common "rules" associated with code
+submitted to the kernel.  There are always exceptions... but you must
+have a really good reason for doing so.  You could probably call this
+section Linus Computer Science 101.
+
+
+
+1) Read Documentation/CodingStyle
+
+Nuff said.  If your code deviates too much from this, it is likely
+to be rejected without further review, and without comment.
+
+
+
+2) #ifdefs are ugly
+
+Code cluttered with ifdefs is difficult to read and maintain.  Don't do
+it.  Instead, put your ifdefs in a header, and conditionally define
+'static inline' functions, or macros, which are used in the code.
+Let the compiler optimize away the "no-op" case.
+
+Simple example, of poor code:
+
+	dev = init_etherdev (NULL, 0);
+	if (!dev)
+		return -ENODEV;
+	#ifdef CONFIG_NET_FUNKINESS
+		init_funky_net(dev);
+	#endif
+
+Cleaned-up example:
+
+(in header)
+	#ifndef CONFIG_NET_FUNKINESS
+	static inline void init_funky_net (struct net_device *d) {}
+	#endif
+
+(in the code itself)
+	dev = init_etherdev (NULL, 0);
+	if (!dev)
+		return -ENODEV;
+	init_funky_net(dev);
+
+
+
+3) 'static inline' is better than a macro
+
+Static inline functions are greatly preferred over macros.
+They provide type safety, have no length limitations, no formatting
+limitations, and under gcc they are as cheap as macros.
+
+Macros should only be used for cases where a static inline is clearly
+suboptimal [there a few, isolated cases of this in fast paths],
+or where it is impossible to use a static inline function [such as
+string-izing].
+
+'static inline' is preferred over 'static __inline__', 'extern inline',
+and 'extern __inline__'.
+
+
+
+4) Don't over-design.
+
+Don't try to anticipate nebulous future cases which may or may not
+be useful:  "Make it as simple as you can, and no simpler"
+
+
+
diff --git a/Documentation/arm/README b/Documentation/arm/README
index 96bdfe3e2..8514dac03 100644
--- a/Documentation/arm/README
+++ b/Documentation/arm/README
@@ -157,7 +157,8 @@ Kernel entry (head-armv.S)
   the mail a subject of 'Register new architecture':
 
     Name: <name of your architecture>
-    ARCHDIR: <name of include/asm-arm/arch-* directory>
+    ArchDir: <name of include/asm-arm/arch-* directory>
+    Type: <MACH_TYPE_* macro name>
     Description:
     <description of your architecture>
 
diff --git a/Documentation/arm/SA1100/ThinClient b/Documentation/arm/SA1100/GraphicsClient
index d5d7625fd..01f3f050a 100644
--- a/Documentation/arm/SA1100/ThinClient
+++ b/Documentation/arm/SA1100/GraphicsClient
@@ -1,24 +1,21 @@
-Thin Client / Single Board Computer
-
-The Thin Client, a low cost high power single board computer, has been
-designed to provide intuitive graphical displays in embedded systems.
+ADS GraphicsClient/ThinClient Single Board Computer
 
 For more details, contact Applied Data Systems or see
 http://www.flatpanels.com/products.html
 
-Current Linux support for this product has been provided by Nicolas Pitre
-<nico@cam.org>.
+The original Linux support for this product has been provided by 
+Nicolas Pitre <nico@cam.org>.
 
 It's currently possible to mount a root filesystem via NFS providing a
 complete Linux environment.  Otherwise a ramdisk image may be used.  Use
-'make thinclient_config' before any 'make config'.  This will set up
-defaults for ThinClient support.
+'make graphicsclient_config' before any 'make config'.  This will set up
+defaults for GraphicsClient/ThinClient support.
 
 The kernel zImage is linked to be loaded and executed at 0xc0200000.  
 Also the following registers should have the specified values upon entry:
 
 	r0 = 0
-	r1 = 24	(this is the ThinClient architecture number)
+	r1 = 29	(this is the GraphicsClient architecture number)
 
 Here is a tipical angel.opt option file if the kernel is loaded through
 the Angel Debug Monitor:
@@ -27,7 +24,7 @@ the Angel Debug Monitor:
 base 0xc0200000
 entry 0xc0200000
 r0 0x00000000
-r1 0x00000018
+r1 0x0000001d
 device /dev/ttyS1
 options "9600 8N1"
 baud 115200
@@ -41,7 +38,7 @@ uncommented) would be loaded with:
 
 	angelboot -f angelboot.opt zImage
 
-Here it is assumed that the ThinClient is connected to ttyS1 on your PC
+Here it is assumed that the board is connected to ttyS1 on your PC
 and that minicom is preconfigured with /dev/ttyS1, 9600 baud, 8N1, no flow
 control by default.
 
@@ -54,13 +51,13 @@ Supported peripherals:
 - on-board SMC 92C94 ethernet NIC
 - SA1100 serial port
 - flash memory access
+- pcmcia
 - possibly UCB1200 audio (not tested yet)
 
 To do:
 - touchscreen driver
 - 16bpp frame buffer support
 - extra (external) serial port driver
-- pcmcia
 - some console keyboard support (maybe IR?)
 - everything else!  :-)
 
diff --git a/Documentation/arm/SA1100/Pangolin b/Documentation/arm/SA1100/Pangolin
new file mode 100644
index 000000000..88cff5bf1
--- /dev/null
+++ b/Documentation/arm/SA1100/Pangolin
@@ -0,0 +1,25 @@
+Pangolin is a StrongARM 1110-based evaluation  platform produced
+by Dialogue Technoloy (http://www.dialogue.com.tw/).
+It has EISA slots for ease of configuration with SDRAM/Flash
+memory card, USB/Serial/Audio card, Compact Flash card,
+and TFT-LCD card.
+This platform is currently under development.
+
+To compile for Pangolin, you must issue the following commands:
+
+	make pangolin_config
+	make config
+	[accept all defaults]
+	make dep
+	make zImage
+
+Supported peripherals:
+- SA1110 serial port
+- flash memory access
+
+Testing:
+- pcmcia driver
+- sound driver
+
+To do:
+- MQ-200 driver
diff --git a/Documentation/arm/SA1100/serial_UART b/Documentation/arm/SA1100/serial_UART
new file mode 100644
index 000000000..3807dea19
--- /dev/null
+++ b/Documentation/arm/SA1100/serial_UART
@@ -0,0 +1,65 @@
+The SA1100 serial port finally had its major/minor numbers officially 
+assigned:
+
+> Date: Sun, 24 Sep 2000 21:40:27 -0700
+> From: H. Peter Anvin <hpa@transmeta.com>
+> To: Nicolas Pitre <nico@CAM.ORG>
+> Cc: Device List Maintainer <device@lanana.org>
+> Subject: Re: device
+> 
+> Okay.  Note that device numbers 204 and 205 are used for "low density
+> serial devices", so you will have a range of minors on those majors (the
+> tty device layer handles this just fine, so you don't have to worry about
+> doing anything special.)
+> 
+> So your assignments are:
+> 
+> 204 char        Low-density serial ports
+>                   5 = /dev/ttySA0               SA1100 builtin serial port 0
+>                   6 = /dev/ttySA1               SA1100 builtin serial port 1
+>                   7 = /dev/ttySA2               SA1100 builtin serial port 2
+> 
+> 205 char        Low-density serial ports (alternate device)
+>                   5 = /dev/cusa0                Callout device for ttySA0
+>                   6 = /dev/cusa1                Callout device for ttySA1
+>                   7 = /dev/cusa2                Callout device for ttySA2
+>
+
+So, if you're not using devfs, you must create those inodes in /dev
+on the root filesystem used by your SA1100-based device:
+
+	mknod ttySA0 c 204 5
+	mknod ttySA1 c 204 6
+	mknod ttySA2 c 204 7
+	mknod cusa0 c 205 5
+	mknod cusa1 c 205 6
+	mknod cusa2 c 205 7
+
+Note that the old incorrect use of /dev/ttyS0 in order to use the serial port 
+won't work anymore.  This device node is reserved to the conventionnal 16x50
+UART which may appear on devices like PCMCIA modem, etc.
+
+In addition to the creation of the appropriate device nodes above, you must
+ensure your user space applications make use of the correct device name.
+The classic example is the content of the /etc/inittab where you might have 
+a getty process started on ttyS0.  In this case you have two choices:
+
+1- replace occurences of ttyS0 with ttySA0, ttyS1 with ttySA1, etc.
+
+2- in the occurence of 'ttyS0', you may consider replacing it with 'console'.
+   as in "T0:12345:respawn:/sbin/getty -L console 9600 vt100"
+
+(don't forget to add 'ttySA0', 'console', or the appropriate tty name 
+ in /etc/securetty for root to be allowed to login as well.)
+
+The use of /dev/console has the advantage of being independent of the real
+serial device used.  The kernel automatically forward all operations on
+/dev/console to the apropriate serial device.  The nature of the console may
+also be modified with a kernel command line parameter (see
+Documentation/serial-console.txt for the details).  Of course, 
+/dev/console must have been created as a char device with major 5 minor 1.
+
+Using /dev/console is also compatible with older kernels that used /dev/ttyS0.
+Therefore it is handy for ramdisk images which are targetted for different
+StrongARM platforms and older kernels.
+
diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt
index 5201a2f54..f3ae78497 100644
--- a/Documentation/cachetlb.txt
+++ b/Documentation/cachetlb.txt
@@ -257,7 +257,7 @@ the proper points in time.
 
 Here is the new interface:
 
-  void copy_user_page(void *from, void *to, unsigned long address)
+  void copy_user_page(void *to, void *from, unsigned long address)
   void clear_user_page(void *to, unsigned long address)
 
 	These two routines store data in user anonymous or COW
diff --git a/Documentation/filesystems/devfs/README b/Documentation/filesystems/devfs/README
index 6febda525..0c6fde510 100644
--- a/Documentation/filesystems/devfs/README
+++ b/Documentation/filesystems/devfs/README
@@ -529,7 +529,7 @@ yielded code size reductions and simplifications.
 If you want to construct a minimal chroot() gaol, the following
 command should suffice:
 
-mount -t bind /dev/null /gaol/dev/null
+mount --bind /dev/null /gaol/dev/null
 
 
 Repeat for other device nodes you want to expose. Simple!
@@ -739,7 +739,7 @@ create the /dev-state directory
 add the following lines near the very beginning of your boot
 scripts:
 
-mount -t bind /dev /dev-state
+mount --bind /dev /dev-state
 mount -t devfs none /dev
 devfsd /dev
 
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 5dcf02cfe..ea8d32afb 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -3,8 +3,11 @@
 ------------------------------------------------------------------------------
 /proc/sys         Terrehon Bowden <terrehon@pacbell.net>        October 7 1999
                   Bodo Bauer <bb@ricochet.net>
+
+2.4.x update	  Jorge Nerin <comandante@zaralinux.com>      November 14 2000
 ------------------------------------------------------------------------------
-Version 1.2                                              Kernel version 2.2.12
+Version 1.3                                              Kernel version 2.2.12
+					      Kernel version 2.4.0-test11-pre4
 ------------------------------------------------------------------------------
 
 Table of Contents
@@ -42,17 +45,18 @@ Preface
 0.1 Introduction/Credits
 ------------------------
 
-This documentation  is  part  of a soon (or so we hope) to be released book on
-the SuSE  Linux  distribution.  As  there is no complete documentation for the
-/proc file  system and we've used many freely available sources to write these
-chapters, it  seems  only  fair  to give the work back to the Linux community.
-This work is based on the 2.2.* kernel version. I'm afraid it's still far from
-complete, but  we  hope  it will be useful. As far as we know, it is the first
-'all-in-one' document  about the /proc file system. It is focused on the Intel
-x86 hardware,  so if you are looking for PPC, ARM, SPARC, APX, etc., features,
-you probably  won't  find  what  you are looking for. It also only covers IPv4
-networking, not  IPv6  nor  other protocols - sorry. But additions and patches
-are welcome and will be added to this document if you mail them to Bodo.
+This documentation is  part of a soon (or  so we hope) to be  released book on
+the SuSE  Linux distribution. As  there is  no complete documentation  for the
+/proc file system and we've used  many freely available sources to write these
+chapters, it  seems only fair  to give the work  back to the  Linux community.
+This work is  based on the 2.2.*  kernel version and the  upcomming 2.4.*. I'm
+afraid it's still far from complete, but we  hope it will be useful. As far as
+we know, it is the first 'all-in-one' document about the /proc file system. It
+is focused  on the Intel  x86 hardware,  so if you  are looking for  PPC, ARM,
+SPARC, APX, etc., features, you probably  won't find what you are looking for.
+It also only covers IPv4 networking, not IPv6 nor other protocols - sorry. But
+additions and patches  are welcome and will  be added to this  document if you
+mail them to Bodo.
 
 We'd like  to  thank Alan Cox, Rik van Riel, and Alexey Kuznetsov and a lot of
 other people for help compiling this documentation. We'd also like to extend a
@@ -65,9 +69,13 @@ If you  have  any comments, corrections or additions, please don't hesitate to
 contact Bodo  Bauer  at  bb@ricochet.net.  We'll  be happy to add them to this
 document.
 
-The latest  version  of  this  document  is  available  online  at
+The   latest   version    of   this   document   is    available   online   at
 http://skaro.nightcrawler.com/~bb/Docs/Proc as HTML version.
 
+If  the above  direction does  not works  for you,  ypu could  try the  kernel
+mailing  list  at  linux-kernel@vger.kernel.org  and/or try  to  reach  me  at
+comandante@zaralinux.com.
+
 0.2 Legal Stuff
 ---------------
 
@@ -92,7 +100,7 @@ In This Chapter
 
 The proc  file  system acts as an interface to internal data structures in the
 kernel. It  can  be  used to obtain information about the system and to change
-certain kernel parameters at runtime.
+certain kernel parameters at runtime (sysctl).
 
 First, we'll  take  a  look  at the read-only parts of /proc. In Chapter 2, we
 show you how you can use /proc/sys to change settings.
@@ -111,16 +119,17 @@ Table 1-1: Process specific entries in /proc
 ..............................................................................
  File    Content                                        
  cmdline Command line arguments                         
- environ Values of environment variables                
+ cpu	 Current and last cpu in wich it was executed		(2.4)(smp)
+ cwd	 Link to the current working directory
+ environ Values of environment variables      
+ exe	 Link to the executable of this process
  fd      Directory, which contains all file descriptors 
+ maps	 Memory maps to executables and library files		(2.4)
  mem     Memory held by this process                    
+ root	 Link to the root directory of this process
  stat    Process status                                 
- status  Process status in human readable form          
- cwd     Link to the current working directory          
- exe     Link to the executable of this process         
- maps    Memory maps                                    
- root    Link to the root directory of this process     
  statm   Process memory status information              
+ status  Process status in human readable form          
 ..............................................................................
 
 For example, to get the status information of a process, all you have to do is
@@ -131,6 +140,7 @@ read the file /proc/PID/status:
   State:  R (running) 
   Pid:    5452 
   PPid:   743 
+  TracerPid:      0						(2.4)
   Uid:    501     501     501     501 
   Gid:    100     100     100     100 
   Groups: 100 14 16 
@@ -187,13 +197,20 @@ Table 1-3: Kernel info in /proc
  devices     Available devices (block and character)           
  dma         Used DMS channels                                 
  filesystems Supported filesystems                             
+ driver	     Various drivers grouped here, currently rtc	(2.4)
+ execdomains Execdomains, related to security			(2.4)
+ fb	     Frame Buffer devices				(2.4)
+ fs	     File system parameters, currently nfs/exports	(2.4)
  ide         Directory containing info about the IDE subsystem 
  interrupts  Interrupt usage                                   
+ iomem	     Memory map						(2.4)
  ioports     I/O port usage                                    
- kcore       Kernel core image (can be ELF or A.OUT)           
+ irq	     Masks for irq to cpu affinity			(2.4)(smp?)
+ isapnp	     ISA PnP (Plug&Play) Info				(2.4)
+ kcore       Kernel core image (can be ELF or A.OUT(deprecated in 2.4))   
  kmsg        Kernel messages                                   
  ksyms       Kernel symbol table                               
- loadavg     Load average                                      
+ loadavg     Load average of last 1, 5 & 15 minutes                
  locks       Kernel locks                                      
  meminfo     Memory info                                       
  misc        Miscellaneous                                     
@@ -201,14 +218,19 @@ Table 1-3: Kernel info in /proc
  mounts      Mounted filesystems                               
  net         Networking info (see text)                        
  partitions  Table of partitions known to the system           
+ pci	     Depreciated info of PCI bus (new way -> /proc/bus/pci/, 
+             decoupled by lspci					(2.4)
  rtc         Real time clock                                   
  scsi        SCSI info (see text)                              
  slabinfo    Slab pool info                                    
  stat        Overall statistics                                
  swaps       Swap space utilization                            
  sys         See chapter 2                                     
+ sysvipc     Info of SysVIPC Resources (msg, sem, shm)		(2.4)
+ tty	     Info of tty drivers
  uptime      System uptime                                     
  version     Kernel version                                    
+ video	     bttv info of video resources			(2.4)
 ..............................................................................
 
 You can,  for  example,  check  which interrupts are currently in use and what
@@ -230,6 +252,68 @@ they are used for by looking in the file /proc/interrupts:
    15:          7          XT-PIC  ide1 
   NMI:          0 
 
+In 2.4.* a couple of lines where added to this file LOC & ERR (this time is the
+output of a SMP machine):
+
+  > cat /proc/interrupts 
+
+             CPU0       CPU1       
+    0:    1243498    1214548    IO-APIC-edge  timer
+    1:       8949       8958    IO-APIC-edge  keyboard
+    2:          0          0          XT-PIC  cascade
+    5:      11286      10161    IO-APIC-edge  soundblaster
+    8:          1          0    IO-APIC-edge  rtc
+    9:      27422      27407    IO-APIC-edge  3c503
+   12:     113645     113873    IO-APIC-edge  PS/2 Mouse
+   13:          0          0          XT-PIC  fpu
+   14:      22491      24012    IO-APIC-edge  ide0
+   15:       2183       2415    IO-APIC-edge  ide1
+   17:      30564      30414   IO-APIC-level  eth0
+   18:        177        164   IO-APIC-level  bttv
+  NMI:    2457961    2457959 
+  LOC:    2457882    2457881 
+  ERR:       2155
+
+NMI is incremented in this case because every timer interrupt generates a NMI
+(Non Maskable Interrupt) which is used by the NMI Watchdog to detect lookups.
+
+LOC is the local interrupt counter of the internal APIC of every CPU.
+
+ERR is incremented in the case of errors in the IO-APIC bus (the bus that
+connects the CPUs in a SMP system. This means that an error has been detected,
+the IO-APIC automatically retry the transmision, so it should not be a big
+problem, but you should read the SMP-FAQ.
+
+In this context it could be interesting to note the new irq directory in 2.4.
+It could be used to set IRQ to CPU affinity, this means that you can "hook" an
+IRQ to only one CPU, or to exclude a CPU of handling IRQs. The contents of the
+irq subdir is one subdir for each IRQ, and one file; prof_cpu_mask
+
+For example 
+  > ls /proc/irq/
+  0  10  12  14  16  18  2  4  6  8  prof_cpu_mask
+  1  11  13  15  17  19  3  5  7  9
+  > ls /proc/irq/0/
+  smp_affinity
+
+The contents of the prof_cpu_mask file and each smp_affinity file for each IRQ
+is the same by default:
+
+  > cat /proc/irq/0/smp_affinity 
+  ffffffff
+
+It's a bitmask, in wich you can specify wich CPUs can handle the IRQ, you can
+set it by doing:
+
+  > echo 1 > /proc/irq/prof_cpu_mask
+
+This means that only the first CPU will handle the IRQ, but you can also echo 5
+wich means that only the first and fourth CPU can handle the IRQ.
+
+The way IRQs are routed is handled by the IO-APIC, and it's Round Robin
+between all the CPUs which are allowed to handle it. As usual the kernel has
+more info than you and does a better job than you, so the defaults are the
+best choice for almost everyone.
 
 There are  three  more  important subdirectories in /proc: net, scsi, and sys.
 The general  rule  is  that  the  contents,  or  even  the  existence of these
@@ -1307,6 +1391,15 @@ Time in seconds to keep an IP fragment in memory.
 TCP settings
 ------------
 
+tcp_ecn
+-------
+
+This file controls the use of the ECN bit in the IPv4 headers, this is a new
+feature about Explicit Congestion Notification, but some routers and firewalls
+block trafic that has this bit set, so it could be necessary to echo 0 to
+/proc/sys/net/ipv4/tcp_ecn, if you want to talk to this sites. For more info
+you could read RFC2481.
+
 tcp_retrans_collapse
 --------------------
 
diff --git a/Documentation/initrd.txt b/Documentation/initrd.txt
index acc2315a4..941f9ddd0 100644
--- a/Documentation/initrd.txt
+++ b/Documentation/initrd.txt
@@ -1,25 +1,28 @@
 Using the initial RAM disk (initrd)
 ===================================
 
-Written 1996 by Werner Almesberger <almesber@lrc.epfl.ch> and
-		Hans Lermen <lermen@elserv.ffm.fgan.de>
+Written 1996,2000 by Werner Almesberger <werner.almesberger@epfl.ch> and
+                     Hans Lermen <lermen@fgan.de>
 
 
-initrd adds the capability to load a RAM disk by the boot loader. This
-RAM disk can then be mounted as the root file system and programs can be
-run from it. Afterwards, a new root file system can be mounted from a
-different device. The previous root (from initrd) is then either moved
-to the directory /initrd or it is unmounted.
+initrd provides the capability to load a RAM disk by the boot loader.
+This RAM disk can then be mounted as the root file system and programs
+can be run from it. Afterwards, a new root file system can be mounted
+from a different device. The previous root (from initrd) is then moved
+to a directory and can be subsequently unmounted.
 
 initrd is mainly designed to allow system startup to occur in two phases,
 where the kernel comes up with a minimum set of compiled-in drivers, and
 where additional modules are loaded from initrd.
 
+This document gives a brief overview of the use of initrd. A more detailed
+discussion of the boot process can be found in [1].
+
 
 Operation
 ---------
 
-When using initrd, the system boots as follows:
+When using initrd, the system typically boots as follows:
 
   1) the boot loader loads the kernel and the initial RAM disk
   2) the kernel converts initrd into a "normal" RAM disk and
@@ -28,28 +31,17 @@ When using initrd, the system boots as follows:
   4) /linuxrc is executed (this can be any valid executable, including
      shell scripts; it is run with uid 0 and can do basically everything
      init can do)
-  5) when linuxrc terminates, the "real" root file system is mounted
-  6) if a directory /initrd exists, the initrd is moved there
-     otherwise, initrd is unmounted
+  5) linuxrc mounts the "real" root file system
+  6) linuxrc places the root file system at the root directory using the
+     pivot_root system call
   7) the usual boot sequence (e.g. invocation of /sbin/init) is performed
      on the root file system
+  8) the initrd file system is removed
 
-Note that moving initrd from / to /initrd does not involve unmounting it.
-It is therefore possible to leave processes running on initrd (or leave
-file systems mounted, but see below) during that procedure. However, if
-/initrd doesn't exist, initrd can only be unmounted if it is not used by
-anything. If it can't be unmounted, it will stay in memory.
-
-Also note that file systems mounted under initrd continue to be accessible,
-but their /proc/mounts entries are not updated. Also, if /initrd doesn't
-exist, initrd can't be unmounted and will "disappear" and take those file
-systems with it, thereby preventing them from being re-mounted. It is
-therefore strongly suggested to generally unmount all file systems (except
-of course for the root file system, but including /proc) before switching
-from initrd to the "normal" root file system.
-
-In order to deallocate the memory used for the initial RAM disk, you have
-to execute freeramdisk (see 'Resources' below) after unmounting /initrd.
+Note that changing the root directory does not involve unmounting it.
+It is therefore possible to leave processes running on initrd during that
+procedure. Also note that file systems mounted under initrd continue to
+be accessible.
 
 
 Boot command-line options
@@ -57,7 +49,7 @@ Boot command-line options
 
 initrd adds the following new options:
 
-  initrd=<path>    (LOADLIN only)
+  initrd=<path>    (e.g. LOADLIN)
 
     Loads the specified file as the initial RAM disk. When using LILO, you
     have to specify the RAM disk image file in /etc/lilo.conf, using the
@@ -71,40 +63,38 @@ initrd adds the following new options:
     in this case and doesn't necessarily have to be a file system image.
     This option is used mainly for debugging.
 
-    Note that /dev/initrd is read-only and that it can only be used once.
-    As soon as the last process has closed it, all data is freed and
-    /dev/initrd can't be opened any longer.
+    Note: /dev/initrd is read-only and it can only be used once. As soon
+    as the last process has closed it, all data is freed and /dev/initrd
+    can't be opened anymore.
 
-  root=/dev/ram
+  root=/dev/ram0   (without devfs)
+  root=/dev/rd/0   (with devfs)
 
-    initrd is mounted as root, and /linuxrc is started. If no /linuxrc
-    exists, the normal boot procedure is followed, with the RAM disk
-    still mounted as root. This option is mainly useful when booting from
-    a floppy disk. Compared to directly mounting an on-disk file system,
-    the intermediate step of going via initrd adds a little speed
-    advantage and it allows the use of a compressed file system.
-    Also, together with LOADLIN you may load the RAM disk directly from
-    CDROM or disk, hence having a floppyless boot from CD,
-    e.g.: E:\loadlin E:\bzImage root=/dev/ram initrd=E:\rdimage
+    initrd is mounted as root, and the normal boot procedure is followed,
+    with the RAM disk still mounted as root.
 
 
 Installation
 ------------
 
-First, the "normal" root file system has to be prepared as follows:
+First, a directory for the initrd file system has to be created on the
+"normal" root file system, e.g.
 
-# mknod /dev/initrd b 1 250 
-# chmod 400 /dev/initrd
 # mkdir /initrd
 
+The name is not relevant. More details can be found on the pivot_root(2)
+man page.
+
 If the root file system is created during the boot procedure (i.e. if
-you're creating an install floppy), the root file system creation
-procedure should perform these operations.
+you're building an install floppy), the root file system creation
+procedure should create the /initrd directory.
+
+If initrd will not be mounted in some cases, its content is still
+accessible if the following device has been created (note that this
+does not work if using devfs):
 
-Note that neither /dev/initrd nor /initrd are strictly required for
-correct operation of initrd, but it is a lot easier to experiment with
-initrd if you have them, and you may also want to use /initrd to pass
-data to the "real" system.
+# mknod /dev/initrd b 1 250 
+# chmod 400 /dev/initrd
 
 Second, the kernel has to be compiled with RAM disk support and with
 support for the initial RAM disk enabled. Also, at least all components
@@ -112,100 +102,148 @@ needed to execute programs from initrd (e.g. executable format and file
 system) must be compiled into the kernel.
 
 Third, you have to create the RAM disk image. This is done by creating a
-file system on a block device and then by copying files to it as needed.
-With recent kernels, at least three types of devices are suitable for
-that:
+file system on a block device, copying files to it as needed, and then
+copying the content of the block device to the initrd file. With recent
+kernels, at least three types of devices are suitable for that:
 
  - a floppy disk (works everywhere but it's painfully slow)
  - a RAM disk (fast, but allocates physical memory)
- - a loopback device (the most elegant solution, but currently requires a
-   modified mount)
+ - a loopback device (the most elegant solution)
 
-We'll describe the RAM disk method:
+We'll describe the loopback device method:
 
- 1) make sure you have a RAM disk device /dev/ram (block, major 1, minor 0)
+ 1) make sure loopback block devices are configured into the kernel
  2) create an empty file system of the appropriate size, e.g.
-    # mke2fs -m0 /dev/ram 300   
+    # dd if=/dev/zero of=initrd bs=300k count=1
+    # mke2fs -F -m0 initrd
     (if space is critical, you may want to use the Minix FS instead of Ext2)
- 3) mount the file system on an appropriate directory, e.g.
-    # mount -t ext2 /dev/ram /mnt
- 4) create the console device:
+ 3) mount the file system, e.g.
+    # mount -t ext2 -o loop initrd /mnt
+ 4) create the console device (not necessary if using devfs, but it can't
+    hurt to do it anyway):
     # mkdir /mnt/dev
-    # mknod /mnt/dev/tty1 c 4 1
+    # mknod /mnt/dev/console c 5 1
  5) copy all the files that are needed to properly use the initrd
     environment. Don't forget the most important file, /linuxrc
     Note that /linuxrc's permissions must include "x" (execute).
- 6) unmount the RAM disk
-    # umount /dev/ram
- 7) copy the image to a file
-    # dd if=/dev/ram bs=1k count=300 of=/boot/initrd
- 8) deallocate the RAM disk
-    # freeramdisk /dev/ram
-
-For experimenting with initrd, you may want to take a rescue floppy (e.g.
-rescue.gz from Slackware) and only add a symbolic link from /linuxrc to
-/bin/sh, e.g.
-
- # gunzip <rescue.gz >/dev/ram
- # mount -t minix /dev/ram /mnt
- # ln -s /bin/sh /mnt/linuxrc
- # umount /dev/ram
- # dd if=/dev/ram bs=1k count=1440 of=/boot/initrd
- # freeramdisk /dev/ram
-
-Finally, you have to boot the kernel and load initrd. Currently,
-preliminary versions of LOADLIN 1.6 and LILO 18 support initrd (see
-below for where to get them). With LOADLIN, you simply execute
+ 6) correct operation the initrd environment can frequently be tested
+    even without rebooting with the command
+    # chroot /mnt /linuxrc
+    This is of course limited to initrds that do not interfere with the
+    general system state (e.g. by reconfiguring network interfaces,
+    overwriting mounted devices, trying to start already running demons,
+    etc. Note however that it is usually possible to use pivot_root in
+    such a chroot'ed initrd environment.)
+ 7) unmount the file system
+    # umount /mnt
+ 8) the initrd is now in the file "initrd". Optionally, it can now be
+    compressed
+    # gzip -9 initrd
+
+For experimenting with initrd, you may want to take a rescue floppy and
+only add a symbolic link from /linuxrc to /bin/sh. Alternatively, you
+can try the experimental newlib environment [2] to create a small
+initrd.
+
+Finally, you have to boot the kernel and load initrd. Almost all Linux
+boot loaders support initrd. Since the boot process is still compatible
+with an older mechanism, the following boot command line parameters
+have to be given:
+
+  root=/dev/ram0 init=/linuxrc rw
+
+if not using devfs, or
+
+  root=/dev/rd/0 init=/linuxrc rw
+
+if using devfs. (rw is only necessary if writing to the initrd file
+system.)
+
+With LOADLIN, you simply execute
 
      LOADLIN <kernel> initrd=<disk_image>
-e.g. LOADLIN C:\LINUX\VMLINUZ initrd=C:\LINUX\INITRD
+e.g. LOADLIN C:\LINUX\BZIMAGE initrd=C:\LINUX\INITRD.GZ root=/dev/ram0
+       init=/linuxrc rw
 
 With LILO, you add the option INITRD=<path> to either the global section
-or to the section of the respective kernel in /etc/lilo.conf, e.g.
+or to the section of the respective kernel in /etc/lilo.conf, and pass
+the options using APPEND, e.g.
 
-  image = /vmlinuz
-    initrd = /boot/initrd
+  image = /bzImage
+    initrd = /boot/initrd.gz
+    append = "root=/dev/ram0 init=/linuxrc rw"
 
 and run /sbin/lilo
 
+For other boot loaders, please refer to the respective documentation.
+
 Now you can boot and enjoy using initrd.
 
 
-Setting the root device
------------------------
+Changing the root device
+------------------------
 
-By default, the standard settings in the kernel are used for the root
-device, i.e. the default compiled in or set with rdev, or what was passed
-with root=xxx on the command line, or, with LILO, what was specified in
-/etc/lilo.conf It is also possible to use initrd with an NFS-mounted
-root; you have to use the nfs_root_name and nfs_root_addrs boot options
-for this.
+When finished with its duties, linuxrc typically changes the root device
+and proceeds with starting the Linux system on the "real" root device.
 
-It is also possible to change the root device from within the initrd
-environment. In order to do so, /proc has to be mounted. Then, the
-following files are available:
+The procedure involves the following steps:
+ - mounting the new root file system
+ - turning it into the root file system
+ - removing all accesses to the old (initrd) root file system
+ - unmounting the initrd file system and de-allocating the RAM disk
 
-  /proc/sys/kernel/real-root-dev
-  /proc/sys/kernel/nfs-root-name
-  /proc/sys/kernel/nfs-root-addrs
+Mounting the new root file system is easy: it just needs to be mounted on
+a directory under the current root. Example:
 
-real-root-dev can be changed by writing the number of the new root FS
-device to it, e.g.
+# mkdir /new-root
+# mount -o ro /dev/hda1 /new-root
 
-  # echo 0x301 >/proc/sys/kernel/real-root-dev
+The root change is accomplished with the pivot_root system call, which
+is also available via the pivot_root utility (see pivot_root(8) man
+page; pivot_root is distributed with util-linux version 2.10h or higher
+[3]). pivot_root moves the current root to a directory under the new
+root, and puts the new root at its place. The directory for the old root
+must exist before calling pivot_root. Example:
+
+# cd /new-root
+# mkdir initrd
+# pivot_root . initrd
+
+Now, the linuxrc process may still access the old root via its
+executable, shared libraries, standard input/output/error, and its
+current root directory. All these references are dropped by the
+following command:
+
+# exec chroot . what-follows <dev/console >dev/console 2>&1
+
+Where what-follows is a program under the new root, e.g. /sbin/init
+If the new root file system will be used with devfs and has no valid
+/dev directory, devfs must be mounted before invoking chroot in order to
+provide /dev/console.
 
-for /dev/hda1. When using an NFS-mounted root, nfs-root-name and
-nfs-root-addrs have to be set accordingly and then real-root-dev has to
-be set to 0xff, e.g.
+Note: implementation details of pivot_root may change with time. In order
+to ensure compatibility, the following points should be observed:
 
-  # echo /var/nfsroot >/proc/sys/kernel/nfs-root-name
-  # echo 193.8.232.2:193.8.232.7::255.255.255.0:idefix \
-    >/proc/sys/kernel/nfs-root-addrs
-  # echo 255 >/proc/sys/kernel/real-root-dev
+ - before calling pivot_root, the current directory of the invoking
+   process should point to the new root directory
+ - use . as the first argument, and the _relative_ path of the directory
+   for the old root as the second argument
+ - a chroot program must be available under the old and the new root
+ - chroot to the new root afterwards
+ - use relative paths for dev/console in the exec command
 
-If the root device is set to the RAM disk, the root file system is not
-moved to /initrd, but the boot procedure is simply continued by starting
-init on the initial RAM disk.
+Now, the initrd can be unmounted and the memory allocated by the RAM
+disk can be freed:
+
+# umount /initrd
+# blockdev --flushbufs /dev/ram0    # /dev/rd/0 if using devfs
+
+It is also possible to use initrd with an NFS-mounted root, see the
+pivot_root(8) man page for details.
+
+Note: if linuxrc or any program exec'ed from it terminates for some
+reason, the old change_root mechanism is invoked (see section "Obsolete
+root change mechanism").
 
 
 Usage scenarios
@@ -215,32 +253,30 @@ The main motivation for implementing initrd was to allow for modular
 kernel configuration at system installation. The procedure would work
 as follows:
 
-  1) systems boots from floppy or other media with a minimal kernel
-     (e.g. support for RAM disks, initrd, a.out, and the ext2 FS) and
+  1) system boots from floppy or other media with a minimal kernel
+     (e.g. support for RAM disks, initrd, a.out, and the Ext2 FS) and
      loads initrd
   2) /linuxrc determines what is needed to (1) mount the "real" root FS
      (i.e. device type, device drivers, file system) and (2) the
      distribution media (e.g. CD-ROM, network, tape, ...). This can be
      done by asking the user, by auto-probing, or by using a hybrid
      approach.
-  3) /linuxrc loads the necessary modules
+  3) /linuxrc loads the necessary kernel modules
   4) /linuxrc creates and populates the root file system (this doesn't
      have to be a very usable system yet)
-  5) /linuxrc unmounts the root file system and possibly any other file
-     systems it has mounted, sets /proc/sys/kernel/..., and terminates
-  6) the root file system is mounted
-  7) now that we're sure that the file system is accessible and intact,
-     the boot loader can be installed
-  8) the boot loader is configured to load an initrd with the set of
+  5) /linuxrc invokes pivot_root to change the root file system and
+     execs - via chroot - a program that continues the installation
+  6) the boot loader is installed
+  7) the boot loader is configured to load an initrd with the set of
      modules that was used to bring up the system (e.g. /initrd can be
      modified, then unmounted, and finally, the image is written from
-     /dev/ram to a file)
-  9) now the system is bootable and additional installation tasks can be
+     /dev/ram0 or /dev/rd/0 to a file)
+  8) now the system is bootable and additional installation tasks can be
      performed
 
 The key role of initrd here is to re-use the configuration data during
 normal system operation without requiring the use of a bloated "generic"
-kernel or re-compilation or re-linking of the kernel.
+kernel or re-compiling or re-linking the kernel.
 
 A second scenario is for installations where Linux runs on systems with
 different hardware configurations in a single administrative domain. In
@@ -252,35 +288,53 @@ read by it would have to be different.
 
 A third scenario are more convenient recovery disks, because information
 like the location of the root FS partition doesn't have to be provided at
-boot time, but the system loaded from initrd can use a user-friendly
+boot time, but the system loaded from initrd can invoke a user-friendly
 dialog and it can also perform some sanity checks (or even some form of
 auto-detection).
 
-Last not least, CDROM distributors may use it for better installation from CD,
-either using a LILO boot floppy and bootstrapping a bigger RAM disk via
-initrd from CD, or using LOADLIN to directly load the RAM disk from CD
-without need of floppies.
+Last not least, CD-ROM distributors may use it for better installation
+from CD, e.g. by using a boot floppy and bootstrapping a bigger RAM disk
+via initrd from CD; or by booting via a loader like LOADLIN or directly
+from the CD-ROM, and loading the RAM disk from CD without need of
+floppies. 
 
-Since initrd is a fairly generic mechanism, it is likely that additional
-uses will be found.
 
+Obsolete root change mechanism
+------------------------------
 
-Resources
----------
+The following mechanism was used before the introduction of pivot_root.
+Current kernels still support it, but you should _not_ rely on its
+continued availability.
+
+It works by mounting the "real" root device (i.e. the one set with rdev
+in the kernel image or with root=... at the boot command line) as the
+root file system when linuxrc exits. The initrd file system is then
+unmounted, or, if it is still busy, moved to a directory /initrd, if
+such a directory exists on the new root file system.
+
+In order to use this mechanism, you do not have to specify the boot
+command options root, init, or rw. (If specified, they will affect
+the real root file system, not the initrd environment.)
+  
+If /proc is mounted, the "real" root device can be changed from within
+linuxrc by writing the number of the new root FS device to the special
+file /proc/sys/kernel/real-root-dev, e.g.
+
+  # echo 0x301 >/proc/sys/kernel/real-root-dev
+
+Note that the mechanism is incompatible with NFS and similar file
+systems.
 
-The bzImage+initrd patch (bzImage is an extension to load kernels directly
-above 1 MB, which allows kernels sizes of up to approximately 2 MB) can be
-found at
-ftp://lrcftp.epfl.ch/pub/people/almesber/lilo/bzImage+initrd-1.3.71.patch.gz
-and
-ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/bzImage+initrd-1.3.71.patch.gz
+This old, deprecated mechanism is commonly called "change_root", while
+the new, supported mechanism is called "pivot_root".
 
-A preliminary version of LOADLIN 1.6 is available on
-ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/loadlin-1.6-pre8-bin.tgz
 
-A preliminary version of LILO 18 is available on
-ftp://lrcftp.epfl.ch/pub/people/almesber/lilo/lilo.18dev3.tar.gz
+Resources
+---------
 
-A very simple example for building an image for initrd, also including
-the program 'freeramdisk', can be found on
-ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/initrd-example.tgz
+[1] Almesberger, Werner; "Booting Linux: The History and the Future"
+    ftp://icaftp.epfl.ch/pub/people/almesber/booting/bootinglinux-current.ps.gz
+[2] newlib package (experimental), with initrd example
+    ftp://icaftp.epfl.ch/pub/people/almesber/misc/newlib-linux/
+[3] Brouwer, Andries; "util-linux: Miscellaneous utilities for Linux"
+    ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index 0edc635ff..4fd9a4b5a 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt
@@ -74,8 +74,8 @@ Code	Seq#	Include File		Comments
 0x22	all	scsi/sg.h
 '1'	00-1F	<linux/timepps.h>	PPS kit from Ulrich Windl
 					<ftp://ftp.de.kernel.org/pub/linux/daemons/ntp/PPS/>
-'6'	00-10	<asm-i386/processor.h>	Intel P6 microcode update driver
-					<tigran@veritas.com>
+'6'	00-10	<asm-i386/processor.h>	Intel IA32 microcode update driver
+					<mailto:tigran@veritas.com>
 '8'	all				SNP8023 advanced NIC card
 					<mailto:mcr@solidum.com>
 'A'	00-1F	linux/apm_bios.h
diff --git a/Documentation/isdn/INTERFACE.fax b/Documentation/isdn/INTERFACE.fax
index 4c164b805..7e5731319 100644
--- a/Documentation/isdn/INTERFACE.fax
+++ b/Documentation/isdn/INTERFACE.fax
@@ -1,4 +1,4 @@
-$Id: INTERFACE.fax,v 1.1 1999/08/11 20:30:28 armin Exp $
+$Id: INTERFACE.fax,v 1.2 2000/08/06 09:22:50 armin Exp $
 
 
 Description of the fax-subinterface between linklevel and hardwarelevel of 
diff --git a/Documentation/isdn/README.HiSax b/Documentation/isdn/README.HiSax
index 2dddf96ec..63308c20a 100644
--- a/Documentation/isdn/README.HiSax
+++ b/Documentation/isdn/README.HiSax
@@ -54,6 +54,7 @@ Sedlbauer ISDN-Controller PC/104
 USR Sportster internal TA (compatible Stollmann tina-pp V3)
 ith Kommunikationstechnik GmbH MIC 16 ISA card
 Traverse Technologie NETjet PCI S0 card and NETspider U card
+Ovislink ISDN sc100-p card (NETjet driver)
 Dr. Neuhaus Niccy PnP/PCI
 Siemens I-Surf 1.0
 Siemens I-Surf 2.0 (with IPAC, try type 12 asuscom) 
@@ -191,8 +192,9 @@ Card types:
    34	Gazel ISDN cards (PCI)   none
    35	HFC 2BDS0 PCI            none
    36	W6692 based PCI cards    none
-   37	HFC 2BDS0 S+, SP/PCMCIA  irq,io (pcmcia must be set with cardmgr)
+   37	HFC 2BDS0 S+, SP         irq,io 
    38	NETspider U PCI card     none
+   39	HFC 2BDS0 SP/PCMCIA      irq,io (set with cardmgr)
 
 At the moment IRQ sharing is only possible with PCI cards. Please make sure
 that your IRQ is free and enabled for ISA use.
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 1b63892c6..ef789acf2 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -32,6 +32,8 @@ This document describes the Linux kernel Makefiles.
      7.6  Compilation flags
      7.7  Miscellaneous variables
   8  New-style variables
+     8.1  New variables
+     8.2  Converting to old-style
   9  Compatibility with Linux Kernel 2.2
  10  Credits
 
@@ -521,6 +523,8 @@ contains boilerplate code which converts from new-style variables to
 old-style variables.  This is because Rules.make processes only the
 old-style variables.
 
+See section 8.2 ("Converting to old-style") for examples.
+
 
 
 --- 6.4 Rules.make section
@@ -679,6 +683,25 @@ The public interface of Rules.make consists of the following variables:
 	options still control whether or not its $(O_TARGET) goes into
 	vmlinux.  See the $(M_OBJS) example below.
 
+	Sometimes the ordering of all $(OX_OBJS) files before all
+	$(O_OBJS) files can be a problem, particularly if both
+	$(O_OBJS) files and $(OX_OBJS) files contain __initcall
+	declarations where order is important.   To avoid this imposed
+	ordering, the use of $(OX_OBJS) can be dropped altogether and
+	$(MIX_OBJS) used instead.
+
+	If this approach is used, then:
+	 - All objects to be linked into vmlinux should be listed in
+	   $(O_OBJS) in the desired order.
+	 - All objects to be created as modules should be listed in
+	   $(M_OBJS)
+	 - All objects that export symbols should also be listed in
+	   $(MIX_OBJS).
+
+	This has the same effect as maintaining the
+	exported/non-exported split, except that there is more control
+	over the ordering of object files in vmlinux.
+	
 
 
 --- 7.3 Library file goals
@@ -865,6 +888,14 @@ The public interface of Rules.make consists of the following variables:
 			$(LD) -r -o $@ $(sb-objs)
 
 
+	As is mentioned in section 7.2 ("Object file goals"),
+	$(MIX_OBJS) can also be used simply to list all objects that
+	export any symbols.  If this approach is taken, then
+	$(O_OBJS), $(L_OBJS), $(M_OBJS) and $(MI_OBJS) should simply
+	lists all of the vmlinux object files, library object files,
+	module object files and intermediate module files
+	respectively.  Duplication between $(MI_OBJS) and $(MIX_OBJS)
+	is not a problem.
 
 --- 7.6 Compilation flags
 
@@ -993,6 +1024,8 @@ variables into old-style variables.  There is also some mixing, where
 people define most variables using "new style" but then fall back to
 "old style" for a few lines.
 
+--- 8.1 New variables
+
     obj-y obj-m obj-n obj-
 
 	These variables replace $(O_OBJS), $(OX_OBJS), $(M_OBJS),
@@ -1184,6 +1217,41 @@ people define most variables using "new style" but then fall back to
 	This means nls should be added to (subdir-y) and $(subdir-m) if
 	CONFIG_NFS = y.
 
+--- 8.2 Converting to old-style
+
+	The following example is taken from drivers/usb/Makefile.
+	Note that this uses MIX_OBJS to avoid the need for OX_OBJS and
+	MX_OBJS and thus to maintain the ordering of objects in $(obj-y)
+
+		# Translate to Rules.make lists.
+		multi-used	:= $(filter $(list-multi), $(obj-y) $(obj-m))
+		multi-objs	:= $(foreach m, $(multi-used), $($(basename $(m))-objs))
+		active-objs	:= $(sort $(multi-objs) $(obj-y) $(obj-m))
+
+		O_OBJS		:= $(obj-y)
+		M_OBJS		:= $(obj-m)
+		MIX_OBJS	:= $(filter $(export-objs), $(active-objs))
+
+	An example for libraries from drivers/acorn/scsi/Makefile:
+
+		# Translate to Rules.make lists.
+
+		L_OBJS		:= $(filter-out $(export-objs), $(obj-y))
+		LX_OBJS		:= $(filter     $(export-objs), $(obj-y))
+		M_OBJS		:= $(sort $(filter-out $(export-objs), $(obj-m)))
+		MX_OBJS		:= $(sort $(filter     $(export-objs), $(obj-m)))
+
+	As ordering is not so important in libraries, this still uses
+	LX_OBJS and MX_OBJS, though (presumably) it could be changed to
+	use MIX_OBJS as follows:
+
+		active-objs	:= $(sort $(obj-y) $(obj-m))
+		L_OBJS		:= $(obj-y)
+		M_OBJS		:= $(obj-m)
+		MIX_OBJS	:= $(filter $(export-objs), $(active-objs))
+		
+
+	which is clearly shorted and arguably clearer.
 
 === 9 Compatibility with Linux Kernel 2.2
 
diff --git a/Documentation/networking/irda.txt b/Documentation/networking/irda.txt
index fa455100e..a4b5a110d 100644
--- a/Documentation/networking/irda.txt
+++ b/Documentation/networking/irda.txt
@@ -1,10 +1,10 @@
 To use the IrDA protocols within Linux you will need to get a suitable copy
 of the IrDA Utilities. More detailed information about these and associated
-programs can be found on http://www.cs.uit.no/linux-irda/
+programs can be found on http://irda.sourceforge.net/
 
 For more information about how to use the IrDA protocol stack, see the
-IR-HOWTO (http://www.snafu.de/~wehe/IR-HOWTO.html) written by Werner Heuser
-<wehe@snafu.de>
+IR-HOWTO (http://www.mobilix.org/Infrared-HOWTO/Infrared-HOWTO.html) written by Werner Heuser
+<wehe@mobilix.org>
 
 There is an active mailing list for discussing Linux-IrDA matters called
 linux-irda. To subscribe to it, visit:
diff --git a/Documentation/parisc/00-INDEX b/Documentation/parisc/00-INDEX
new file mode 100644
index 000000000..7c8494ea2
--- /dev/null
+++ b/Documentation/parisc/00-INDEX
@@ -0,0 +1,10 @@
+00-INDEX
+	- this file.
+IODC.txt
+	- Documentation IODC
+debugging
+	- some debugging hints for real-mode code
+mm
+	- Documentation on parisc mm status
+registers
+	- current/planned usage of registers
diff --git a/Documentation/parisc/IODC.txt b/Documentation/parisc/IODC.txt
new file mode 100644
index 000000000..d686536f1
--- /dev/null
+++ b/Documentation/parisc/IODC.txt
@@ -0,0 +1,68 @@
+Some notes on IODC, its general brokenness, and how to work around it.
+
+Short Version
+
+IODC is HP's pre-PCI standard for device identification (a la PCI vendor,
+device IDs), detection, configuration, initialization and so on.
+
+It also can provide firmware function to do the actual IO, which are slow,
+not really defined for runtime usage and generally not desirable.  (There
+are other firmware standards, such as STI, to do real IO).
+
+Usually, there are two parts to IODC.  The actual ROMs, which are laid out,
+detected aso in a bus-specific manner (IO_DC_ADDRESS / IO_DC_DATA on
+GSC/Runway, PCI spec - compliant ROMs for PCI, God-only-knows how on EISA),
+and the slightly cooked data read by PDC_IODC.
+
+The ROM layout is generally icky (only one byte out of every 4-byte-word
+might be valid, and many devices don't implement required options), so
+using PDC_IODC is highly recommended.  (In fact, you should use the device
+lists set up by the kernel proper instead of calling PDC_IODC yourself).
+
+Now, let's have a look at what the cooked ROM looks like (see iodc.pdf for
+the details, this is the simplified version).
+
+Basically, the first 8 bytes of IODC contain two 32-bit ids called HVERSION
+and SVERSION.  Those are further split up into bit fields, and
+unfortunately just ignoring this split up isn't an option.
+
+SVERSION consists of a 4-bit revision field, a 20-bit model field and a
+8-bit opt field.  Now, forget the revision and opt fields exist.  Basically,
+the model field is equivalent to a PCI device id (there is no vendor id.
+this is proprietary hardware we're talking about).  That is, all your
+driver cares for, in 90 % of the cases, is to find all devices that match
+the model field.
+
+The rev field is - you guessed it - roughly equivalent to the revision
+byte for PCI, with the exception that higher revisions should be strict
+supersets of lower revisions.
+
+The last byte of HVERSION, "type", and the last byte of SVERSION, "opt",
+belong together;  type gives a very rough indication of what the device
+is supposed to do, and opt contains some type-specific information. (For
+example, the "bus converter" (ie bus bridge) type encodes the kind of
+bus behind the bridge in the opt field.
+
+The rest of HVERSION contains, in most cases, a number identifying the
+machine the chip was used in, or a revision indicator that just fixed
+bugs and didn't add any features (or was done in a shrinked process or
+whatever).
+
+So, here's the interface you actually should use to find your devices:
+
+
+/* Find a device, matching the model field of sversion only (from=NULL
+ * for the first call */
+struct iodc_dev *iodc_find_device(u32 sversion, struct iodc_dev *from);
+
+
+Here's a function you should use if you have special requirements, such
+as finding devices by type rather than by model.  Generally, if you're
+using this, you should be me).
+
+/* Find a device, masking out bits as specified */
+struct iodc_dev *iodc_find_device_mask(u32 hversion, u32 sversion,
+	u32 hversion_mask, u32 sversion_mask, struct iodc_dev *from);
+
+
+	Philipp Rumpf <prumpf@tux.org>
diff --git a/Documentation/parisc/debugging b/Documentation/parisc/debugging
new file mode 100644
index 000000000..5e060917a
--- /dev/null
+++ b/Documentation/parisc/debugging
@@ -0,0 +1,39 @@
+okay, here are some hints for debugging the lower-level parts of
+linux/parisc.
+
+
+1. Absolute addresses
+
+A lot of the assembly code currently runs in real mode, which means
+absolute addresses are used instead of virtual addresses as in the
+rest of the kernel.  To translate an absolute address to a virtual
+address you can lookup in System.map, add __PAGE_OFFSET (0xc0000000
+currently).
+
+
+2. HPMCs
+
+When real-mode code tries to access non-existent memory, you'll get
+an HPMC instead of a kernel oops.  To debug an HPMC, try to find
+the System Responder/Requestor addresses.  The System Requestor
+address should match (one of the) processor HPAs (high addresses in
+the I/O range); the System Responder address is the address real-mode
+code tried to access.
+
+Typical values for the System Responder address are addresses larger
+than __PAGE_OFFSET (0xc0000000) which mean a virtual address didn't
+get translated to a physical address before real-mode code tried to
+access it.
+
+
+3. Q bit fun
+
+Certain, very critical code has to clear the Q bit in the PSW.  What
+happens when the Q bit is cleared is the CPU does not update the
+registers interruption handlers read to find out where the machine
+was interrupted - so if you get an interruption between the instruction
+that clears the Q bit and the RFI that sets it again you don't know
+where exactly it happened.  If you're lucky the IAOQ will point to the
+instrucion that cleared the Q bit, if you're not it points anywhere
+at all.  Usually Q bit problems will show themselves in unexplainable
+system hangs or running off the end of physical memory.
diff --git a/Documentation/parisc/mm b/Documentation/parisc/mm
new file mode 100644
index 000000000..d53b29508
--- /dev/null
+++ b/Documentation/parisc/mm
@@ -0,0 +1,31 @@
+
+The current state of Linux/PA-RISC mm is BROKEN.
+
+Someone needs to sit down and thoroughly rewrite all the cache flushing
+macro definitions.  Here are some of the problems, followed by what I
+think needs to be done about them.
+
+(1) We're using fdce / fice everywhere.  This has to stop (except in
+the routines which flush the entire cache).  The right instructions to
+be using are fdc/fic.
+
+(2) fdc/fic will throw exceptions if the address they reference isn't
+mapped.  Therefore we need to check the page is mapped before flushing
+(we're guaranteed not to have the page dirty if we don't have a software
+mapping for it any longer, right?)
+
+(3) the flush macros are right now tunnelled down to one routine to flush
+the data cache and one routine to flush the insn cache.  this is wrong.
+we should take hints from how we're called and optimise our routines
+accordingly.
+
+(4) fdc/fic actually take space register arguments.  fic takes an 3-bit sr
+argument and fdc takes a 2-bit sr argument.  right now, there's a lot of
+pissing about with %sr1 and all the macros use %sr1.  This is crazy.  We
+normally _know_ what's being referred to, and it's the current task.  So
+if we want to flush that, just use %sr3.  If it happens to be kernel,
+use %sr0 for fdc and %sr4 for fic.
+
+(5) we need to write flush_kernel_dcache_range and use it on kernel
+addresses.  all the macros are defined to work on the _current task's_
+virtual address space.
diff --git a/Documentation/parisc/registers b/Documentation/parisc/registers
new file mode 100644
index 000000000..28097fe49
--- /dev/null
+++ b/Documentation/parisc/registers
@@ -0,0 +1,126 @@
+Register Usage for Linux/PA-RISC
+
+[ an asterisk is used for planned usage which is currently unimplemented ]
+
+	General Registers as specified by ABI
+
+	FPU Registers must not be used in kernel mode
+
+	Control Registers
+
+CR 0 (Recovery Counter)		used for ptrace
+CR 1-CR 7(undefined)		unused
+CR 8 (Protection ID)		per-process value*
+CR 9, 12, 13 (PIDS)		unused
+CR10 (CCR)			lazy FPU saving*
+CR11				as specified by ABI
+CR14 (interruption vector)	initialized to fault_vector
+CR15 (EIEM)			initialized to all ones*
+CR16 (Interval Timer)		timer interrupt
+CR17-CR22			interruption parameters
+CR23 (EIRR)			read for pending interrupts
+CR24 (TR 0)			Kernel Space Page Directory Pointer
+CR25 (TR 1)			User   Space Page Directory Pointer
+CR26 (TR 2)
+CR27 (TR 3)
+CR28 (TR 4)			used by interruption handlers
+CR29 (TR 5)			used by interruption handlers
+CR30 (TR 6)			current / 0
+CR31 (TR 7)			used by interruption handlers
+
+	Space Registers (kernel mode)
+
+SR0				temporary space register
+SR4-SR7 			set to 0
+SR1				temporary space register
+SR2				unused
+SR3				used for userspace accesses (current process)*
+
+	Space Registers (user mode)
+
+SR0				temporary space register
+SR1                             temporary space register
+SR2                             holds space of linux gateway page
+SR3                             holds user address space value while in kernel
+SR4-SR7                         Defines short address space for user/kernel
+
+
+	Processor Status Word
+
+W (64-bit addresses)		0
+E (Little-endian)		0
+S (Secure Interval Timer)	0
+T (Taken Branch Trap)		0
+H (Higher-privilege trap)	0
+L (Lower-privilege trap)	0
+N (Nullify next instruction)	used by C code
+X (Data memory break disable)	0
+B (Taken Branch)		used by C code
+C (code address translation)	1, 0 while executing real-mode code
+V (divide step correction)	used by C code
+M (HPMC mask)			0, 1 while executing HPMC handler*
+C/B (carry/borrow bits)		used by C code
+O (ordered references)		1*
+F (performance monitor)		0
+R (Recovery Counter trap)	0
+Q (collect interruption state)	1 (0 in code directly preceding an rfi)
+P (Protection Identifiers)	1*
+D (Data address translation)	1, 0 while executing real-mode code
+I (external interrupt mask)	used by cli()/sti() macros
+
+	"Invisible" Registers
+
+PSW default W value		0
+PSW default E value		0
+Shadow Registers		used by interruption handler code
+TOC enable bit			1
+
+=========================================================================
+Info from John Marvin:
+
+From: "John Marvin" <jsm@udlkern.fc.hp.com>
+To: randolf@tausq.org
+Subject: Re: parisc asm questions
+
+[...]
+
+For the general registers:
+
+r1,r2,r19-r26,r28,r29 & r31 can be used without saving them first. And of
+course, you need to save them if you care about them, before calling
+another procedure. Some of the above registers do have special meanings
+that you should be aware of:
+
+    r1: The addil instruction is hardwired to place its result in r1,
+	so if you use that instruction be aware of that.
+
+    r2: This is the return pointer. In general you don't want to
+	use this, since you need the pointer to get back to your
+	caller. However, it is grouped with this set of registers
+	since the caller can't rely on the value being the same
+	when you return, i.e. you can copy r2 to another register
+	and return through that register after trashing r2, and
+	that should not cause a problem for the calling routine.
+
+    r19-r22: these are generally regarded as temporary registers.
+	Note that in 64 bit they are arg7-arg4.
+
+    r23-r26: these are arg3-arg0, i.e. you can use them if you
+	don't care about the values that were passed in anymore.
+
+    r28,r29: are ret0 and ret1. They are what you pass return values
+	in. r28 is the primary return. I'm not sure I remember
+	under what circumstances stuff is returned in r29 (millicode
+	perhaps).
+
+    r31: the ble instruction puts the return pointer in here.
+
+
+r3-r18,r27,r30 need to be saved and restored. r3-r18 are just
+    general purpose registers. r27 is the data pointer, and is
+    used to make references to global variables easier. r30 is
+    the stack pointer.
+
+John
+
+
diff --git a/Documentation/sound/CMI8330 b/Documentation/sound/CMI8330
index 8885d3307..287799884 100644
--- a/Documentation/sound/CMI8330
+++ b/Documentation/sound/CMI8330
@@ -57,7 +57,7 @@ How to enable CMI 8330 (SOUNDPRO) soundchip on Linux
 ------------------------------------------
 Stefan Laudat <Stefan.Laudat@asit.ro>
 
-[Note: The CMI 8338 is unrelated and right now unsupported]
+[Note: The CMI 8338 is unrelated and is supported by cmpci.o]
 
 	
 	In order to use CMI8330 under Linux  you just have to use a proper isapnp.conf, a good isapnp and a little bit of patience.  I use isapnp 1.17, but
diff --git a/Documentation/usb/URB.txt b/Documentation/usb/URB.txt
index 7d99567ad..234c75cf3 100644
--- a/Documentation/usb/URB.txt
+++ b/Documentation/usb/URB.txt
@@ -1,3 +1,5 @@
+Revised: 2000-Dec-05.
+
 1. Specification of the API
 
 1.1. Basic concept or 'What is an URB?'
@@ -8,16 +10,16 @@ called USB Request Block, or URB for short.
 - An URB consists of all relevant information to execute any USB transaction 
 and deliver the data and status back. 
 
-- Execution of an URB is an inherently asynchronous operation, i.e. the 
-submit_urb(urb) call returns immediately after it has successfully queued 
+- Execution of an URB is inherently an asynchronous operation, i.e. the 
+usb_submit_urb(urb) call returns immediately after it has successfully queued 
 the requested action. 
 
 - Ongoing transfers for one URB (e.g. ISO) can simply be canceled with
-unlink_urb(urb) at any time. 
+usb_unlink_urb(urb) at any time. 
 
 - Each URB has a completion handler, which is called after the action
 has been successfully completed or canceled (INT transfers behave a bit
-different, see below). The URB also contains a context-pointer for free 
+differently, see below). The URB also contains a context-pointer for free 
 usage and information passing to the completion handler.
 
 - URBs can be linked. After completing one URB, the next one can be
@@ -31,6 +33,8 @@ URB-machinery.
 
 typedef struct urb
 {
+	spinlock_t lock;		// lock for the URB
+
 // ignore, for host controller/URB machine internal use
 	void *hcpriv;                   // private data for host controller
 	struct list_head urb_list;      // list pointer to all active urbs 
@@ -39,12 +43,12 @@ typedef struct urb
 	struct urb* next;               // pointer to next URB  
 	struct usb_device *dev;         // pointer to associated USB device
 
-// pipe is assembled by the various well known pipe-macros in usb.h
+// pipe is assembled by the various well-known pipe macros in usb.h
 	unsigned int pipe;              // pipe information
 
 // status after each completion
 	int status;                     // returned status
-	unsigned int transfer_flags;    // ASAP, SP_OK, etc.
+	unsigned int transfer_flags;    // ASAP, DISABLE_SPD, etc.
 
 // for data stage (CTRL), BULK, INT and ISO
 	void *transfer_buffer;          // associated data buffer
@@ -55,7 +59,7 @@ typedef struct urb
 
 // setup stage for CTRL (always 8 bytes!)
 	unsigned char* setup_packet;    // setup packet (control only)
-	
+
 // with ASAP, start_frame is set to the determined frame
 	int start_frame;                // start frame (iso/irq)
 	int number_of_packets;          // # of packets (iso/int)
@@ -66,7 +70,7 @@ typedef struct urb
 	usb_complete_t complete;        // pointer to completion routine
 	//
 // specification of the requested data offsets and length for ISO
-	iso_packet_descriptor_t  iso_frame_desc[0];
+	iso_packet_descriptor_t iso_frame_desc[0];
 } urb_t, *purb_t;
 
 
@@ -74,7 +78,7 @@ typedef struct urb
 
 URBs are allocated with the following call
 
-	purb_t alloc_urb(int isoframes)
+	purb_t usb_alloc_urb(int isoframes)
 
 Return value is a pointer to the allocated URB, 0 if allocation failed.
 The parameter isoframes specifies the number of isochronous transfer frames
@@ -82,7 +86,7 @@ you want to schedule. For CTRL/BULK/INT, use 0.
 
 To free an URB, use
 
-	void free_urb(purb_t purb)
+	void usb_free_urb(purb_t purb)
 
 This call also may free internal (host controller specific) memory in the
 future.
@@ -91,12 +95,13 @@ future.
 1.4. What has to be filled in?
 
 Depending on the type of transaction, there are some macros 
-(FILL_CONTROL_URB, FILL_BULK_URB, and FILL_INT_URB, defined in uhci.h)
+(FILL_CONTROL_URB, FILL_CONTROL_URB_TO, FILL_BULK_URB,
+FILL_BULK_URB_TO, and FILL_INT_URB, defined in usb.h)
 that simplify the URB creation. In general, all macros need the usb
-device pointer, the pipe (usual format), the transfer buffer, the 
-desired transfer length, the completion  handler, and its context. 
-Take a look at the uhci_control_msg-function that convert the old API 
-into an URB.
+device pointer, the pipe (usual format from usb.h), the transfer buffer,
+the desired transfer length, the completion  handler, and its context. 
+Take a look at the usb_control_msg function that converts the old API 
+into the URB API.
 
 Flags:
 For ISO there are two startup behaviors: Specified start_frame or ASAP.
@@ -114,7 +119,7 @@ re-submission for INT transfers that are being continued.
 
 Just call
 
-	int submit_urb(purb_t purb)
+	int usb_submit_urb(purb_t purb)
 
 It immediately returns, either with status 0 (request queued) or some
 error code, usually caused by the following:
@@ -128,7 +133,7 @@ error code, usually caused by the following:
 - Invalid INT interval (-EINVAL)
 - More than one packet for INT (-EINVAL)
 
-After submission, urb->status is USB_ST_URB_PENDING.
+After submission, urb->status is USB_ST_URB_PENDING (-EINPROGRESS).
 
 For isochronous endpoints, subsequent submitting of URBs to the same endpoint
 with the ASAP flag result in a seamless ISO streaming. Exception: The 
@@ -142,18 +147,18 @@ independent of the transfer flags (implicitly ASAP).
 For an URB which you've submitted, but which hasn't been returned to
 your driver by the host controller, call
 
-	int unlink_urb(purb_t purb)
+	int usb_unlink_urb(purb_t purb)
 
 It removes the urb from the internal list and frees all allocated
 HW descriptors. The status is changed to USB_ST_URB_KILLED. After 
-unlink_urb() returns, you can safely free the URB with free_urb(urb)
+usb_unlink_urb() returns, you can safely free the URB with usb_free_urb(urb)
 and all other possibly associated data (urb->context etc.)
 
 There is also an asynchronous unlink mode.  To use this, set the
 the USB_ASYNC_UNLINK flag in urb->transfer flags before calling
 usb_unlink_urb().  When using async unlinking, the URB will not
-normally be unlinked when unlink_urb() returns.  Instead, wait for
-the completion handler to be called.
+normally be unlinked when usb_unlink_urb() returns.  Instead, wait
+for the completion handler to be called.
 
 
 1.7. What about the completion handler?
@@ -187,13 +192,13 @@ in completion handlers.
 1.8. How to do isochronous (ISO) transfers?
 
 For ISO transfers you have to append the iso_packet_descriptor_t structure 
-to the URB for each frame you want to schedule. When using alloc_urb(n)
-(recommended), the isoframe-parameter n can be used to allocate the
-structures for n frames.
+to the URB for each frame you want to schedule. When using usb_alloc_urb(n)
+(recommended), the iso_packets parameter can be used to allocate the
+structures for iso_packets frames.
 
 For each entry you have to specify the data offset for this frame (base is
 transfer_buffer), and the length you want to write/expect to read.
-After completion, actual_length contains the actual transfered length and 
+After completion, actual_length contains the actual transferred length and 
 status contains the resulting USB-status for the ISO transfer for this frame.
 It is allowed to specify a varying length from frame to frame (e.g. for
 audio synchronisation/adaptive transfer rates). You can also use the length 
@@ -217,7 +222,7 @@ for 1, 2, 4,... 128ms. Only one URB is allocated for each interrupt. After
 calling the completion handler, that URB is recycled by the host controller
 driver (HCD).
 With the submission of one URB, the interrupt is scheduled until it is
-canceled by unlink_urb.
-
-The submit_urb()-call modifies urb->interval to the rounded value.
+canceled by usb_unlink_urb.
 
+The usb_submit_urb() call modifies urb->interval to the implemented interval
+value that is less than or equal to the requested interval value.
diff --git a/Documentation/usb/error-codes.txt b/Documentation/usb/error-codes.txt
index d1dccece5..964af3033 100644
--- a/Documentation/usb/error-codes.txt
+++ b/Documentation/usb/error-codes.txt
@@ -1,12 +1,12 @@
-$Id: README.error-codes,v 1.1 1999/12/14 14:03:02 fliegl Exp $
+Revised: 2000-Dec-05.
 
 This is the documentation of (hopefully) all possible error codes (and
-their interpretation) that can be returned from the hostcontroller driver 
+their interpretation) that can be returned from the host controller drivers 
 and from usbcore.
 
 NOTE:
-The USB_ST_* codes are deferred and are only listed for compatibility, new
-software should use only -E* instead!
+The USB_ST_* codes are deprecated and are only listed for compatibility;
+new software should use only -E* instead!
 
 
 
@@ -25,12 +25,16 @@ USB-specific:
 
 -ENODEV		specified USB-device or bus doesn't exist
 
--ENXIO		specified endpoint doesn't exist on the device
+USB_ST_REQUEST_ERROR
+-ENXIO		a control or interrupt URB is already queued to this endpoint; or
+		  a bulk URB is already queued to this endpoint and
+		  USB_QUEUE_BULK wasn't used (UHCI HCDs only)
 
 USB_ST_URB_INVALID_ERROR
 -EINVAL		a) Invalid transfer type specified (or not supported)
 		b) Invalid interrupt interval (0<=n<256)
 		c) more than one interrupt packet requested
+		d) ISO: number_of_packets is < 0
 
 -EAGAIN		a) specified ISO start frame too early
 		b) (using ISO-ASAP) too much scheduled for the future
@@ -38,6 +42,7 @@ USB_ST_URB_INVALID_ERROR
 
 -EFBIG		too much ISO frames requested (currently uhci>900)
 
+USB_ST_STALL
 -EPIPE		specified pipe-handle is already stalled
 
 -EMSGSIZE	endpoint message size is zero, do interface/alternate setting
@@ -59,7 +64,7 @@ USB_ST_NOERROR
 0			Transfer completed successfully
 
 USB_ST_URB_KILLED
--ENOENT			URB was canceled by unlink_urb
+-ENOENT			URB was canceled by usb_unlink_urb
 
 USB_ST_URB_PENDING
 -EINPROGRESS		URB still pending, no results yet
@@ -73,12 +78,28 @@ USB_ST_INTERNALERROR
 USB_ST_CRC
 -EILSEQ			CRC mismatch
 
+USB_ST_STALL
 -EPIPE			a) babble detect
 			b) endpoint stalled
 
-USB_ST_BUFFERUNDERRUN
--ENOST			buffer error
+USB_ST_BUFFEROVERRUN
+-ECOMM			During an IN transfer, the host controller
+			received data from an endpoint faster than it
+			could be written to system memory
 
+USB_ST_BUFFERUNDERRUN
+-ENOSR			During an OUT transfer, the host controller
+			could not retrieve data from system memory fast
+			enough to keep up with the USB data rate
+
+USB_ST_DATAOVERRUN
+-EOVERFLOW		The amount of data returned by the endpoint was
+			greater than either the max packet size of the
+			endpoint or the remaining buffer size
+
+USB_ST_DATAUNDERRUN
+-EREMOTEIO		The endpoint returned less than max packet size
+			and that amount did not fill the specified buffer
 USB_ST_NORESPONSE
 USB_ST_TIMEOUT
 -ETIMEDOUT		transfer timed out, NAK
@@ -104,14 +125,7 @@ USB_ST_URB_INVALID_ERROR
 **************************************************************************
 
 usb_register():
-USB_ST_NOTSUPPORTED
 -EINVAL			error during registering new driver
 
-usb_terminate_bulk():
-USB_ST_REMOVED
--ENODEV			urb already removed
-
 usb_get_*/usb_set_*():
 			All USB errors (submit/status) can occur
-
-
diff --git a/Documentation/usb/usb-help.txt b/Documentation/usb/usb-help.txt
index 5ad2aaa57..98ade189e 100644
--- a/Documentation/usb/usb-help.txt
+++ b/Documentation/usb/usb-help.txt
@@ -7,6 +7,7 @@ linux/Documentation/usb/*, see the following:
 Linux-USB project:  http://www.linux-usb.org
   mirrors at        http://www.suse.cz/development/linux-usb/
          and        http://usb.in.tum.de/linux-usb/
+         and        http://it.linux-usb.org
 Linux USB Guide:    http://linux-usb.sourceforge.net
 Linux-USB device overview (working devices and drivers):
                     http://www.qbik.ch/usb/devices/
diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt
index a6efeefa5..2fc5ac8eb 100644
--- a/Documentation/usb/usb-serial.txt
+++ b/Documentation/usb/usb-serial.txt
@@ -139,6 +139,9 @@ Digi AccelePort Driver
   (plus a parallel port) and 4 port USB serial converters.  The driver
   does NOT yet support the Digi AccelePort USB 8.
 
+  This driver works under SMP with the usb-uhci driver.  It does not
+  work under SMP with the uhci driver.
+
   The driver is generally working, though we still have a few more ioctls
   to implement and final testing and debugging to do.  The paralled port
   on the USB 2 is supported as a serial to parallel converter; in other
@@ -182,6 +185,33 @@ TO DO List:
   -- Add everything else that is missing :)
 
 
+Empeg empeg-car Mark I/II Driver (empeg.c)
+
+  This is an experimental driver to provide connectivity support for the
+  client synchronization tools for an Empeg empeg-car mp3 player.
+
+  Tips:
+
+    * Don't forget to create the device nodes for ttyUSB{0,1,2,...}
+    * modprobe empeg (modprobe is your friend)
+    * emptool --usb /dev/ttyUSB0 (or whatever you named your device node)
+
+  The driver is still pretty new, so some testing 'in the wild' would be
+  helpful. :)
+
+
+MCT USB Single Port Serial Adapter U232
+
+ This driver is for the MCT USB-RS232 Converter (25 pin, Model No.
+ U232-P25) from Magic Control Technology Corp. (there is also a 9 pin
+ Model No. U232-P9). More information about this device can be found
+ at the manufacture's web-site: http://www.mct.com.tw.
+
+ The driver is generally working, though it still needs some more
+ testing. It is derived from the Belkin USB Serial Adapter F5U103
+ driver and its TODO list is valid for this driver as well.
+
+
 Generic Serial driver
 
   If your device is not one of the above listed devices, compatible with