Merge suse.cz:/home/vojtech/bk/linus into suse.cz:/home/vojtech/bk/input

27 files changed, 3612 insertions, 614 deletions

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 8787c4d099a654..6ee3cd6134dfad 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -160,7 +160,7 @@ pci_set_dma_mask(struct pci_device *dev, u64 mask)
 Checks to see if the mask is possible and updates the device
 parameters if it is.
 
-Returns: 1 if successful and 0 if not
+Returns: 0 if successful and a negative error if not.
 
 u64
 dma_get_required_mask(struct device *dev)
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index 5f11984a04f391..ef66fdda129f2a 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -133,6 +133,11 @@ KAO -->
      <sect1><title>Socket Filter</title>
 !Enet/core/filter.c
      </sect1>
+     <sect1><title>Generic Network Statistics</title>
+!Iinclude/linux/gen_stats.h
+!Enet/core/gen_stats.c
+!Enet/core/gen_estimator.c
+     </sect1>
   </chapter>
 
   <chapter id="netdev">
diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl
index ac0d5fc0a211d0..92a405a0e36415 100644
--- a/Documentation/DocBook/libata.tmpl
+++ b/Documentation/DocBook/libata.tmpl
@@ -61,6 +61,196 @@
   </para>
   </chapter>
 
+  <chapter id="libataDriverApi">
+     <title>libata Driver API</title>
+     <sect1>
+        <title>struct ata_port_operations</title>
+
+	<programlisting>
+void (*port_disable) (struct ata_port *);
+	</programlisting>
+
+	<para>
+	Called from ata_bus_probe() and ata_bus_reset() error paths,
+	as well as when unregistering from the SCSI module (rmmod, hot
+	unplug).
+	</para>
+
+	<programlisting>
+void (*dev_config) (struct ata_port *, struct ata_device *);
+	</programlisting>
+
+	<para>
+	Called after IDENTIFY [PACKET] DEVICE is issued to each device
+	found.  Typically used to apply device-specific fixups prior to
+	issue of SET FEATURES - XFER MODE, and prior to operation.
+	</para>
+
+	<programlisting>
+void (*set_piomode) (struct ata_port *, struct ata_device *);
+void (*set_dmamode) (struct ata_port *, struct ata_device *);
+void (*post_set_mode) (struct ata_port *ap);
+	</programlisting>
+
+	<para>
+	Hooks called prior to the issue of SET FEATURES - XFER MODE
+	command.  dev->pio_mode is guaranteed to be valid when
+	->set_piomode() is called, and dev->dma_mode is guaranteed to be
+	valid when ->set_dmamode() is called.  ->post_set_mode() is
+	called unconditionally, after the SET FEATURES - XFER MODE
+	command completes successfully.
+	</para>
+
+	<para>
+	->set_piomode() is always called (if present), but
+	->set_dma_mode() is only called if DMA is possible.
+	</para>
+
+	<programlisting>
+void (*tf_load) (struct ata_port *ap, struct ata_taskfile *tf);
+void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf);
+	</programlisting>
+
+	<para>
+	->tf_load() is called to load the given taskfile into hardware
+	registers / DMA buffers.  ->tf_read() is called to read the
+	hardware registers / DMA buffers, to obtain the current set of
+	taskfile register values.
+	</para>
+
+	<programlisting>
+void (*exec_command)(struct ata_port *ap, struct ata_taskfile *tf);
+	</programlisting>
+
+	<para>
+	causes an ATA command, previously loaded with
+	->tf_load(), to be initiated in hardware.
+	</para>
+
+	<programlisting>
+u8   (*check_status)(struct ata_port *ap);
+void (*dev_select)(struct ata_port *ap, unsigned int device);
+	</programlisting>
+
+	<para>
+	Reads the Status ATA shadow register from hardware.  On some
+	hardware, this has the side effect of clearing the interrupt
+	condition.
+	</para>
+
+	<programlisting>
+void (*dev_select)(struct ata_port *ap, unsigned int device);
+	</programlisting>
+
+	<para>
+	Issues the low-level hardware command(s) that causes one of N
+	hardware devices to be considered 'selected' (active and
+	available for use) on the ATA bus.
+	</para>
+
+	<programlisting>
+void (*phy_reset) (struct ata_port *ap);
+	</programlisting>
+
+	<para>
+	The very first step in the probe phase.  Actions vary depending
+	on the bus type, typically.  After waking up the device and probing
+	for device presence (PATA and SATA), typically a soft reset
+	(SRST) will be performed.  Drivers typically use the helper
+	functions ata_bus_reset() or sata_phy_reset() for this hook.
+	</para>
+
+	<programlisting>
+void (*bmdma_setup) (struct ata_queued_cmd *qc);
+void (*bmdma_start) (struct ata_queued_cmd *qc);
+	</programlisting>
+
+	<para>
+	When setting up an IDE BMDMA transaction, these hooks arm
+	(->bmdma_setup) and fire (->bmdma_start) the hardware's DMA
+	engine.
+	</para>
+
+	<programlisting>
+void (*qc_prep) (struct ata_queued_cmd *qc);
+int (*qc_issue) (struct ata_queued_cmd *qc);
+	</programlisting>
+
+	<para>
+	Higher-level hooks, these two hooks can potentially supercede
+	several of the above taskfile/DMA engine hooks.  ->qc_prep is
+	called after the buffers have been DMA-mapped, and is typically
+	used to populate the hardware's DMA scatter-gather table.
+	Most drivers use the standard ata_qc_prep() helper function, but
+	more advanced drivers roll their own.
+	</para>
+	<para>
+	->qc_issue is used to make a command active, once the hardware
+	and S/G tables have been prepared.  IDE BMDMA drivers use the
+	helper function ata_qc_issue_prot() for taskfile protocol-based
+	dispatch.  More advanced drivers roll their own ->qc_issue
+	implementation, using this as the "issue new ATA command to
+	hardware" hook.
+	</para>
+
+	<programlisting>
+void (*eng_timeout) (struct ata_port *ap);
+	</programlisting>
+
+	<para>
+	This is a high level error handling function, called from the
+	error handling thread, when a command times out.
+	</para>
+
+	<programlisting>
+irqreturn_t (*irq_handler)(int, void *, struct pt_regs *);
+void (*irq_clear) (struct ata_port *);
+	</programlisting>
+
+	<para>
+	->irq_handler is the interrupt handling routine registered with
+	the system, by libata.  ->irq_clear is called during probe just
+	before the interrupt handler is registered, to be sure hardware
+	is quiet.
+	</para>
+
+	<programlisting>
+u32 (*scr_read) (struct ata_port *ap, unsigned int sc_reg);
+void (*scr_write) (struct ata_port *ap, unsigned int sc_reg,
+                   u32 val);
+	</programlisting>
+
+	<para>
+	Read and write standard SATA phy registers.  Currently only used
+	if ->phy_reset hook called the sata_phy_reset() helper function.
+	</para>
+
+	<programlisting>
+int (*port_start) (struct ata_port *ap);
+void (*port_stop) (struct ata_port *ap);
+void (*host_stop) (struct ata_host_set *host_set);
+	</programlisting>
+
+	<para>
+	->port_start() is called just after the data structures for each
+	port are initialized.  Typically this is used to alloc per-port
+	DMA buffers / tables / rings, enable DMA engines, and similar
+	tasks.  
+	</para>
+	<para>
+	->host_stop() is called when the rmmod or hot unplug process
+	begins.  The hook must stop all hardware interrupts, DMA
+	engines, etc.
+	</para>
+	<para>
+	->port_stop() is called after ->host_stop().  It's sole function
+	is to release DMA/memory resources, now that they are no longer
+	actively being used.
+	</para>
+
+     </sect1>
+  </chapter>
+
   <chapter id="libataExt">
      <title>libata Library</title>
 !Edrivers/scsi/libata-core.c
@@ -83,7 +273,7 @@
   </chapter>
 
   <chapter id="SILInt">
-     <title>ata_sil Internals</title>
+     <title>sata_sil Internals</title>
 !Idrivers/scsi/sata_sil.c
   </chapter>
 
diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
index a851d039ad01b9..fad566bb02fc8f 100644
--- a/Documentation/arm/Booting
+++ b/Documentation/arm/Booting
@@ -118,6 +118,10 @@ to store page tables.  The recommended placement is 32KiB into RAM.
 
 In either case, the following conditions must be met:
 
+- Quiesce all DMA capable devicess so that memory does not get
+  corrupted by bogus network packets or disk data. This will save
+  you many hours of debug.
+
 - CPU register settings
   r0 = 0,
   r1 = machine type number discovered in (3) above.
diff --git a/Documentation/arm/IXP2000 b/Documentation/arm/IXP2000
index 48ba502fa598f9..969f165932f250 100644
--- a/Documentation/arm/IXP2000
+++ b/Documentation/arm/IXP2000
@@ -18,7 +18,7 @@ http://developer.intel.com/design/network/products/npfamily/ixp2xxx.htm
 
 2. Linux Support
 
-Linux currently supports the following features on the IXP2000 NPUS:
+Linux currently supports the following features on the IXP2000 NPUs:
 
 - On-chip serial
 - PCI
@@ -30,10 +30,10 @@ That is about all we can support under Linux ATM b/c the core networking
 components of the chip are accessed via Intel's closed source SDK. 
 Please contact Intel directly on issues with using those. There is
 also a mailing list run by some folks at Princeton University that might
-be of helpful:  https://lists.cs.princeton.edu/mailman/listinfo/ixp2xxx
+be of help:  https://lists.cs.princeton.edu/mailman/listinfo/ixp2xxx
 
 WHATEVER YOU DO, DO NOT POST EMAIL TO THE LINUX-ARM OR LINUX-ARM-KERNEL
-MAILINNG LISTS REGARDING THE INTEL SDK.
+MAILING LISTS REGARDING THE INTEL SDK.
 
 3. Supported Platforms
 
@@ -47,12 +47,12 @@ MAILINNG LISTS REGARDING THE INTEL SDK.
 
 - The IXP2000 platforms ususally have rather complex PCI bus topologies
   with large memory space requirements. In addition, b/c of the way the
-  Intel SDK is designed, devices are enumerated in a vert specific
+  Intel SDK is designed, devices are enumerated in a very specific
   way. B/c of this this, we use "pci=firmware" option in the kernel
   command line so that we do not re-enumerate the bus.
 
 - IXDP2x01 systems have variable clock tick rates that we cannot determine 
-  via HW registers. The "ixdp2x01_clk=XXX" cmd line options allows you
+  via HW registers. The "ixdp2x01_clk=XXX" cmd line options allow you
   to pass the clock rate to the board port.
 
 5. Thanks
diff --git a/Documentation/arm/IXP4xx b/Documentation/arm/IXP4xx
index d86d818a492d85..2e1590b42fff21 100644
--- a/Documentation/arm/IXP4xx
+++ b/Documentation/arm/IXP4xx
@@ -122,6 +122,15 @@ http://developer.intel.com/design/network/products/npfamily/ixdp425.htm
    also known as the Richfield board. It contains 4 PCI slots, 16MB
    of flash, two 10/100 ports and one ADSL port.
 
+Intel IXDPG425 Development Platform
+
+   This is basically and ADI Coyote board with a NEC EHCI controller
+   added. One issue with this board is that the mini-PCI slots only
+   have the 3.3v line connected, so you can't use a PCI to mini-PCI
+   adapter with an E100 card. So to NFS root you need to use either
+   the CSR or a WiFi card and a ramdisk that BOOTPs and then does
+   a pivot_root to NFS.
+
 Motorola PrPMC1100 Processor Mezanine Card
 http://www.fountainsys.com/datasheet/PrPMC1100.pdf
 
@@ -152,4 +161,4 @@ Robert E. Ranslam
 
 -------------------------------------------------------------------------
 
-Last Update: 5/13/2004
+Last Update: 11/16/2004
diff --git a/Documentation/arm/README b/Documentation/arm/README
index 1dd5d6cb76e4d1..a6f718e90a8687 100644
--- a/Documentation/arm/README
+++ b/Documentation/arm/README
@@ -163,9 +163,9 @@ CONFIG_MACH_ and CONFIG_ARCH_
 
     <http://www.arm.linux.org.uk/developer/machines/>
 
-Kernel entry (head-armv.S)
+Kernel entry (head.S)
 --------------------------
-  The initial entry into the kernel is via head-armv.S, which uses machine
+  The initial entry into the kernel is via head.S, which uses machine
   independent code.  The machine is selected by the value of 'r1' on
   entry, which must be kept unique.
 
diff --git a/Documentation/arm/Sharp-LH/IOBarrier b/Documentation/arm/Sharp-LH/IOBarrier
index bf34e046ea10bf..c0d8853672dc9e 100644
--- a/Documentation/arm/Sharp-LH/IOBarrier
+++ b/Documentation/arm/Sharp-LH/IOBarrier
@@ -5,7 +5,7 @@ Due to an unfortunate oversight when the Card Engines were designed,
 the signals that control access to some peripherals, most notably the
 SMC91C9111 ethernet controller, are not properly handled.
 
-The symptom is that back to back IO with the peripheral returns
+The symptom is that some back to back IO with the peripheral returns
 unreliable data.  With the SMC chip, you'll see errors about the bank
 register being 'screwed'.
 
@@ -13,20 +13,33 @@ The cause is that the AEN signal to the SMC chip does not transition
 for every memory access.  It is driven through the CPLD from the CS7
 line of the CPU's static memory controller which is optimized to
 eliminate unnecessary transitions.  Yet, the SMC requires a transition
-for every access.  The Sharp website has more information on the
-effect of this power conservation feature on peripheral interfacing.
+for every write access.  The Sharp website has more information about
+the effect this power-conserving feature has on peripheral
+interfacing.
 
-The solution is to follow every access to the SMC chip with an access
-to another memory region that will force the CPU to release the chip
-select line.  Note that it is important to guarantee that the access
-will force the CPU off-chip.  We map a page of SDRAM as if it were an
-uncacheable IO device and read from it after every SMC IO operation.
+The solution is to follow every write access to the SMC chip with an
+access to another memory region that will force the CPU to release the
+chip select line.  It is important to guarantee that this access
+forces the CPU off-chip.  We map a page of SDRAM as if it were an
+uncacheable IO device and read from it after every SMC IO write
+operation.
 
   SMC IO
   BARRIER IO
 
-You might be tempted to believe that we must access another device
+Only this sequence is important.  It does not matter that there is no
+BARRIER IO before the access to the SMC chip because the AEN latch
+only needs occurs after the SMC IO write cycle.  The routines that
+implement this work-around make an additional concession which is to
+disable interrupts during the IO sequence.  Other hardware devices
+(the LogicPD CPLD) have registers in the same the physical memory
+region as the SMC chip.  An interrupt might allow an access to one of
+those registers while SMC IO is being performed.
+
+You might be tempted to think that we have to access another device
 attached to the static memory controller, but the empirical evidence
 indicates that this is not so.  Mapping 0x00000000 (flash) and
 0xc0000000 (SDRAM) appear to have the same effect.  Using SDRAM seems
-to be faster.
+to be faster.  Choosing to access an undecoded memory region is not
+desirable as there is no way to know how that chip select will be used
+in the future.
diff --git a/Documentation/dvb/README.dibusb b/Documentation/dvb/README.dibusb
index d6449ec80999da..e3d650b814dcc8 100644
--- a/Documentation/dvb/README.dibusb
+++ b/Documentation/dvb/README.dibusb
@@ -1,43 +1,91 @@
+Documentation for dib3000mb frontend driver and dibusb device driver
+====================================================================
 
+Copyright (C) 2004 Patrick Boettcher (patrick.boettcher@desy.de),
 
-Documentation for dib3000mb frontend driver and dibusb device driver
+dibusb and dib3000mb/mc drivers based on GPL code, which has
+
+Copyright (C) 2004 Amaury Demol for DiBcom (ademol@dibcom.fr)
 
-The drivers should work with
+This program is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License as
+published by the Free Software Foundation, version 2.
 
-- Twinhan VisionPlus VisionDTV USB-Ter DVB-T Device (VP7041)
-	http://www.twinhan.com/
 
-- CTS Portable (Chinese Television System)
-	http://www.2cts.tv/ctsportable/
+Supported devices USB1.1
+========================
 
-- KWorld V-Stream XPERT DTV - DVB-T USB
-	http://www.kworld.com.tw/asp/pindex.asp?id=4&pid=13
+Produced and reselled by Twinhan:
+---------------------------------
+- TwinhanDTV USB-Ter DVB-T Device (VP7041)
+	http://www.twinhan.com/product_terrestrial_3.asp
+
+- TwinhanDTV Magic Box (VP7041e)
+	http://www.twinhan.com/product_terrestrial_4.asp
 
 - HAMA DVB-T USB device
 	http://www.hama.de/portal/articleId*110620/action*2598
 
-- DiBcom USB DVB-T reference device
+- CTS Portable (Chinese Television System)
+	http://www.2cts.tv/ctsportable/
+
+- Unknown USB DVB-T device with vendor ID Hyper-Paltek
+
+
+Produced and reselled by KWorld:
+--------------------------------
+- KWorld V-Stream XPERT DTV DVB-T USB
+	http://www.kworld.com.tw/en/product/DVBT-USB/DVBT-USB.html
+
+- JetWay DTV DVB-T USB
+	http://www.jetway.com.tw/evisn/product/lcd-tv/DVT-USB/dtv-usb.htm
+
+- ADSTech Instant TV DVB-T USB
+	http://www.adstech.com/products/PTV-333/intro/PTV-333_intro.asp?pid=PTV-333
 
-- Ultima Electronic/Artec T1 USB TVBOX
-	http://www.arteceuro.com/products-tvbox.html
+
+Others:
+-------
+- Ultima Electronic/Artec T1 USB TVBOX (AN2135 and AN2235)
+	http://82.161.246.249/products-tvbox.html
 
 - Compro Videomate DVB-U2000 - DVB-T USB
 	http://www.comprousa.com/products/vmu2000.htm
 
-- Unknown USB DVB-T device with vendor ID Hyper-Paltek
+- Grandtec USB DVB-T
+	http://www.grand.com.tw/
 
-Copyright (C) 2004 Patrick Boettcher (patrick.boettcher@desy.de),
+- Avermedia AverTV DVBT USB
+	http://www.avermedia.com/
 
-both drivers based on GPL code, which has
+- DiBcom USB DVB-T reference device (non-public)
 
-Copyright (C) 2004 Amaury Demol for DiBcom (ademol@dibcom.fr)
 
-This program is free software; you can redistribute it and/or
-modify it under the terms of the GNU General Public License as
-published by the Free Software Foundation, version 2.
+Supported devices USB2.0
+========================
+- Twinhan MagicBox II
+	http://www.twinhan.com/product_terrestrial_7.asp
+
+- Yakumo DVB-T mobile
+	http://www.yakumo.de/produkte/index.php?pid=1&ag=DVB-T
+
+- DiBcom USB2.0 DVB-T reference device (non-public)
 
 
-NEWS:
+0. NEWS:
+  2004-12-06 - possibility for demod i2c-address probing
+             - new usb IDs (Compro,Artec)
+  2004-11-23 - merged changes from DiB3000MC_ver2.1
+             - revised the debugging
+             - possibility to deliver the complete TS for USB2.0
+  2004-11-21 - first working version of the dib3000mc/p frontend driver.
+  2004-11-12 - added additional remote control keys. Thanks to Uwe Hanke.
+  2004-11-07 - added remote control support. Thanks to David Matthews.
+  2004-11-05 - added support for a new devices (Grandtec/Avermedia/Artec)
+             - merged my changes (for dib3000mb/dibusb) to the FE_REFACTORING, because it became HEAD
+             - moved transfer control (pid filter, fifo control) from usb driver to frontend, it seems
+               better settled there (added xfer_ops-struct)
+             - created a common files for frontends (mc/p/mb)
   2004-09-28 - added support for a new device (Unkown, vendor ID is Hyper-Paltek)
   2004-09-20 - added support for a new device (Compro DVB-U2000), thanks
                to Amaury Demol for reporting
@@ -49,7 +97,7 @@ NEWS:
 
   (old news for vp7041.c)
   2004-07-15 - found out, by accident, that the device has a TUA6010XS for
-               frequency generator
+               PLL
   2004-07-12 - figured out, that the driver should also work with the
                CTS Portable (Chinese Television System)
   2004-07-08 - firmware-extraction-2.422-problem solved, driver is now working
@@ -67,7 +115,7 @@ NEWS:
 
 1. How to use?
 NOTE: This driver was developed using Linux 2.6.6.,
-it is working with 2.6.7, 2.6.8.1.
+it is working with 2.6.7, 2.6.8.1, 2.6.9 .
 
 Linux 2.4.x support is not planned, but patches are very welcome.
 
@@ -81,8 +129,15 @@ The USB driver needs to download a firmware to start working.
 You can either use "get_dvb_firmware dibusb" to download the firmware or you
 can get it directly via
 
+for USB1.1 (AN2135)
 http://linuxtv.org/cgi-bin/cvsweb.cgi/dvb-kernel/firmware/dvb-dibusb-5.0.0.11.fw?rev=1.1&content-type=text/plain
 
+for USB1.1 (AN2235) (a few Artec T1 devices)
+http://linuxtv.org/cgi-bin/cvsweb.cgi/dvb-kernel/firmware/dvb-dibusb-an2235-1.fw?rev=1.1&content-type=text/plain
+
+for USB2.0 (FX2)
+http://linuxtv.org/cgi-bin/cvsweb.cgi/dvb-kernel/firmware/dvb-dibusb-6.0.0.5.fw?rev=1.1&content-type=text/plain
+
 1.2. Compiling
 
 Since the driver is in the linux kernel, activating the driver in
@@ -94,15 +149,16 @@ to compile the driver as module. Hotplug does the rest.
 Hotplug is able to load the driver, when it is needed (because you plugged
 in the device).
 
-If you want to enable debug output, you have to load the driver manually.
+If you want to enable debug output, you have to load the driver manually and
+from withing the dvb-kernel cvs repository.
 
 first have a look, which debug level are available:
 
-modinfo dvb-dibusb
 modinfo dib3000mb
+modinfo dvb-dibusb
 
-modprobe dvb-dibusb debug=<level> 
 modprobe dib3000mb debug=<level>
+modprobe dvb-dibusb debug=<level>
 
 should do the trick.
 
@@ -118,21 +174,17 @@ as a slave device in vdr, was not working for me. Some work has to be done
 2. Known problems and bugs
 
 TODO:
-- remote control tasklet
 - signal-quality and strength calculations
-- debug messages restructure
-- i2c address probing
-- 
 
 2.1. Adding support for devices 
 
 It is not possible to determine the range of devices based on the DiBcom
-reference design. This is because the reference design of DiBcom can be sold
-to third persons, without telling DiBcom (so done with the Twinhan VP7041 and
+reference designs. This is because the reference design of DiBcom can be sold
+to thirds, without telling DiBcom (so done with the Twinhan VP7041 and
 the HAMA device).
 
 When you think you have a device like this and the driver does not recognizes it,
-please send the ****load.inf and the ****cap.inf of the Windows driver to me.
+please send the ****load*.inf and the ****cap*.inf of the Windows driver to me.
 
 Sometimes the Vendor or Product ID is identical to the ones of Twinhan, even
 though it is not a Twinhan device (e.g. HAMA), then please send me the name
@@ -144,7 +196,29 @@ the dvb-dibusb.h-file and create a patch and send it over to me or to
 the linux-dvb mailing list, _after_ you have tried compiling and modprobing
 it.
 
-2.2. Comments
+2.2. USB1.1 Bandwidth limitation
+
+Most of the current supported devices are USB1.1 and thus they have a
+maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub.
+This is not enough for receiving the complete transport stream of a
+DVB-T channel (which can be about 16 MBit/s). Normally this is not a
+problem, if you only want to watch TV, but watching a channel while
+recording another channel on the same frequency simply does not work.
+This applies to all USB1.1 DVB-T devices.
+
+A special problem of the dibusb for the USB1.1 is, that the USB control
+IC has a problem with write accesses while having MPEG2-streaming
+enabled. When you set another pid while receiving MPEG2-TS it happens, that
+the stream is disturbed and probably data is lost (results in distortions of
+the video or strange beeps within the audio stream). DiBcom is preparing a
+firmware especially for Linux which perhaps solves the problem.
+
+Especially VDR users are victoms of this bug. VDR frequently requests new PIDs
+due the automatic scanning (introduced in 1.3.x, afaik) and epg-scan. Disabling
+these features is maybe a solution. Additionally this behaviour of VDR exceeds
+the USB1.1 bandwidth.
+
+2.3. Comments
 
 Patches, comments and suggestions are very very welcome
 
@@ -153,6 +227,9 @@ Patches, comments and suggestions are very very welcome
 	providing specs, code and help, on which the dvb-dibusb and dib3000mb are
 	based.
 
+   David Matthews for identifying a new device type (Artec T1 with AN2235)
+    and for extending dibusb with remote control event handling. Thank you.
+
    Alex Woods for frequently answering question about usb and dvb
     stuff, a big thank you
 
diff --git a/Documentation/dvb/cards.txt b/Documentation/dvb/cards.txt
index 43e1a8a9788195..efdc4ee9d40c11 100644
--- a/Documentation/dvb/cards.txt
+++ b/Documentation/dvb/cards.txt
@@ -38,7 +38,7 @@ o Frontends drivers:
                		  Comtech DVBT-6k07 (SP5730 PLL)
                		  (NxtWave Communications NXT6000 demodulator)
    - sp887x		: Microtune 7202D
-   - dib3000mb	: DiBcom 3000-MB Frontend
+   - dib3000mb	: DiBcom 3000-MB demodulator
   DVB-S/C/T:
    - dst		: TwinHan DST Frontend
 
@@ -69,7 +69,17 @@ o Technotrend / Hauppauge DVB USB devices:
 
 o DiBcom DVB-T USB based devices:
   - Twinhan VisionPlus VisionDTV USB-Ter DVB-T Device
-  - KWorld V-Stream XPERT DTV - DVB-T USB
   - HAMA DVB-T USB device
+  - CTS Portable (Chinese Television System)
+  - KWorld V-Stream XPERT DTV DVB-T USB
+  - JetWay DTV DVB-T USB
+  - ADSTech Instant TV DVB-T USB
+  - Ultima Electronic/Artec T1 USB TVBOX (AN2135 and AN2235)
+  - Compro Videomate DVB-U2000 - DVB-T USB
+  - Grandtec USB DVB-T
+  - Avermedia AverTV DVBT USB
+  - DiBcom USB DVB-T reference device (non-public)
+  - Yakumo DVB-T mobile USB2.0
+  - DiBcom USB2.0 DVB-T reference device (non-public)
 
 o Experimental support for the analog module of the Siemens DVB-C PCI card
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index f3a8fef9819266..e9964b71e12453 100644
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -21,7 +21,7 @@
 use File::Temp qw/ tempdir /;
 use IO::Handle;
 
-@components = ( "alps_tdlb7", "sp887x", "tda10045", "tda10046", "av7110", "dec2000t", "dec2540t", "dec3000s", "vp7041", "dibusb" );
+@components = ( "sp8870", "sp887x", "tda10045", "tda10046", "av7110", "dec2000t", "dec2540t", "dec3000s", "vp7041", "dibusb" );
 
 # Check args
 syntax() if (scalar(@ARGV) != 1);
@@ -32,7 +32,7 @@ for($i=0; $i < scalar(@components); $i++) {
     if ($cid eq $components[$i]) {
 	$outfile = eval($cid);
 	die $@ if $@;
-	print STDERR "Firmware $outfile extracted successfully. Now copy it to /usr/lib/hotplug/firmware/.\n";
+	print STDERR "Firmware $outfile extracted successfully. Now copy it to either /lib/firmware or /usr/lib/hotplug/firmware/ (depending on your hotplug version).\n";
 	exit(0);
     }
 }
@@ -47,11 +47,11 @@ syntax();
 # ---------------------------------------------------------------
 # Firmware-specific extraction subroutines
 
-sub alps_tdlb7 {
+sub sp8870 {
     my $sourcefile = "tt_Premium_217g.zip";
     my $url = "http://www.technotrend.de/new/217g/$sourcefile";
     my $hash = "53970ec17a538945a6d8cb608a7b3899";
-    my $outfile = "dvb-fe-tdlb7.fw";
+    my $outfile = "dvb-fe-sp8870.fw";
     my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
 
     checkstandard();
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index b182423fdbb6f6..011e92094c028d 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -676,14 +676,26 @@ SMBus communication
   extern s32 i2c_smbus_read_word_data(struct i2c_client * client, u8 command);
   extern s32 i2c_smbus_write_word_data(struct i2c_client * client,
                                        u8 command, u16 value);
-  extern s32 i2c_smbus_process_call(struct i2c_client * client,
-                                    u8 command, u16 value);
-  extern s32 i2c_smbus_read_block_data(struct i2c_client * client,
-                                       u8 command, u8 *values);
   extern s32 i2c_smbus_write_block_data(struct i2c_client * client,
                                         u8 command, u8 length,
                                         u8 *values);
 
+These ones were removed in Linux 2.6.10 because they had no users, but could
+be added back later if needed:
+
+  extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client,
+                                           u8 command, u8 *values);
+  extern s32 i2c_smbus_read_block_data(struct i2c_client * client,
+                                       u8 command, u8 *values);
+  extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client,
+                                            u8 command, u8 length,
+                                            u8 *values);
+  extern s32 i2c_smbus_process_call(struct i2c_client * client,
+                                    u8 command, u16 value);
+  extern s32 i2c_smbus_block_process_call(struct i2c_client *client,
+                                          u8 command, u8 length,
+                                          u8 *values)
+
 All these transactions return -1 on failure. The 'write' transactions 
 return 0 on success; the 'read' transactions return the read value, except 
 for read_block, which returns the number of values read. The block buffers 
diff --git a/Documentation/ia64/serial.txt b/Documentation/ia64/serial.txt
new file mode 100644
index 00000000000000..f51eb4bc2ff1e1
--- /dev/null
+++ b/Documentation/ia64/serial.txt
@@ -0,0 +1,144 @@
+SERIAL DEVICE NAMING
+
+    As of 2.6.10, serial devices on ia64 are named based on the
+    order of ACPI and PCI enumeration.  The first device in the
+    ACPI namespace (if any) becomes /dev/ttyS0, the second becomes
+    /dev/ttyS1, etc., and PCI devices are named sequentially
+    starting after the ACPI devices.
+
+    Prior to 2.6.10, there were confusing exceptions to this:
+
+	- Firmware on some machines (mostly from HP) provides an HCDP
+	  table[1] that tells the kernel about devices that can be used
+	  as a serial console.  If the user specified "console=ttyS0"
+	  or the EFI ConOut path contained only UART devices, the
+	  kernel registered the device described by the HCDP as
+	  /dev/ttyS0.
+
+	- If there was no HCDP, we assumed there were UARTs at the
+	  legacy COM port addresses (I/O ports 0x3f8 and 0x2f8), so
+	  the kernel registered those as /dev/ttyS0 and /dev/ttyS1.
+
+    Any additional ACPI or PCI devices were registered sequentially
+    after /dev/ttyS0 as they were discovered.
+
+    With an HCDP, device names changed depending on EFI configuration
+    and "console=" arguments.  Without an HCDP, device names didn't
+    change, but we registered devices that might not really exist.
+
+    For example, an HP rx1600 with a single built-in serial port
+    (described in the ACPI namespace) plus an MP[2] (a PCI device) has
+    these ports:
+
+                                  pre-2.6.10      pre-2.6.10
+                    MMIO         (EFI console    (EFI console
+                   address        on builtin)     on MP port)    2.6.10
+                  ==========      ==========      ==========     ======
+      builtin     0xff5e0000        ttyS0           ttyS1         ttyS0
+      MP UPS      0xf8031000        ttyS1           ttyS2         ttyS1
+      MP Console  0xf8030000        ttyS2           ttyS0         ttyS2
+      MP 2        0xf8030010        ttyS3           ttyS3         ttyS3
+      MP 3        0xf8030038        ttyS4           ttyS4         ttyS4
+
+CONSOLE SELECTION
+
+    EFI knows what your console devices are, but it doesn't tell the
+    kernel quite enough to actually locate them.  The DIG64 HCDP
+    table[1] does tell the kernel where potential serial console
+    devices are, but not all firmware supplies it.  Also, EFI supports
+    multiple simultaneous consoles and doesn't tell the kernel which
+    should be the "primary" one.
+
+    So how do you tell Linux which console device to use?
+
+	- If your firmware supplies the HCDP, it is simplest to
+	  configure EFI with a single device (either a UART or a VGA
+	  card) as the console.  Then you don't need to tell Linux
+	  anything; the kernel will automatically use the EFI console.
+
+	  (This works only in 2.6.6 or later; prior to that you had
+	  to specify "console=ttyS0" to get a serial console.)
+
+	- Without an HCDP, Linux defaults to a VGA console unless you
+	  specify a "console=" argument.
+
+    NOTE: Don't assume that a serial console device will be /dev/ttyS0.
+    It might be ttyS1, ttyS2, etc.  Make sure you have the appropriate
+    entries in /etc/inittab (for getty) and /etc/securetty (to allow
+    root login).
+
+EARLY SERIAL CONSOLE
+
+    The kernel can't start using a serial console until it knows where
+    the device lives.  Normally this happens when the driver enumerates
+    all the serial devices, which can happen a minute or more after the
+    kernel starts booting.
+
+    2.6.10 and later kernels have an "early uart" driver that works
+    very early in the boot process.  The kernel will automatically use
+    this if the user supplies an argument like "console=uart,io,0x3f8",
+    or if the EFI console path contains only a UART device and the
+    firmware supplies an HCDP.
+
+TROUBLESHOOTING SERIAL CONSOLE PROBLEMS
+
+    No kernel output after elilo prints "Uncompressing Linux... done":
+
+	- You specified "console=ttyS0" but Linux changed the device
+	  to which ttyS0 refers.  Configure exactly one EFI console
+	  device[3] and remove the "console=" option.
+
+	- The EFI console path contains both a VGA device and a UART.
+	  EFI and elilo use both, but Linux defaults to VGA.  Remove
+	  the VGA device from the EFI console path[3].
+
+	- Multiple UARTs selected as EFI console devices.  EFI and
+	  elilo use all selected devices, but Linux uses only one.
+	  Make sure only one UART is selected in the EFI console
+	  path[3].
+
+	- You're connected to an HP MP port[2] but have a non-MP UART
+	  selected as EFI console device.  EFI uses the MP as a
+	  console device even when it isn't explicitly selected.
+	  Either move the console cable to the non-MP UART, or change
+	  the EFI console path[3] to the MP UART.
+
+    Long pause (60+ seconds) between "Uncompressing Linux... done" and
+    start of kernel output:
+
+	- No early console because you used "console=ttyS<n>".  Remove
+	  the "console=" option if your firmware supplies an HCDP.
+
+	- If you don't have an HCDP, the kernel doesn't know where
+	  your console lives until the driver discovers serial
+	  devices.  Use "console=uart, io,0x3f8" (or appropriate
+	  address for your machine).
+
+    Kernel and init script output works fine, but no "login:" prompt:
+
+	- Add getty entry to /etc/inittab for console tty.  Look for
+	  the "Adding console on ttyS<n>" message that tells you which
+	  device is the console.
+
+    "login:" prompt, but can't login as root:
+
+	- Add entry to /etc/securetty for console tty.
+
+
+
+[1] http://www.dig64.org/specifications/DIG64_PCDPv20.pdf
+    The table was originally defined as the "HCDP" for "Headless
+    Console/Debug Port."  The current version is the "PCDP" for
+    "Primary Console and Debug Port Devices."
+
+[2] The HP MP (management processor) is a PCI device that provides
+    several UARTs.  One of the UARTs is often used as a console; the
+    EFI Boot Manager identifies it as "Acpi(HWP0002,700)/Pci(...)/Uart".
+    The external connection is usually a 25-pin connector, and a
+    special dongle converts that to three 9-pin connectors, one of
+    which is labelled "Console."
+
+[3] EFI console devices are configured using the EFI Boot Manager
+    "Boot option maintenance" menu.  You may have to interrupt the
+    boot sequence to use this menu, and you will have to reset the
+    box after changing console configuration.
diff --git a/Documentation/ioctl/cdrom.txt b/Documentation/ioctl/cdrom.txt
new file mode 100644
index 00000000000000..4ccdcc6fe36459
--- /dev/null
+++ b/Documentation/ioctl/cdrom.txt
@@ -0,0 +1,966 @@
+		Summary of CDROM ioctl calls.
+		============================
+
+		Edward A. Falk <efalk@google.com>
+
+		November, 2004
+
+This document attempts to describe the ioctl(2) calls supported by
+the CDROM layer.  These are by-and-large implemented (as of Linux 2.6)
+in drivers/cdrom/cdrom.c and drivers/block/scsi_ioctl.c
+
+ioctl values are listed in <linux/cdrom.h>.  As of this writing, they
+are as follows:
+
+	CDROMPAUSE		Pause Audio Operation
+	CDROMRESUME		Resume paused Audio Operation
+	CDROMPLAYMSF		Play Audio MSF (struct cdrom_msf)
+	CDROMPLAYTRKIND		Play Audio Track/index (struct cdrom_ti)
+	CDROMREADTOCHDR		Read TOC header (struct cdrom_tochdr)
+	CDROMREADTOCENTRY	Read TOC entry (struct cdrom_tocentry)
+	CDROMSTOP		Stop the cdrom drive
+	CDROMSTART		Start the cdrom drive
+	CDROMEJECT		Ejects the cdrom media
+	CDROMVOLCTRL		Control output volume (struct cdrom_volctrl)
+	CDROMSUBCHNL		Read subchannel data (struct cdrom_subchnl)
+	CDROMREADMODE2		Read CDROM mode 2 data (2336 Bytes)
+					   (struct cdrom_read)
+	CDROMREADMODE1		Read CDROM mode 1 data (2048 Bytes)
+					   (struct cdrom_read)
+	CDROMREADAUDIO		(struct cdrom_read_audio)
+	CDROMEJECT_SW		enable(1)/disable(0) auto-ejecting
+	CDROMMULTISESSION	Obtain the start-of-last-session
+				  address of multi session disks
+				  (struct cdrom_multisession)
+	CDROM_GET_MCN		Obtain the "Universal Product Code"
+				   if available (struct cdrom_mcn)
+	CDROM_GET_UPC		Deprecated, use CDROM_GET_MCN instead.
+	CDROMRESET		hard-reset the drive
+	CDROMVOLREAD		Get the drive's volume setting
+					  (struct cdrom_volctrl)
+	CDROMREADRAW		read data in raw mode (2352 Bytes)
+					   (struct cdrom_read)
+	CDROMREADCOOKED		read data in cooked mode
+	CDROMSEEK		seek msf address
+	CDROMPLAYBLK		scsi-cd only, (struct cdrom_blk)
+	CDROMREADALL		read all 2646 bytes
+	CDROMGETSPINDOWN	return 4-bit spindown value
+	CDROMSETSPINDOWN	set 4-bit spindown value
+	CDROMCLOSETRAY		pendant of CDROMEJECT
+	CDROM_SET_OPTIONS	Set behavior options
+	CDROM_CLEAR_OPTIONS	Clear behavior options
+	CDROM_SELECT_SPEED	Set the CD-ROM speed
+	CDROM_SELECT_DISC	Select disc (for juke-boxes)
+	CDROM_MEDIA_CHANGED	Check is media changed
+	CDROM_DRIVE_STATUS	Get tray position, etc.
+	CDROM_DISC_STATUS	Get disc type, etc.
+	CDROM_CHANGER_NSLOTS	Get number of slots
+	CDROM_LOCKDOOR		lock or unlock door
+	CDROM_DEBUG		Turn debug messages on/off
+	CDROM_GET_CAPABILITY	get capabilities
+	CDROMAUDIOBUFSIZ	set the audio buffer size
+	DVD_READ_STRUCT		Read structure
+	DVD_WRITE_STRUCT	Write structure
+	DVD_AUTH		Authentication
+	CDROM_SEND_PACKET	send a packet to the drive
+	CDROM_NEXT_WRITABLE	get next writable block
+	CDROM_LAST_WRITTEN	get last block written on disc
+
+
+The information that follows was determined from reading kernel source
+code.  It is likely that some corrections will be made over time.
+
+
+
+
+
+
+
+General:
+
+	Unless otherwise specified, all ioctl calls return 0 on success
+	and -1 with errno set to an appropriate value on error.  (Some
+	ioctls return non-negative data values.)
+
+	Unless otherwise specified, all ioctl calls return -1 and set
+	errno to EFAULT on a failed attempt to copy data to or from user
+	address space.
+
+	Individual drivers may return error codes not listed here.
+
+	Unless otherwise specified, all data structures and constants
+	are defined in <linux/cdrom.h>
+
+
+
+
+CDROMPAUSE			Pause Audio Operation
+
+	usage:
+
+	  ioctl(fd, CDROMPAUSE, 0);
+
+	inputs:		none
+
+	outputs:	none
+
+	error return:
+	  ENOSYS	cd drive not audio-capable.
+
+
+CDROMRESUME			Resume paused Audio Operation
+
+	usage:
+
+	  ioctl(fd, CDROMRESUME, 0);
+
+	inputs:		none
+
+	outputs:	none
+
+	error return:
+	  ENOSYS	cd drive not audio-capable.
+
+
+CDROMPLAYMSF			Play Audio MSF (struct cdrom_msf)
+
+	usage:
+
+	  struct cdrom_msf msf;
+	  ioctl(fd, CDROMPLAYMSF, &msf);
+
+	inputs:
+	  cdrom_msf structure, describing a segment of music to play
+
+	outputs:	none
+
+	error return:
+	  ENOSYS	cd drive not audio-capable.
+
+	notes:
+	  MSF stands for minutes-seconds-frames
+	  LBA stands for logical block address
+
+	  Segment is described as start and end times, where each time
+	  is described as minutes:seconds:frames.  A frame is 1/75 of
+	  a second.
+
+
+CDROMPLAYTRKIND			Play Audio Track/index (struct cdrom_ti)
+
+	usage:
+
+	  struct cdrom_ti ti;
+	  ioctl(fd, CDROMPLAYTRKIND, &ti);
+
+	inputs:
+	  cdrom_ti structure, describing a segment of music to play
+
+	outputs:	none
+
+	error return:
+	  ENOSYS	cd drive not audio-capable.
+
+	notes:
+	  Segment is described as start and end times, where each time
+	  is described as a track and an index.
+
+
+
+CDROMREADTOCHDR			Read TOC header (struct cdrom_tochdr)
+
+	usage:
+
+	  cdrom_tochdr header;
+	  ioctl(fd, CDROMREADTOCHDR, &header);
+
+	inputs:
+	  cdrom_tochdr structure
+
+	outputs:
+	  cdrom_tochdr structure
+
+	error return:
+	  ENOSYS	cd drive not audio-capable.
+
+
+
+CDROMREADTOCENTRY		Read TOC entry (struct cdrom_tocentry)
+
+	usage:
+
+	  struct cdrom_tocentry entry;
+	  ioctl(fd, CDROMREADTOCENTRY, &entry);
+
+	inputs:
+	  cdrom_tocentry structure
+
+	outputs:
+	  cdrom_tocentry structure
+
+	error return:
+	  ENOSYS	cd drive not audio-capable.
+	  EINVAL	entry.cdte_format not CDROM_MSF or CDROM_LBA
+	  EINVAL	requested track out of bounds
+	  EIO		I/O error reading TOC
+
+	notes:
+	  TOC stands for Table Of Contents
+	  MSF stands for minutes-seconds-frames
+	  LBA stands for logical block address
+
+
+
+CDROMSTOP			Stop the cdrom drive
+
+	usage:
+
+	  ioctl(fd, CDROMSTOP, 0);
+
+	inputs:		none
+
+	outputs:	none
+
+	error return:
+	  ENOSYS	cd drive not audio-capable.
+
+	notes:
+	  Exact interpretation of this ioctl depends on the device,
+	  but most seem to spin the drive down.
+
+
+CDROMSTART			Start the cdrom drive
+
+	usage:
+
+	  ioctl(fd, CDROMSTART, 0);
+
+	inputs:		none
+
+	outputs:	none
+
+	error return:
+	  ENOSYS	cd drive not audio-capable.
+
+	notes:
+	  Exact interpretation of this ioctl depends on the device,
+	  but most seem to spin the drive up and/or close the tray.
+	  Other devices ignore the ioctl completely.
+
+
+CDROMEJECT			Ejects the cdrom media
+
+	usage:
+
+	  ioctl(fd, CDROMEJECT, 0);
+
+	inputs:		none
+
+	outputs:	none
+
+	error returns:
+	  ENOSYS	cd drive not capable of ejecting
+	  EBUSY		other processes are accessing drive, or door is locked
+
+	notes:
+	  See CDROM_LOCKDOOR, below.
+
+
+
+CDROMCLOSETRAY			pendant of CDROMEJECT
+
+	usage:
+
+	  ioctl(fd, CDROMEJECT, 0);
+
+	inputs:		none
+
+	outputs:	none
+
+	error returns:
+	  ENOSYS	cd drive not capable of ejecting
+	  EBUSY		other processes are accessing drive, or door is locked
+
+	notes:
+	  See CDROM_LOCKDOOR, below.
+
+
+
+CDROMVOLCTRL			Control output volume (struct cdrom_volctrl)
+
+	usage:
+
+	  struct cdrom_volctrl volume;
+	  ioctl(fd, CDROMVOLCTRL, &volume);
+
+	inputs:
+	  cdrom_volctrl structure containing volumes for up to 4
+	  channels.
+
+	outputs:	none
+
+	error return:
+	  ENOSYS	cd drive not audio-capable.
+
+
+
+CDROMVOLREAD			Get the drive's volume setting
+					  (struct cdrom_volctrl)
+
+	usage:
+
+	  struct cdrom_volctrl volume;
+	  ioctl(fd, CDROMVOLREAD, &volume);
+
+	inputs:		none
+
+	outputs:
+	  The current volume settings.
+
+	error return:
+	  ENOSYS	cd drive not audio-capable.
+
+
+
+CDROMSUBCHNL			Read subchannel data (struct cdrom_subchnl)
+
+	usage:
+
+	  struct cdrom_subchnl q;
+	  ioctl(fd, CDROMSUBCHNL, &q);
+
+	inputs:
+	  cdrom_subchnl structure
+
+	outputs:
+	  cdrom_subchnl structure
+
+	error return:
+	  ENOSYS	cd drive not audio-capable.
+	  EINVAL	format not CDROM_MSF or CDROM_LBA
+
+	notes:
+	  Format is converted to CDROM_MSF on return
+
+
+
+CDROMREADRAW			read data in raw mode (2352 Bytes)
+					   (struct cdrom_read)
+
+	usage:
+
+	  union {
+	    struct cdrom_msf msf;		/* input */
+	    char buffer[CD_FRAMESIZE_RAW];	/* return */
+	  } arg;
+	  ioctl(fd, CDROMREADRAW, &arg);
+
+	inputs:
+	  cdrom_msf structure indicating an address to read.
+	  Only the start values are significant.
+
+	outputs:
+	  Data written to address provided by user.
+
+	error return:
+	  EINVAL	address less than 0, or msf less than 0:2:0
+	  ENOMEM	out of memory
+
+	notes:
+	  As of 2.6.8.1, comments in <linux/cdrom.h> indicate that this
+	  ioctl accepts a cdrom_read structure, but actual source code
+	  reads a cdrom_msf structure and writes a buffer of data to
+	  the same address.
+
+	  MSF values are converted to LBA values via this formula:
+
+	    lba = (((m * CD_SECS) + s) * CD_FRAMES + f) - CD_MSF_OFFSET;
+
+
+
+
+CDROMREADMODE1			Read CDROM mode 1 data (2048 Bytes)
+					   (struct cdrom_read)
+
+	notes:
+	  Identical to CDROMREADRAW except that block size is
+	  CD_FRAMESIZE (2048) bytes
+
+
+
+CDROMREADMODE2			Read CDROM mode 2 data (2336 Bytes)
+					   (struct cdrom_read)
+
+	notes:
+	  Identical to CDROMREADRAW except that block size is
+	  CD_FRAMESIZE_RAW0 (2336) bytes
+
+
+
+CDROMREADAUDIO			(struct cdrom_read_audio)
+
+	usage:
+
+	  struct cdrom_read_audio ra;
+	  ioctl(fd, CDROMREADAUDIO, &ra);
+
+	inputs:
+	  cdrom_read_audio structure containing read start
+	  point and length
+
+	outputs:
+	  audio data, returned to buffer indicated by ra
+
+	error return:
+	  EINVAL	format not CDROM_MSF or CDROM_LBA
+	  EINVAL	nframes not in range [1 75]
+	  ENXIO		drive has no queue (probably means invalid fd)
+	  ENOMEM	out of memory
+
+
+CDROMEJECT_SW			enable(1)/disable(0) auto-ejecting
+
+	usage:
+
+	  int val;
+	  ioctl(fd, CDROMEJECT_SW, val);
+
+	inputs:
+	  Flag specifying auto-eject flag.
+
+	outputs:	none
+
+	error return:
+	  ENOSYS	Drive is not capable of ejecting.
+	  EBUSY		Door is locked
+
+
+
+
+CDROMMULTISESSION		Obtain the start-of-last-session
+				  address of multi session disks
+				  (struct cdrom_multisession)
+	usage:
+
+	  struct cdrom_multisession ms_info;
+	  ioctl(fd, CDROMMULTISESSION, &ms_info);
+
+	inputs:
+	  cdrom_multisession structure containing desired
+	  format.
+
+	outputs:
+	  cdrom_multisession structure is filled with last_session
+	  information.
+
+	error return:
+	  EINVAL	format not CDROM_MSF or CDROM_LBA
+
+
+CDROM_GET_MCN			Obtain the "Universal Product Code"
+				   if available (struct cdrom_mcn)
+
+	usage:
+
+	  struct cdrom_mcn mcn;
+	  ioctl(fd, CDROM_GET_MCN, &mcn);
+
+	inputs:		none
+
+	outputs:
+	  Universal Product Code
+
+	error return:
+	  ENOSYS	Drive is not capable of reading MCN data.
+
+	notes:
+	  Source code comments state:
+
+	    The following function is implemented, although very few
+	    audio discs give Universal Product Code information, which
+	    should just be the Medium Catalog Number on the box.  Note,
+	    that the way the code is written on the CD is /not/ uniform
+	    across all discs!
+
+
+
+
+CDROM_GET_UPC			CDROM_GET_MCN  (deprecated)
+
+	Not implemented, as of 2.6.8.1
+
+
+
+CDROMRESET			hard-reset the drive
+
+	usage:
+
+	  ioctl(fd, CDROMRESET, 0);
+
+	inputs:		none
+
+	outputs:	none
+
+	error return:
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  ENOSYS	Drive is not capable of resetting.
+
+
+
+
+CDROMREADCOOKED			read data in cooked mode
+
+	usage:
+
+	  u8 buffer[CD_FRAMESIZE]
+	  ioctl(fd, CDROMREADCOOKED, buffer);
+
+	inputs:		none
+
+	outputs:
+	  2048 bytes of data, "cooked" mode.
+
+	notes:
+	  Not implemented on all drives.
+
+
+
+
+CDROMREADALL			read all 2646 bytes
+
+	Same as CDROMREADCOOKED, but reads 2646 bytes.
+
+
+
+CDROMSEEK			seek msf address
+
+	usage:
+
+	  struct cdrom_msf msf;
+	  ioctl(fd, CDROMSEEK, &msf);
+
+	inputs:
+	  MSF address to seek to.
+
+	outputs:	none
+
+
+
+CDROMPLAYBLK			scsi-cd only, (struct cdrom_blk)
+
+	usage:
+
+	  struct cdrom_blk blk;
+	  ioctl(fd, CDROMPLAYBLK, &blk);
+
+	inputs:
+	  Region to play
+
+	outputs:	none
+
+
+
+CDROMGETSPINDOWN
+
+	usage:
+
+	  char spindown;
+	  ioctl(fd, CDROMGETSPINDOWN, &spindown);
+
+	inputs:		none
+
+	outputs:
+	  The value of the current 4-bit spindown value.
+
+
+
+
+CDROMSETSPINDOWN
+
+	usage:
+
+	  char spindown
+	  ioctl(fd, CDROMSETSPINDOWN, &spindown);
+
+	inputs:
+	  4-bit value used to control spindown (TODO: more detail here)
+
+	outputs:	none
+
+
+
+
+
+CDROM_SET_OPTIONS		Set behavior options
+
+	usage:
+
+	  int options;
+	  ioctl(fd, CDROM_SET_OPTIONS, options);
+
+	inputs:
+	  New values for drive options.  The logical 'or' of:
+	    CDO_AUTO_CLOSE	close tray on first open(2)
+	    CDO_AUTO_EJECT	open tray on last release
+	    CDO_USE_FFLAGS	use O_NONBLOCK information on open
+	    CDO_LOCK		lock tray on open files
+	    CDO_CHECK_TYPE	check type on open for data
+
+	outputs:
+	  Returns the resulting options settings in the
+	  ioctl return value.  Returns -1 on error.
+
+	error return:
+	  ENOSYS	selected option(s) not supported by drive.
+
+
+
+
+CDROM_CLEAR_OPTIONS		Clear behavior options
+
+	Same as CDROM_SET_OPTIONS, except that selected options are
+	turned off.
+
+
+
+CDROM_SELECT_SPEED		Set the CD-ROM speed
+
+	usage:
+
+	  int speed;
+	  ioctl(fd, CDROM_SELECT_SPEED, speed);
+
+	inputs:
+	  New drive speed.
+
+	outputs:	none
+
+	error return:
+	  ENOSYS	speed selection not supported by drive.
+
+
+
+CDROM_SELECT_DISC		Select disc (for juke-boxes)
+
+	usage:
+
+	  int disk;
+	  ioctl(fd, CDROM_SELECT_DISC, disk);
+
+	inputs:
+	  Disk to load into drive.
+
+	outputs:	none
+
+	error return:
+	  EINVAL	Disk number beyond capacity of drive
+
+
+
+CDROM_MEDIA_CHANGED		Check is media changed
+
+	usage:
+
+	  int slot;
+	  ioctl(fd, CDROM_MEDIA_CHANGED, slot);
+
+	inputs:
+	  Slot number to be tested, always zero except for jukeboxes.
+	  May also be special values CDSL_NONE or CDSL_CURRENT
+
+	outputs:
+	  Ioctl return value is 0 or 1 depending on whether the media
+	  has been changed, or -1 on error.
+
+	error returns:
+	  ENOSYS	Drive can't detect media change
+	  EINVAL	Slot number beyond capacity of drive
+	  ENOMEM	Out of memory
+
+
+
+CDROM_DRIVE_STATUS		Get tray position, etc.
+
+	usage:
+
+	  int slot;
+	  ioctl(fd, CDROM_DRIVE_STATUS, slot);
+
+	inputs:
+	  Slot number to be tested, always zero except for jukeboxes.
+	  May also be special values CDSL_NONE or CDSL_CURRENT
+
+	outputs:
+	  Ioctl return value will be one of the following values
+	  from <linux/cdrom.h>:
+
+	    CDS_NO_INFO		Information not available.
+	    CDS_NO_DISC
+	    CDS_TRAY_OPEN
+	    CDS_DRIVE_NOT_READY
+	    CDS_DISC_OK
+	    -1			error
+
+	error returns:
+	  ENOSYS	Drive can't detect drive status
+	  EINVAL	Slot number beyond capacity of drive
+	  ENOMEM	Out of memory
+
+
+
+
+CDROM_DISC_STATUS		Get disc type, etc.
+
+	usage:
+
+	  ioctl(fd, CDROM_DISC_STATUS, 0);
+
+	inputs:		none
+
+	outputs:
+	  Ioctl return value will be one of the following values
+	  from <linux/cdrom.h>:
+	    CDS_NO_INFO
+	    CDS_AUDIO
+	    CDS_MIXED
+	    CDS_XA_2_2
+	    CDS_XA_2_1
+	    CDS_DATA_1
+
+	error returns:	none at present
+
+	notes:
+	  Source code comments state:
+
+	    Ok, this is where problems start.  The current interface for
+	    the CDROM_DISC_STATUS ioctl is flawed.  It makes the false
+	    assumption that CDs are all CDS_DATA_1 or all CDS_AUDIO, etc.
+	    Unfortunatly, while this is often the case, it is also
+	    very common for CDs to have some tracks with data, and some
+	    tracks with audio.	Just because I feel like it, I declare
+	    the following to be the best way to cope.  If the CD has
+	    ANY data tracks on it, it will be returned as a data CD.
+	    If it has any XA tracks, I will return it as that.	Now I
+	    could simplify this interface by combining these returns with
+	    the above, but this more clearly demonstrates the problem
+	    with the current interface.  Too bad this wasn't designed
+	    to use bitmasks...	       -Erik
+
+	    Well, now we have the option CDS_MIXED: a mixed-type CD.
+	    User level programmers might feel the ioctl is not very
+	    useful.
+			---david
+
+
+
+
+CDROM_CHANGER_NSLOTS		Get number of slots
+
+	usage:
+
+	  ioctl(fd, CDROM_CHANGER_NSLOTS, 0);
+
+	inputs:		none
+
+	outputs:
+	  The ioctl return value will be the number of slots in a
+	  CD changer.  Typically 1 for non-multi-disk devices.
+
+	error returns:	none
+
+
+
+CDROM_LOCKDOOR			lock or unlock door
+
+	usage:
+
+	  int lock;
+	  ioctl(fd, CDROM_LOCKDOOR, lock);
+
+	inputs:
+	  Door lock flag, 1=lock, 0=unlock
+
+	outputs:	none
+
+	error returns:
+	  EDRIVE_CANT_DO_THIS	Door lock function not supported.
+	  EBUSY			Attempt to unlock when multiple users
+	  			have the drive open and not CAP_SYS_ADMIN
+
+	notes:
+	  As of 2.6.8.1, the lock flag is a global lock, meaning that
+	  all CD drives will be locked or unlocked together.  This is
+	  probably a bug.
+
+	  The EDRIVE_CANT_DO_THIS value is defined in <linux/cdrom.h>
+	  and is currently (2.6.8.1) the same as EOPNOTSUPP
+
+
+
+CDROM_DEBUG			Turn debug messages on/off
+
+	usage:
+
+	  int debug;
+	  ioctl(fd, CDROM_DEBUG, debug);
+
+	inputs:
+	  Cdrom debug flag, 0=disable, 1=enable
+
+	outputs:
+	  The ioctl return value will be the new debug flag.
+
+	error return:
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+
+
+
+CDROM_GET_CAPABILITY		get capabilities
+
+	usage:
+
+	  ioctl(fd, CDROM_GET_CAPABILITY, 0);
+
+	inputs:		none
+
+	outputs:
+	  The ioctl return value is the current device capability
+	  flags.  See CDC_CLOSE_TRAY, CDC_OPEN_TRAY, etc.
+
+
+
+CDROMAUDIOBUFSIZ		set the audio buffer size
+
+	usage:
+
+	  int arg;
+	  ioctl(fd, CDROMAUDIOBUFSIZ, val);
+
+	inputs:
+	  New audio buffer size
+
+	outputs:
+	  The ioctl return value is the new audio buffer size, or -1
+	  on error.
+
+	error return:
+	  ENOSYS	Not supported by this driver.
+
+	notes:
+	  Not supported by all drivers.
+
+
+
+DVD_READ_STRUCT			Read structure
+
+	usage:
+
+	  dvd_struct s;
+	  ioctl(fd, DVD_READ_STRUCT, &s);
+
+	inputs:
+	  dvd_struct structure, containing:
+	    type		specifies the information desired, one of
+	    			DVD_STRUCT_PHYSICAL, DVD_STRUCT_COPYRIGHT,
+				DVD_STRUCT_DISCKEY, DVD_STRUCT_BCA,
+				DVD_STRUCT_MANUFACT
+	    physical.layer_num	desired layer, indexed from 0
+	    copyright.layer_num	desired layer, indexed from 0
+	    disckey.agid
+
+	outputs:
+	  dvd_struct structure, containing:
+	    physical		for type == DVD_STRUCT_PHYSICAL
+	    copyright		for type == DVD_STRUCT_COPYRIGHT
+	    disckey.value	for type == DVD_STRUCT_DISCKEY
+	    bca.{len,value}	for type == DVD_STRUCT_BCA
+	    manufact.{len,valu}	for type == DVD_STRUCT_MANUFACT
+
+	error returns:
+	  EINVAL	physical.layer_num exceeds number of layers
+	  EIO		Recieved invalid response from drive
+
+
+
+DVD_WRITE_STRUCT		Write structure
+
+	Not implemented, as of 2.6.8.1
+
+
+
+DVD_AUTH			Authentication
+
+	usage:
+
+	  dvd_authinfo ai;
+	  ioctl(fd, DVD_AUTH, &ai);
+
+	inputs:
+	  dvd_authinfo structure.  See <linux/cdrom.h>
+
+	outputs:
+	  dvd_authinfo structure.
+
+	error return:
+	  ENOTTY	ai.type not recognized.
+
+
+
+CDROM_SEND_PACKET		send a packet to the drive
+
+	usage:
+
+	  struct cdrom_generic_command cgc;
+	  ioctl(fd, CDROM_SEND_PACKET, &cgc);
+
+	inputs:
+	  cdrom_generic_command structure containing the packet to send.
+
+	outputs:	none
+	  cdrom_generic_command structure containing results.
+
+	error return:
+	  EIO		command failed.
+	  EPERM		Operation not permitted, either because a
+			write command was attempted on a drive which
+			is opened read-only, or because the command
+			requires CAP_SYS_RAWIO
+	  EINVAL	cgc.data_direction not set
+
+
+
+CDROM_NEXT_WRITABLE		get next writable block
+
+	usage:
+
+	  long next;
+	  ioctl(fd, CDROM_NEXT_WRITABLE, &next);
+
+	inputs:		none
+
+	outputs:
+	  The next writable block.
+
+	notes:
+	  If the device does not support this ioctl directly, the
+	  ioctl will return CDROM_LAST_WRITTEN + 7.
+
+
+
+CDROM_LAST_WRITTEN		get last block written on disc
+
+	usage:
+
+	  long last;
+	  ioctl(fd, CDROM_LAST_WRITTEN, &last);
+
+	inputs:		none
+
+	outputs:
+	  The last block written on disc
+
+	notes:
+	  If the device does not support this ioctl directly, the
+	  result is derived from the disc's table of contents.  If the
+	  table of contents can't be read, this ioctl returns an
+	  error.
diff --git a/Documentation/ioctl/hdio.txt b/Documentation/ioctl/hdio.txt
new file mode 100644
index 00000000000000..c42d3b68577e70
--- /dev/null
+++ b/Documentation/ioctl/hdio.txt
@@ -0,0 +1,965 @@
+		Summary of HDIO_ ioctl calls.
+		============================
+
+		Edward A. Falk <efalk@google.com>
+
+		November, 2004
+
+This document attempts to describe the ioctl(2) calls supported by
+the HD/IDE layer.  These are by-and-large implemented (as of Linux 2.6)
+in drivers/ide/ide.c and drivers/block/scsi_ioctl.c
+
+ioctl values are listed in <linux/hdreg.h>.  As of this writing, they
+are as follows:
+
+    ioctls that pass argument pointers to user space:
+
+	HDIO_GETGEO		get device geometry
+	HDIO_GET_UNMASKINTR	get current unmask setting
+	HDIO_GET_MULTCOUNT	get current IDE blockmode setting
+	HDIO_GET_QDMA		get use-qdma flag
+	HDIO_SET_XFER		set transfer rate via proc
+	HDIO_OBSOLETE_IDENTITY	OBSOLETE, DO NOT USE
+	HDIO_GET_KEEPSETTINGS	get keep-settings-on-reset flag
+	HDIO_GET_32BIT		get current io_32bit setting
+	HDIO_GET_NOWERR		get ignore-write-error flag
+	HDIO_GET_DMA		get use-dma flag
+	HDIO_GET_NICE		get nice flags
+	HDIO_GET_IDENTITY	get IDE identification info
+	HDIO_GET_WCACHE		get write cache mode on|off
+	HDIO_GET_ACOUSTIC	get acoustic value
+	HDIO_GET_ADDRESS	get sector addressing mode
+	HDIO_GET_BUSSTATE	get the bus state of the hwif
+	HDIO_TRISTATE_HWIF	execute a channel tristate
+	HDIO_DRIVE_RESET	execute a device reset
+	HDIO_DRIVE_TASKFILE	execute raw taskfile
+	HDIO_DRIVE_TASK		execute task and special drive command
+	HDIO_DRIVE_CMD		execute a special drive command
+	HDIO_DRIVE_CMD_AEB	HDIO_DRIVE_TASK
+
+    ioctls that pass non-pointer values:
+
+	HDIO_SET_MULTCOUNT	change IDE blockmode
+	HDIO_SET_UNMASKINTR	permit other irqs during I/O
+	HDIO_SET_KEEPSETTINGS	keep ioctl settings on reset
+	HDIO_SET_32BIT		change io_32bit flags
+	HDIO_SET_NOWERR		change ignore-write-error flag
+	HDIO_SET_DMA		change use-dma flag
+	HDIO_SET_PIO_MODE	reconfig interface to new speed
+	HDIO_SCAN_HWIF		register and (re)scan interface
+	HDIO_SET_NICE		set nice flags
+	HDIO_UNREGISTER_HWIF	unregister interface
+	HDIO_SET_WCACHE		change write cache enable-disable
+	HDIO_SET_ACOUSTIC	change acoustic behavior
+	HDIO_SET_BUSSTATE	set the bus state of the hwif
+	HDIO_SET_QDMA		change use-qdma flag
+	HDIO_SET_ADDRESS	change lba addressing modes
+
+	HDIO_SET_IDE_SCSI	Set scsi emulation mode on/off
+	HDIO_SET_SCSI_IDE	not implemented yet
+
+
+The information that follows was determined from reading kernel source
+code.  It is likely that some corrections will be made over time.
+
+
+
+
+
+
+
+General:
+
+	Unless otherwise specified, all ioctl calls return 0 on success
+	and -1 with errno set to an appropriate value on error.
+
+	Unless otherwise specified, all ioctl calls return -1 and set
+	errno to EFAULT on a failed attempt to copy data to or from user
+	address space.
+
+	Unless otherwise specified, all data structures and constants
+	are defined in <linux/hdreg.h>
+
+
+
+HDIO_GETGEO			get device geometry
+
+	usage:
+
+	  struct hd_geometry geom;
+	  ioctl(fd, HDIO_GETGEO, &geom);
+
+
+	inputs:		none
+
+	outputs:
+
+	  hd_geometry structure containing:
+
+	    heads	number of heads
+	    sectors	number of sectors/track
+	    cylinders	number of cylinders, mod 65536
+	    start	starting sector of this partition.
+
+
+	error returns:
+	  EINVAL	if the device is not a disk drive or floppy drive,
+	  		or if the user passes a null pointer
+
+
+	notes:
+
+	  Not particularly useful with modern disk drives, whose geometry
+	  is a polite fiction anyway.  Modern drives are addressed
+	  purely by sector number nowadays (lba addressing), and the
+	  drive geometry is an abstraction which is actually subject
+	  to change.  Currently (as of Nov 2004), the geometry values
+	  are the "bios" values -- presumably the values the drive had
+	  when Linux first booted.
+
+	  In addition, the cylinders field of the hd_geometry is an
+	  unsigned short, meaning that on most architectures, this
+	  ioctl will not return a meaningful value on drives with more
+	  than 65535 tracks.
+
+	  The start field is unsigned long, meaning that it will not
+	  contain a meaningful value for disks over 219 Gb in size.
+
+
+
+
+HDIO_GET_UNMASKINTR		get current unmask setting
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_GET_UNMASKINTR, &val);
+
+	inputs:		none
+
+	outputs:
+	  The value of the drive's current unmask setting
+
+
+
+HDIO_SET_UNMASKINTR		permit other irqs during I/O
+
+	usage:
+
+	  unsigned long val;
+	  ioctl(fd, HDIO_SET_UNMASKINTR, val);
+
+	inputs:
+	  New value for unmask flag
+
+	outputs:	none
+
+	error return:
+	  EINVAL	(bdev != bdev->bd_contains) (not sure what this means)
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  EINVAL	value out of range [0 1]
+	  EBUSY		Controller busy
+
+
+
+
+HDIO_GET_MULTCOUNT		get current IDE blockmode setting
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_GET_MULTCOUNT, &val);
+
+	inputs:		none
+
+	outputs:
+	  The value of the current IDE block mode setting.  This
+	  controls how many sectors the drive will transfer per
+	  interrupt.
+
+
+
+HDIO_SET_MULTCOUNT		change IDE blockmode
+
+	usage:
+
+	  int val;
+	  ioctl(fd, HDIO_SET_MULTCOUNT, val);
+
+	inputs:
+	  New value for IDE block mode setting.  This controls how many
+	  sectors the drive will transfer per interrupt.
+
+	outputs:	none
+
+	error return:
+	  EINVAL	(bdev != bdev->bd_contains) (not sure what this means)
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  EINVAL	value out of range supported by disk.
+	  EBUSY		Controller busy or blockmode already set.
+	  EIO		Drive did not accept new block mode.
+
+	notes:
+
+	  Source code comments read:
+
+	    This is tightly woven into the driver->do_special can not
+	    touch.  DON'T do it again until a total personality rewrite
+	    is committed.
+
+	  If blockmode has already been set, this ioctl will fail with
+	  EBUSY
+
+
+
+HDIO_GET_QDMA			get use-qdma flag
+
+	Not implemented, as of 2.6.8.1
+
+
+
+HDIO_SET_XFER			set transfer rate via proc
+
+	Not implemented, as of 2.6.8.1
+
+
+
+HDIO_OBSOLETE_IDENTITY		OBSOLETE, DO NOT USE
+
+	Same as HDIO_GET_IDENTITY (see below), except that it only
+	returns the first 142 bytes of drive identity information.
+
+
+
+HDIO_GET_IDENTITY		get IDE identification info
+
+	usage:
+
+	  unsigned char identity[512];
+	  ioctl(fd, HDIO_GET_IDENTITY, identity);
+
+	inputs:		none
+
+	outputs:
+
+	  ATA drive identity information.  For full description, see
+	  the IDENTIFY DEVICE and IDENTIFY PACKET DEVICE commands in
+	  the ATA specification.
+
+	error returns:
+	  EINVAL	(bdev != bdev->bd_contains) (not sure what this means)
+	  ENOMSG	IDENTIFY DEVICE information not available
+
+	notes:
+
+	  Returns information that was obtained when the drive was
+	  probed.  Some of this information is subject to change, and
+	  this ioctl does not re-probe the drive to update the
+	  information.
+
+	  This information is also available from /proc/ide/hdX/identify
+
+
+
+HDIO_GET_KEEPSETTINGS		get keep-settings-on-reset flag
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_GET_KEEPSETTINGS, &val);
+
+	inputs:		none
+
+	outputs:
+	  The value of the current "keep settings" flag
+
+	notes:
+
+	  When set, indicates that kernel should restore settings
+	  after a drive reset.
+
+
+
+HDIO_SET_KEEPSETTINGS		keep ioctl settings on reset
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_SET_KEEPSETTINGS, val);
+
+	inputs:
+	  New value for keep_settings flag
+
+	outputs:	none
+
+	error return:
+	  EINVAL	(bdev != bdev->bd_contains) (not sure what this means)
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  EINVAL	value out of range [0 1]
+	  EBUSY		Controller busy
+
+
+
+HDIO_GET_32BIT			get current io_32bit setting
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_GET_32BIT, &val);
+
+	inputs:		none
+
+	outputs:
+	  The value of the current io_32bit setting
+
+	notes:
+
+	  0=16-bit, 1=32-bit, 2,3 = 32bit+sync
+
+
+
+HDIO_GET_NOWERR			get ignore-write-error flag
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_GET_NOWERR, &val);
+
+	inputs:		none
+
+	outputs:
+	  The value of the current ignore-write-error flag
+
+
+
+HDIO_GET_DMA			get use-dma flag
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_GET_DMA, &val);
+
+	inputs:		none
+
+	outputs:
+	  The value of the current use-dma flag
+
+
+
+HDIO_GET_NICE			get nice flags
+
+	usage:
+
+	  long nice;
+	  ioctl(fd, HDIO_GET_NICE, &nice);
+
+	inputs:		none
+
+	outputs:
+
+	  The drive's "nice" values.
+
+	notes:
+
+	  Per-drive flags which determine when the system will give more
+	  bandwidth to other devices sharing the same IDE bus.
+	  See <linux/hdreg.h>, near symbol IDE_NICE_DSC_OVERLAP.
+
+
+
+
+HDIO_SET_NICE			set nice flags
+
+	usage:
+
+	  unsigned long nice;
+	  ...
+	  ioctl(fd, HDIO_SET_NICE, nice);
+
+	inputs:
+	  bitmask of nice flags.
+
+	outputs:	none
+
+	error returns:
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  EPERM		Flags other than DSC_OVERLAP and NICE_1 set.
+	  EPERM		DSC_OVERLAP specified but not supported by drive
+
+	notes:
+
+	  This ioctl sets the DSC_OVERLAP and NICE_1 flags from values
+	  provided by the user.
+
+	  Nice flags are listed in <linux/hdreg.h>, starting with
+	  IDE_NICE_DSC_OVERLAP.  These values represent shifts.
+
+
+
+
+
+HDIO_GET_WCACHE			get write cache mode on|off
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_GET_WCACHE, &val);
+
+	inputs:		none
+
+	outputs:
+	  The value of the current write cache mode
+
+
+
+HDIO_GET_ACOUSTIC		get acoustic value
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_GET_ACOUSTIC, &val);
+
+	inputs:		none
+
+	outputs:
+	  The value of the current acoustic settings
+
+	notes:
+
+	  See HDIO_SET_ACOUSTIC
+
+
+
+HDIO_GET_ADDRESS
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_GET_ADDRESS, &val);
+
+	inputs:		none
+
+	outputs:
+	  The value of the current addressing mode:
+	    0 = 28-bit
+	    1 = 48-bit
+	    2 = 48-bit doing 28-bit
+	    3 = 64-bit
+
+
+
+HDIO_GET_BUSSTATE		get the bus state of the hwif
+
+	usage:
+
+	  long state;
+	  ioctl(fd, HDIO_SCAN_HWIF, &state);
+
+	inputs:		none
+
+	outputs:
+	  Current power state of the IDE bus.  One of BUSSTATE_OFF,
+	  BUSSTATE_ON, or BUSSTATE_TRISTATE
+
+	error returns:
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+
+
+
+
+HDIO_SET_BUSSTATE		set the bus state of the hwif
+
+	usage:
+
+	  int state;
+	  ...
+	  ioctl(fd, HDIO_SCAN_HWIF, state);
+
+	inputs:
+	  Desired IDE power state.  One of BUSSTATE_OFF, BUSSTATE_ON,
+	  or BUSSTATE_TRISTATE
+
+	outputs:	none
+
+	error returns:
+	  EACCES	Access denied:  requires CAP_SYS_RAWIO
+	  EOPNOTSUPP	Hardware interface does not support bus power control
+
+
+
+
+HDIO_TRISTATE_HWIF		execute a channel tristate
+
+	Not implemented, as of 2.6.8.1.  See HDIO_SET_BUSSTATE
+
+
+
+HDIO_DRIVE_RESET		execute a device reset
+
+	usage:
+
+	  int args[3]
+	  ...
+	  ioctl(fd, HDIO_DRIVE_RESET, args);
+
+	inputs:		none
+
+	outputs:	none
+
+	error returns:
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+
+	notes:
+
+	  Abort any current command, prevent anything else from being
+	  queued, execute a reset on the device, and issue BLKRRPART
+	  ioctl on the block device.
+
+	  Executes an ATAPI soft reset if applicable, otherwise
+	  executes an ATA soft reset on the controller.
+
+
+
+HDIO_DRIVE_TASKFILE		execute raw taskfile
+
+	Note:  If you don't have a copy of the ANSI ATA specification
+	handy, you should probably ignore this ioctl.
+
+	Execute an ATA disk command directly by writing the "taskfile"
+	registers of the drive.  Requires ADMIN and RAWIO access
+	privileges.
+
+	usage:
+
+	  struct {
+	    ide_task_request_t req_task;
+	    u8 outbuf[OUTPUT_SIZE];
+	    u8 inbuf[INPUT_SIZE];
+	  } task;
+	  memset(&task.req_task, 0, sizeof(task.req_task));
+	  task.req_task.out_size = sizeof(task.outbuf);
+	  task.req_task.in_size = sizeof(task.inbuf);
+	  ...
+	  ioctl(fd, HDIO_DRIVE_TASKFILE, &task);
+	  ...
+
+	inputs:
+
+	  (See below for details on memory area passed to ioctl.)
+
+	  io_ports[8]	values to be written to taskfile registers
+	  hob_ports[8]	high-order bytes, for extended commands.
+	  out_flags	flags indicating which registers are valid
+	  in_flags	flags indicating which registers should be returned
+	  data_phase	see below
+	  req_cmd	command type to be executed
+	  out_size	size of output buffer
+	  outbuf	buffer of data to be transmitted to disk
+	  inbuf		buffer of data to be received from disk (see [1])
+
+	outputs:
+
+	  io_ports[]	values returned in the taskfile registers
+	  hob_ports[]	high-order bytes, for extended commands.
+	  out_flags	flags indicating which registers are valid (see [2])
+	  in_flags	flags indicating which registers should be returned
+	  outbuf	buffer of data to be transmitted to disk (see [1])
+	  inbuf		buffer of data to be received from disk
+
+	error returns:
+	  EACCES	CAP_SYS_ADMIN or CAP_SYS_RAWIO privilege not set.
+	  ENOMSG	Device is not a disk drive.
+	  ENOMEM	Unable to allocate memory for task
+	  EFAULT	req_cmd == TASKFILE_IN_OUT (not implemented as of 2.6.8)
+	  EPERM		req_cmd == TASKFILE_MULTI_OUT and drive
+	  		multi-count not yet set.
+
+
+	notes:
+
+	  [1] Currently (2.6.8), both the input and output buffers are
+	  copied from the user and written back to the user, even when
+	  not used.  This may be a bug.
+
+	  [2] The out_flags and in_flags are returned to the user after
+	  the ioctl completes.	Currently (2.6.8) these are the same
+	  as the input values, unchanged.  In the future, they may have
+	  more significance.
+
+	  Extreme caution should be used with using this ioctl.  A
+	  mistake can easily corrupt data or hang the system.
+
+	  The argument to the ioctl is a pointer to a region of memory
+	  containing a ide_task_request_t structure, followed by an
+	  optional buffer of data to be transmitted to the drive,
+	  followed by an optional buffer to receive data from the drive.
+
+	  Command is passed to the disk drive via the ide_task_request_t
+	  structure, which contains these fields:
+
+	    io_ports[8]		values for the taskfile registers
+	    hob_ports[8]	high-order bytes, for extended commands
+	    out_flags		flags indicating which entries in the
+	    			io_ports[] and hob_ports[] arrays
+				contain valid values.  Type ide_reg_valid_t.
+	    in_flags		flags indicating which entries in the
+	    			io_ports[] and hob_ports[] arrays
+				are expected to contain valid values
+				on return.
+	    data_phase		See below
+	    req_cmd		Command type, see below
+	    out_size		output (user->drive) buffer size, bytes
+	    in_size		input (drive->user) buffer size, bytes
+
+	  This ioctl does not necessarily respect all flags in the
+	  out_flags and in_flags values -- some taskfile registers
+	  may be written or read even if not requested in the flags.
+	  Unused fields of io_ports[] and hob_ports[] should be set
+	  to zero.
+
+	  The data_phase field describes the data transfer to be
+	  performed.  Value is one of:
+
+	    TASKFILE_IN
+	    TASKFILE_MULTI_IN
+	    TASKFILE_OUT
+	    TASKFILE_MULTI_OUT
+	    TASKFILE_IN_OUT
+	    TASKFILE_IN_DMA
+	    TASKFILE_IN_DMAQ
+	    TASKFILE_OUT_DMA
+	    TASKFILE_OUT_DMAQ
+	    TASKFILE_P_IN
+	    TASKFILE_P_IN_DMA
+	    TASKFILE_P_IN_DMAQ
+	    TASKFILE_P_OUT
+	    TASKFILE_P_OUT_DMA
+	    TASKFILE_P_OUT_DMAQ
+
+	  The req_cmd field classifies the command type.  It may be
+	  one of:
+
+	    IDE_DRIVE_TASK_NO_DATA
+	    IDE_DRIVE_TASK_SET_XFER
+	    IDE_DRIVE_TASK_IN
+	    IDE_DRIVE_TASK_OUT
+	    IDE_DRIVE_TASK_RAW_WRITE
+
+
+
+
+
+
+HDIO_DRIVE_CMD			execute a special drive command
+
+	Note:  If you don't have a copy of the ANSI ATA specification
+	handy, you should probably ignore this ioctl.
+
+	usage:
+
+	  u8 args[4+XFER_SIZE];
+	  ...
+	  ioctl(fd, HDIO_DRIVE_CMD, args);
+
+	inputs:
+
+	  Taskfile register values:
+	    args[0]	COMMAND
+	    args[1]	SECTOR
+	    args[2]	FEATURE
+	    args[3]	NSECTOR
+
+	outputs:
+
+	  args[] buffer is filled with register values followed by any
+	  data returned by the disk.
+	    args[0]	status
+	    args[1]	error
+	    args[2]	NSECTOR
+	    args[3]	undefined
+	    args[4+]	NSECTOR * 512 bytes of data returned by the command.
+
+	error returns:
+	  EACCES	Access denied:  requires CAP_SYS_RAWIO
+	  ENOMEM	Unable to allocate memory for task
+
+	notes:
+
+	  Taskfile registers IDE_LCYL, IDE_HCYL, and IDE_SELECT are
+	  set to zero before executing the command.
+
+
+
+HDIO_DRIVE_TASK			execute task and special drive command
+
+	Note:  If you don't have a copy of the ANSI ATA specification
+	handy, you should probably ignore this ioctl.
+
+	usage:
+
+	  u8 args[7];
+	  ...
+	  ioctl(fd, HDIO_DRIVE_TASK, args);
+
+	inputs:
+
+	  Taskfile register values:
+	    args[0]	COMMAND
+	    args[1]	FEATURE
+	    args[2]	NSECTOR
+	    args[3]	SECTOR
+	    args[4]	LCYL
+	    args[5]	HCYL
+	    args[6]	SELECT
+
+	outputs:
+
+	  Taskfile register values:
+	    args[0]	status
+	    args[1]	error
+	    args[2]	NSECTOR
+	    args[3]	SECTOR
+	    args[4]	LCYL
+	    args[5]	HCYL
+	    args[6]	SELECT
+
+	error returns:
+	  EACCES	Access denied:  requires CAP_SYS_RAWIO
+	  ENOMEM	Unable to allocate memory for task
+
+
+
+
+HDIO_DRIVE_CMD_AEB		HDIO_DRIVE_TASK
+
+	Not implemented, as of 2.6.8.1
+
+
+
+HDIO_SET_32BIT			change io_32bit flags
+
+	usage:
+
+	  int val;
+	  ioctl(fd, HDIO_SET_32BIT, val);
+
+	inputs:
+	  New value for io_32bit flag
+
+	outputs:	none
+
+	error return:
+	  EINVAL	(bdev != bdev->bd_contains) (not sure what this means)
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  EINVAL	value out of range [0 3]
+	  EBUSY		Controller busy
+
+
+
+
+HDIO_SET_NOWERR			change ignore-write-error flag
+
+	usage:
+
+	  int val;
+	  ioctl(fd, HDIO_SET_NOWERR, val);
+
+	inputs:
+	  New value for ignore-write-error flag.  Used for ignoring
+	  WRERR_STAT
+
+	outputs:	none
+
+	error return:
+	  EINVAL	(bdev != bdev->bd_contains) (not sure what this means)
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  EINVAL	value out of range [0 1]
+	  EBUSY		Controller busy
+
+
+
+HDIO_SET_DMA			change use-dma flag
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_SET_DMA, val);
+
+	inputs:
+	  New value for use-dma flag
+
+	outputs:	none
+
+	error return:
+	  EINVAL	(bdev != bdev->bd_contains) (not sure what this means)
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  EINVAL	value out of range [0 1]
+	  EBUSY		Controller busy
+
+
+
+HDIO_SET_PIO_MODE		reconfig interface to new speed
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_SET_PIO_MODE, val);
+
+	inputs:
+	  New interface speed.
+
+	outputs:	none
+
+	error return:
+	  EINVAL	(bdev != bdev->bd_contains) (not sure what this means)
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  EINVAL	value out of range [0 255]
+	  EBUSY		Controller busy
+
+
+
+HDIO_SCAN_HWIF			register and (re)scan interface
+
+	usage:
+
+	  int args[3]
+	  ...
+	  ioctl(fd, HDIO_SCAN_HWIF, args);
+
+	inputs:
+	  args[0]	io address to probe
+	  args[1]	control address to probe
+	  args[2]	irq number
+
+	outputs:	none
+
+	error returns:
+	  EACCES	Access denied:  requires CAP_SYS_RAWIO
+	  EIO		Probe failed.
+
+	notes:
+
+	  This ioctl initializes the addresses and irq for a disk
+	  controller, probes for drives, and creates /proc/ide
+	  interfaces as appropiate.
+
+
+
+HDIO_UNREGISTER_HWIF		unregister interface
+
+	usage:
+
+	  int index;
+	  ioctl(fd, HDIO_UNREGISTER_HWIF, index);
+
+	inputs:
+	  index		index of hardware interface to unregister
+
+	outputs:	none
+
+	error returns:
+	  EACCES	Access denied:  requires CAP_SYS_RAWIO
+
+	notes:
+
+	  This ioctl removes a hardware interface from the kernel.
+
+	  Currently (2.6.8) this ioctl silently fails if any drive on
+	  the interface is busy.
+
+
+
+HDIO_SET_WCACHE			change write cache enable-disable
+
+	usage:
+
+	  int val;
+	  ioctl(fd, HDIO_SET_WCACHE, val);
+
+	inputs:
+	  New value for write cache enable
+
+	outputs:	none
+
+	error return:
+	  EINVAL	(bdev != bdev->bd_contains) (not sure what this means)
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  EINVAL	value out of range [0 1]
+	  EBUSY		Controller busy
+
+
+
+HDIO_SET_ACOUSTIC		change acoustic behavior
+
+	usage:
+
+	  int val;
+	  ioctl(fd, HDIO_SET_ACOUSTIC, val);
+
+	inputs:
+	  New value for drive acoustic settings
+
+	outputs:	none
+
+	error return:
+	  EINVAL	(bdev != bdev->bd_contains) (not sure what this means)
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  EINVAL	value out of range [0 254]
+	  EBUSY		Controller busy
+
+
+
+HDIO_SET_QDMA			change use-qdma flag
+
+	Not implemented, as of 2.6.8.1
+
+
+
+HDIO_SET_ADDRESS		change lba addressing modes
+
+	usage:
+
+	  int val;
+	  ioctl(fd, HDIO_SET_ADDRESS, val);
+
+	inputs:
+	  New value for addressing mode
+	    0 = 28-bit
+	    1 = 48-bit
+	    2 = 48-bit doing 28-bit
+
+	outputs:	none
+
+	error return:
+	  EINVAL	(bdev != bdev->bd_contains) (not sure what this means)
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  EINVAL	value out of range [0 2]
+	  EBUSY		Controller busy
+	  EIO		Drive does not support lba48 mode.
+
+
+HDIO_SET_IDE_SCSI
+
+	usage:
+
+	  long val;
+	  ioctl(fd, HDIO_SET_IDE_SCSI, val);
+
+	inputs:
+	  New value for scsi emulation mode (?)
+
+	outputs:	none
+
+	error return:
+	  EINVAL	(bdev != bdev->bd_contains) (not sure what this means)
+	  EACCES	Access denied:  requires CAP_SYS_ADMIN
+	  EINVAL	value out of range [0 1]
+	  EBUSY		Controller busy
+
+
+
+HDIO_SET_SCSI_IDE
+
+	Not implemented, as of 2.6.8.1
+
+
diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt
index b8933206f43586..c91caf7eb30366 100644
--- a/Documentation/kbuild/modules.txt
+++ b/Documentation/kbuild/modules.txt
@@ -1,68 +1,419 @@
-For now this is a raw copy from the old Documentation/kbuild/modules.txt,
-which was removed in 2.6.0-test5.
-The information herein is correct but not complete.
-
-Installing modules in a non-standard location
----------------------------------------------
-When the modules needs to be installed under another directory
-the INSTALL_MOD_PATH can be used to prefix "/lib/modules" as seen
-in the following example:
-
-make INSTALL_MOD_PATH=/frodo modules_install
-
-This will install the modules in the directory /frodo/lib/modules.
-/frodo can be a NFS mounted filesystem on another machine, allowing
-out-of-the-box support for installation on remote machines.
-
-
-Compiling modules outside the official kernel
----------------------------------------------
-
-Often modules are developed outside the official kernel.  To keep up
-with changes in the build system the most portable way to compile a
-module outside the kernel is to use the kernel build system,
-kbuild. Use the following command-line:
-
-make -C path/to/kernel/src M=$PWD modules
-
-This requires that a makefile exits made in accordance to
-Documentation/kbuild/makefiles.txt. Read that file for more details on
-the build system.
-
-The following is a short summary of how to write your Makefile to get
-you up and running fast. Assuming your module will be called
-yourmodule.ko, your code should be in yourmodule.c and your Makefile
-should include
-
-obj-m := yourmodule.o
-
-If the code for your module is in multiple files that need to be
-linked, you need to tell the build system which files to compile. In
-the case of multiple files, none of these files can be named
-yourmodule.c because doing so would cause a problem with the linking
-step. Assuming your code exists in file1.c, file2.c, and file3.c and
-you want to build yourmodule.ko from them, your Makefile should
-include
-
-obj-m := yourmodule.o
-yourmodule-objs := file1.o file2.o file3.o
-
-Now for a final example to put it all together. Assuming the
-KERNEL_SOURCE environment variable is set to the directory where you
-compiled the kernel, a simple Makefile that builds yourmodule.ko as
-described above would look like
-
-# Tells the build system to build yourmodule.ko.
-obj-m := yourmodule.o
-
-# Tells the build system to build these object files and link them as
-# yourmodule.o, before building yourmodule.ko. This line can be left
-# out if all the code for your module is in one file, yourmodule.c. If
-# you are using multiple files, none of these files can be named
-# yourmodule.c.
-yourmodule-objs := file1.o file2.o file3.o
-
-# Invokes the kernel build system to come back to the current
-# directory and build yourmodule.ko.
-default:
-	make -C ${KERNEL_SOURCE} M=`pwd` modules
+
+In this document you will find information about:
+- how to build external modules
+- how to make your module use kbuild infrastructure
+- how kbuild will install a kernel
+- how to install modules in a non-standard location
+
+=== Table of Contents
+
+	=== 1 Introduction
+	=== 2 How to build external modules
+	   --- 2.1 Building external modules
+	   --- 2.2 Available targets
+	   --- 2.3 Available options
+	   --- 2.4 Preparing the kernel tree for module build
+	=== 3. Example commands
+	=== 4. Creating a kbuild file for an external module
+	=== 5. Include files
+	   --- 5.1 How to include files from the kernel include dir
+	   --- 5.2 External modules using an include/ dir
+	=== 6. Module installation
+	   --- 6.1 INSTALL_MOD_PATH
+	   --- 6.2 INSTALL_MOD_DIR
+	=== 7. Module versioning
+	=== 8. Tips & Tricks
+	   --- 8.1 Testing for CONFIG_FOO_BAR
+
+
+
+=== 1. Introduction
+
+kbuild includes functionality for building modules both
+within the kernel source tree and outside the kernel source tree.
+The latter is usually referred to as external modules and is used
+both during development and for modules that are not planned to be
+included in the kernel tree.
+
+What is covered within this file is mainly information to authors
+of modules. The author of an external modules should supply
+a makefile that hides most of the complexity so one only has to type
+'make' to buld the module. A complete example will be present in
+chapter ¤. Creating a kbuild file for an external module".
+
+
+=== 2. How to build external modules
+
+kbuild offers functionality to build external modules, with the
+prerequisite that there is a pre-built kernel available with full source.
+A subset of the targets available when building the kernel is available
+when building an external module.
+
+--- 2.1 Building external modules
+
+	Use the following command to build an external module:
+
+		make -C <path-to-kernel> M=`pwd`
+
+	For the running kernel use:
+		make -C /lib/modules/`uname -r`/build M=`pwd`
+
+	For the above command to succeed the kernel must have been built with
+	modules enabled.
+
+	To install the modules that were just built:
+
+		make -C <path-to-kernel> M=`pwd` modules_install
+
+	More complex examples later, the above should get you going.
+
+--- 2.2 Available targets
+
+	$KDIR refers to path to kernel source top-level directory
+
+	make -C $KDIR M=`pwd`
+		Will build the module(s) located in current directory.
+		All output files will be located in the same directory
+		as the module source.
+		No attempts are made to update the kernel source, and it is
+		a precondition that a successful make has been executed
+		for the kernel.
+
+	make -C $KDIR M=`pwd` modules
+		The modules target is implied when no target is given.
+		Same functionality as if no target was specified.
+		See description above.
+
+	make -C $KDIR M=$PWD modules_install
+		Install the external module(s).
+		Installation default is in /lib/modules/<kernel-version>/extra,
+		but may be prefixed with INSTALL_MOD_PATH - see separate chater.
+
+	make -C $KDIR M=$PWD clean
+		Remove all generated files for the module - the kernel
+		source directory is not moddified.
+
+	make -C $KDIR M=`pwd` help
+		help will list the available target when building external
+		modules.
+
+--- 2.3 Available options:
+
+	$KDIR refer to path to kernel src
+
+	make -C $KDIR
+		Used to specify where to find the kernel source.
+		'$KDIR' represent the directory where the kernel source is.
+		Make will actually change directory to the specified directory
+		when executed but change back when finished.
+
+	make -C $KDIR M=`pwd`
+		M= is used to tell kbuild that an external module is
+		being built.
+		The option given to M= is the directory where the external
+		module (kbuild file) is located.
+		When an external module is being built only a subset of the
+		usual targets are available.
+
+	make -C $KDIR SUBDIRS=`pwd`
+		Same as M=. The SUBDIRS= syntax is kept for backwards
+		compatibility.
+
+--- 2.4 Preparing the kernel tree for module build
+
+	To make sure the kernel contains the information required to
+	build external modules the target 'modules_prepare' must be used.
+	'module_prepare' solely exists as a simple way to prepare
+	a kernel for building external modules.
+	Note: modules_prepare will not build Module.symvers even if
+	      CONFIG_MODULEVERSIONING is set.
+	      Therefore a full kernel build needs to be executed to make
+	      module versioning work.
+
+
+=== 3. Example commands
+
+This example shows the actual commands to be executed when building
+an external module for the currently running kernel.
+In the example below the distribution is supposed to use the
+facility to locate output files for a kernel compile in a different
+directory than the kernel source - but the examples will also work
+when the source and the output files are mixed in the same directory.
+
+# Kernel source
+/lib/modules/<kernel-version>/source -> /usr/src/linux-<version>
+
+# Output from kernel compile
+/lib/modules/<kernel-version>/build -> /usr/src/linux-<version>-up
+
+Change to the directory where the kbuild file is located and execute
+the following commands to build the module:
+
+	cd /home/user/src/module
+	make -C /usr/src/`uname -r`/source            \
+	        O=/lib/modules/`uname-r`/build        \
+	        M=`pwd`
+
+Then to install the module use the following command:
+
+	make -C /usr/src/`uname -r`/source            \
+	        O=/lib/modules/`uname-r`/build        \
+	        M=`pwd`                               \
+		modules_install
+
+If one looks closely you will see that this is the same commands as
+listed before - with the directories spelled out.
+
+The above are rather long commands, and the following chapter
+lists a few tricks to make it all easier.
+
+
+=== 4. Creating a kbuild file for an external module
+
+kbuild is the build system for the kernel, and external modules
+must use kbuild to stay compatible with changes in the build system
+and to pick up the right flags to gcc etc.
+
+The kbuild file used as input shall follow the syntax described
+in Documentation/kbuild/makefiles.txt. This chapter will introduce a few
+more tricks to be used when dealing with external modules.
+
+In the following a Makefile will be created for a module with the
+following files:
+	8123_if.c
+	8123_if.h
+	8123_pci.c
+	8123_bin.o_shipped	<= Binary blob
+
+--- 4.1 Shared Makefile for module and kernel
+
+	An external module always includes a wrapper Makefile supporting
+	building the module using 'make' with no arguments.
+	The Makefile provided will most likely include additional
+	functionality such as test targets etc. and this part shall
+	be filtered away from kbuild since it may impact kbuild if
+	name clashes occurs.
+
+	Example 1:
+		--> filename: Makefile
+		ifneq ($(KERNELRELEASE),)
+		# kbuild part of makefile
+		obj-m  := 8123.o
+		8123-y := 8123_if.o 8123_pci.o 8123_bin.o
+
+		else
+		# Normal Makefile
+
+		KERNELDIR := /lib/modules/`uname -r`/build
+		all::
+			$(MAKE) -C $KERNELDIR M=`pwd` $@
+
+		# Module specific targets
+		genbin:
+			echo "X" > 8123_bini.o_shipped
+
+		endif
+
+	In example 1 the check for KERNELRELEASE is used to separate
+	the two parts of the Makefile. kbuild will only see the two
+	assignments whereas make will see everything except the two
+	kbuild assignments.
+
+	In recent versions of the kernel, kbuild will look for a file named
+	Kbuild and as second option look for a file named Makefile.
+	Utilising the Kbuild file makes us split up the Makefile in example 1
+	into two files as shown in example 2:
+
+	Example 2:
+		--> filename: Kbuild
+		obj-m  := 8123.o
+		8123-y := 8123_if.o 8123_pci.o 8123_bin.o
+
+		--> filename: Makefile
+		KERNELDIR := /lib/modules/`uname -r`/build
+		all::
+			$(MAKE) -C $KERNELDIR M=`pwd` $@
+
+		# Module specific targets
+		genbin:
+			echo "X" > 8123_bin_shipped
+
+
+	In example 2 we are down to two fairly simple files and for simple
+	files as used in this example the split is questionable. But some
+	external modules use Makefiles of several hundred lines and here it
+	really pays off to separate the kbuild part from the rest.
+	Example 3 shows a backward compatible version.
+
+	Example 3:
+		--> filename: Kbuild
+		obj-m  := 8123.o
+		8123-y := 8123_if.o 8123_pci.o 8123_bin.o
+
+		--> filename: Makefile
+		ifneq ($(KERNELRELEASE),)
+		include Kbuild
+		else
+		# Normal Makefile
+
+		KERNELDIR := /lib/modules/`uname -r`/build
+		all::
+			$(MAKE) -C $KERNELDIR M=`pwd` $@
+
+		# Module specific targets
+		genbin:
+			echo "X" > 8123_bin_shipped
+
+		endif
+
+		The trick here is to include the Kbuild file from Makefile so
+		if an older version of kbuild picks up the Makefile the Kbuild
+		file will be included.
+
+--- 4.2 Binary blobs included in a module
+
+	Some external modules needs to include a .o as a blob. kbuild
+	has support for this, but requires the blob file to be named
+	<filename>_shipped. In our example the blob is named
+	8123_bin.o_shipped and when the kbuild rules kick in the file
+	8123_bin.o is created as a simple copy off the 8213_bin.o_shipped file
+	with the _shipped part stripped of the filename.
+	This allows the 8123_bin.o filename to be used in the assignment to
+	the module.
+
+	Example 4:
+		obj-m  := 8123.o
+		8123-y := 8123_if.o 8123_pci.o 8123_bin.o
+
+	In example 4 there is no distinction between the ordinary .c/.h files
+	and the binary file. But kbuild will pick up different rules to create
+	the .o file.
+
+
+=== 5. Include files
+
+Include files are a necessity when a .c file uses something from another .c
+files (not strictly in the sense of .c but if good programming practice is
+used). Any module that consist of more than one .c file will have a .h file
+for one of the .c files. 
+- If the .h file only describes a module internal interface then the .h file
+  shall be placed in the same directory as the .c files.
+- If the .h files describe an interface used by other parts of the kernel
+  located in different directories, the .h files shall be located in
+  include/linux/ or other include/ directories as appropriate.
+
+One exception for this rule is larger subsystems that have their own directory
+under include/ such as include/scsi. Another exception is arch-specific
+.h files which are located under include/asm-$(ARCH)/*.
+
+External modules have a tendency to locate include files in a separate include/
+directory and therefore needs to deal with this in their kbuild file.
+
+--- 5.1 How to include files from the kernel include dir
+
+	When a module needs to include a file from include/linux/ then one
+	just uses:
+
+		#include <linux/modules.h>
+
+	kbuild will make sure to add options to gcc so the relevant
+	directories are searched.
+	Likewise for .h files placed in the same directory as the .c file.
+
+		#include "8123_if.h"
+
+	will do the job.
+
+--- 5.2 External modules using an include/ dir
+
+	External modules often locate their .h files in a separate include/
+	directory although this is not usual kernel style. When an external
+	module uses an include/ dir then kbuild needs to be told so.
+	The trick here is to use either EXTRA_CFLAGS (take effect for all .c
+	files) or CFLAGS_$F.o (take effect only for a single file).
+
+	In our example if we move 8123_if.h to a subdirectory named include/
+	the resulting Kbuild file would look like:
+
+		--> filename: Kbuild
+		obj-m  := 8123.o
+
+		EXTRA_CFLAGS := -Iinclude
+		8123-y := 8123_if.o 8123_pci.o 8123_bin.o
+
+	Note that in the assingment there is no space between -I and the path.
+	This is a kbuild limitation and no space must be present.
+
+
+=== 6. Module installation
+
+Modules which are included in the kernel is installed in the directory:
+
+	/lib/modules/$(KERNELRELEASE)/kernel
+
+External modules are installed in the directory:
+
+	/lib/modules/$(KERNELRELEASE)/extra
+
+--- 6.1 INSTALL_MOD_PATH
+
+	Above are the default directories, but as always some level of
+	customization is possible. One can prefix the path using the variable
+	INSTALL_MOD_PATH:
+
+		$ make INSTALL_MOD_PATH=/frodo modules_install
+		=> Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel
+
+	INSTALL_MOD_PATH may be set as an ordinary shell variable or as in the
+	example above be specified on the commandline when calling make.
+	INSTALL_MOD_PATH has effect both when installing modules included in
+	the kernel as well as when installing external modules.
+
+--- 6.2 INSTALL_MOD_DIR
+
+	When installing external modules they are default installed in a
+	directory under /lib/modules/$(KERNELRELEASE)/extra, but one may wish
+	to locate modules for a specific functionality in a separate
+	directory. For this purpose one can use INSTALL_MOD_DIR to specify an
+	alternative name than 'extra'.
+
+		$ make INSTALL_MOD_DIR=gandalf -C KERNELDIR \
+			M=`pwd` modules_install
+		=> Install dir: /lib/modules/$(KERNELRELEASE)/gandalf
+
+
+=== 7. Module versioning
+
+Module versioning are enabled by the CONFIG_MODVERSIONS tag.
+
+Module versioning is used as a simple ABI consistency check. The Module
+versioning creates a CRC value of the full prototype for an exported symbol and
+when a module is loaded/used then the CRC values contained in the kernel are
+compared with similar values in the module. If they are not equal then the
+kernel refuses to load the module.
+
+During a kernel build a file named Module.symvers will be generated. This
+file includes the symbol version of all symbols within the kernel. If the 
+Module.symvers file is saved from the last full kernel compile one does not
+have to do a full kernel compile to build a module version's compatible module.
+
+=== 8. Tips & Tricks
+
+--- 8.1 Testing for CONFIG_FOO_BAR
+
+	Modules often needs to check for certain CONFIG_ options to decide if
+	a specific feature shall be included in the module. When kbuild is used
+	this is done by referencing the CONFIG_ variable directly.
+
+		#fs/ext2/Makefile
+		obj-$(CONFIG_EXT2_FS) += ext2.o
+
+		ext2-y := balloc.o bitmap.o dir.o
+		ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
+
+	External modules have traditionally used grep to check for specific
+	CONFIG_ settings directly in .config. This usage is broken.
+	As introduced before external modules shall use kbuild when building
+	and therefore can use the same methods as in-kernel modules when testing
+	for CONFIG_ definitions.
+
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index b1d175e3a8e196..844301d6b93cbe 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -312,8 +312,24 @@ running once the system is up.
 	condev=		[HW,S390] console device
 	conmode=
  
-	console=	[KNL] Output console
-			Console device and comm spec (speed, control, parity).
+	console=	[KNL] Output console device and options.
+
+		tty<n>	Use the virtual console device <n>.
+
+		ttyS<n>[,options]
+			Use the specified serial port.  The options are of
+			the form "bbbbpn", where "bbbb" is the baud rate,
+			"p" is parity ("n", "o", or "e"), and "n" is bits.
+			Default is "9600n8".
+
+			See also Documentation/serial-console.txt.
+
+		uart,io,<addr>[,options]
+		uart,mmio,<addr>[,options]
+			Start an early, polled-mode console on the 8250/16550
+			UART at the specified I/O port or MMIO address,
+			switching to the matching ttyS device later.  The
+			options are the same as for ttyS, above.
 
 	cpcihp_generic=	[HW,PCI] Generic port I/O CompactPCI driver
 			Format: <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
@@ -657,9 +673,10 @@ running once the system is up.
 	maxcpus=	[SMP] Maximum number of processors that	an SMP kernel
 			should make use of
 
-	max_scsi_luns=	[SCSI]
+	max_luns=	[SCSI] Maximum number of LUNs to probe
+			Should be between 1 and 2^32-1.
 
-	max_scsi_report_luns=
+	max_report_luns=
 			[SCSI] Maximum number of LUNs received
 			Should be between 1 and 16384.
 
@@ -684,6 +701,9 @@ running once the system is up.
 	mem=nn[KMG]	[KNL,BOOT] Force usage of a specific amount of memory
 			Amount of memory to be used when the kernel is not able
 			to see the whole system memory or for test.
+			[IA-32] Use together with memmap= to avoid physical
+			address space collisions. Without memmap= PCI devices
+			could be placed at addresses belonging to unused RAM.
 
 	mem=nopentium	[BUGS=IA-32] Disable usage of 4MB pages for kernel
 			memory.
@@ -789,8 +809,6 @@ running once the system is up.
 
 	nofxsr		[BUGS=IA-32]
 
-	nohighio	[BUGS=IA-32] Disable highmem block I/O.
-
 	nohlt		[BUGS=ARM]
  
 	no-hlt		[BUGS=IA-32] Tells the kernel that the hlt
@@ -1000,10 +1018,9 @@ running once the system is up.
 			(param: profile step/bucket size as a power of 2 for
 				statistical time based profiling)
 
-	processor.c2=	[HW, ACPI]
-	processor.c3=	[HW, ACPI]
-			0 - disable C2 or C3 idle power saving state.
-			1 - enable C2 or C3 (default unless DMI blacklist entry)
+	processor.max_cstate=   [HW, ACPI]
+			Limit processor to maximum C-state
+			max_cstate=9 overrides any DMI blacklist limit.
 
 	prompt_ramdisk=	[RAM] List of RAM disks to prompt for floppy disk
 			before loading.
@@ -1264,11 +1281,6 @@ running once the system is up.
 	specialix=	[HW,SERIAL] Specialix multi-serial port adapter
 			See Documentation/specialix.txt.
 
-	speedstep_coppermine=
-			[HW,IA-32] Take CPU in your notebook as SpeedStep-capable
-			See comment before function speedstep_setup() in
-			arch/i386/kernel/cpu/cpufreq/speedstep.c.
-
 	spia_io_base=	[HW,MTD]
 	spia_fio_base=
 	spia_pedr=
diff --git a/Documentation/memory.txt b/Documentation/memory.txt
index 7af1709e8facbd..2b3dedd39538f0 100644
--- a/Documentation/memory.txt
+++ b/Documentation/memory.txt
@@ -21,6 +21,8 @@ systems.
 All of these problems can be addressed with the "mem=XXXM" boot option
 (where XXX is the size of RAM to use in megabytes).  
 It can also tell Linux to use less memory than is actually installed.
+If you use "mem=" on a machine with PCI, consider using "memmap=" to avoid
+physical address space collisions.
 
 See the documentation of your boot loader (LILO, loadlin, etc.) about
 how to pass options to the kernel.
@@ -44,7 +46,9 @@ Try:
 	* Disabling the cache from the BIOS.
 
 	* Try passing the "mem=4M" option to the kernel to limit
-	  Linux to using a very small amount of memory.
+	  Linux to using a very small amount of memory. Use "memmap="-option
+	  together with "mem=" on systems with PCI to avoid physical address
+	  space collisions.
 
 
 Other tricks:
diff --git a/Documentation/nmi_watchdog.txt b/Documentation/nmi_watchdog.txt
index 6cad46e8ac2d40..c025a4561c1033 100644
--- a/Documentation/nmi_watchdog.txt
+++ b/Documentation/nmi_watchdog.txt
@@ -54,6 +54,20 @@ then the system has crashed so hard (eg. hardware-wise) that either it
 cannot even accept NMI interrupts, or the crash has made the kernel
 unable to print messages.
 
+Be aware that when using local APIC, the frequency of NMI interrupts
+it generates, depends on the system load. The local APIC NMI watchdog,
+lacking a better source, uses the "cycles unhalted" event. As you may
+guess it doesn't tick when the CPU is in the halted state (which happens
+when the system is idle), but if your system locks up on anything but the
+"hlt" processor instruction, the watchdog will trigger very soon as the
+"cycles unhalted" event will happen every clock tick. If it locks up on
+"hlt", then you are out of luck -- the event will not happen at all and the
+watchdog won't trigger. This is a shortcoming of the local APIC watchdog
+-- unfortunately there is no "clock ticks" event that would work all the
+time. The I/O APIC watchdog is driven externally and has no such shortcoming.  
+But its NMI frequency is much higher, resulting in a more significant hit
+to the overall system performance.
+
 NOTE: starting with 2.4.2-ac18 the NMI-oopser is disabled by default,
 you have to enable it with a boot time parameter.  Prior to 2.4.2-ac18
 the NMI-oopser is enabled unconditionally on x86 SMP boxes.
diff --git a/Documentation/pci.txt b/Documentation/pci.txt
index 04f1ba9c1a20e5..b0676d1145ca8f 100644
--- a/Documentation/pci.txt
+++ b/Documentation/pci.txt
@@ -156,11 +156,9 @@ Searching by both vendor/device and subsystem vendor/device ID:
 VENDOR_ID or DEVICE_ID.  This allows searching for any device from a
 specific vendor, for example.
 
-Note that these functions are not hotplug-safe.  Their hotplug-safe
-replacements are pci_get_device(), pci_get_class() and pci_get_subsys().
-They increment the reference count on the pci_dev that they return.
-You must eventually (possibly at module unload) decrement the reference
-count on these devices by calling pci_dev_put().
+   These functions are hotplug-safe. They increment the reference count on
+the pci_dev that they return. You must eventually (possibly at module unload)
+decrement the reference count on these devices by calling pci_dev_put().
 
 
 3. Enabling and disabling devices
diff --git a/Documentation/rocket.txt b/Documentation/rocket.txt
index f9345cd14e166d..a1067800445192 100644
--- a/Documentation/rocket.txt
+++ b/Documentation/rocket.txt
@@ -20,8 +20,27 @@ or installing it into kernels which do not have the driver configured
 into them.  Installations instructions for the external module
 are in the included README and HW_INSTALL files.
 
-RocketPort ISA and RocketModem II PCI boards are also supported by this
-driver, but must use the external module driver for configuration reasons.  
+RocketPort ISA and RocketModem II PCI boards currently are only supported by
+this driver in module form.
+
+The RocketPort ISA board requires I/O ports to be configured by the DIP
+switches on the board.  See the section "ISA Rocketport Boards" below for
+information on how to set the DIP switches.
+
+You pass the I/O port to the driver using the following module parameters:
+
+board1 :	I/O port for the first ISA board
+board2 :	I/O port for the second ISA board
+board3 :	I/O port for the third ISA board
+board4 :	I/O port for the fourth ISA board
+
+There is a set of utilities and scripts provided with the external driver
+( downloadable from http://www.comtrol.com ) that ease the configuration and
+setup of the ISA cards.
+
+The RocketModem II PCI boards require firmware to be loaded into the card
+before it will function.  The driver has only been tested as a module for this
+board.
 
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 
@@ -55,12 +74,95 @@ create the RocketPort/RocketModem device names, use the command
 >mknod /dev/ttyR1 c 46 1
 >mknod /dev/ttyR2 c 46 2  
 
-The Linux script MAKEDEV will create the first 16 ttyRx device names (nodes) for you:
+The Linux script MAKEDEV will create the first 16 ttyRx device names (nodes)
+for you:
 
 >/dev/MAKEDEV ttyR
 
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 
+ISA Rocketport Boards
+---------------------
+
+You must assign and configure the I/O addresses used by the ISA Rocketport
+card before installing and using it.  This is done by setting a set of DIP
+switches on the Rocketport board.
+
+
+SETTING THE I/O ADDRESS
+-----------------------
+
+Before installing RocketPort(R) or RocketPort RA boards, you must find
+a range of I/O addresses for it to use. The first RocketPort card
+requires a 68-byte contiguous block of I/O addresses, starting at one
+of the following: 0x100h, 0x140h, 0x180h, 0x200h, 0x240h, 0x280h,
+0x300h, 0x340h, 0x380h.  This I/O address must be reflected in the DIP
+switiches of *all* of the Rocketport cards.
+
+The second, third, and fourth RocketPort cards require a 64-byte
+contiguous block of I/O addresses, starting at one of the following
+I/O addresses: 0x100h, 0x140h, 0x180h, 0x1C0h, 0x200h, 0x240h, 0x280h,
+0x2C0h, 0x300h, 0x340h, 0x380h, 0x3C0h.  The I/O address used by the
+second, third, and fourth Rocketport cards (if present) are set via
+software control.  The DIP switch settings for the I/O address must be
+set to the value of the first Rocketport cards.
+
+In order to destinguish each of the card from the others, each card
+must have a unique board ID set on the dip switches.  The first
+Rocketport board must be set with the DIP switches corresponding to
+the first board, the second board must be set with the DIP switches
+corresponding to the second board, etc.  IMPORTANT: The board ID is
+the only place where the DIP switch settings should differ between the
+various Rocketport boards in a system.
+
+The I/O address range used by any of the RocketPort cards must not
+conflict with any other cards in the system, including other
+RocketPort cards.  Below, you will find a list of commonly used I/O
+address ranges which may be in use by other devices in your system.
+On a Linux system, "cat /proc/ioports" will also be helpful in
+identifying what I/O addresses are being used by devics on your
+system.
+
+Remember, the FIRST RocketPort uses 68 I/O addresses.  So, if you set it
+for 0x100, it will occupy 0x100 to 0x143.  This would mean that you
+CAN NOT set the second, third or fourth board for address 0x140 since
+the first 4 bytes of that range are used by the first board.  You would
+need to set the second, third, or fourth board to one of the next available
+blocks such as 0x180.
+
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+
+RocketPort and RocketPort RA SW1 Settings:
+
+          +-------------------------------+
+          | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
+          +-------+-------+---------------+
+          | Unused| Card  | I/O Port Block|
+          +-------------------------------+
+
+DIP Switches                             DIP Switches
+7    8                                   6    5
+===================                      ===================
+On   On   UNUSED, MUST BE ON.            On   On   First Card    <==== Default
+                                         On   Off  Second Card
+                                         Off  On   Third Card
+                                         Off  Off  Fourth Card
+
+DIP Switches         I/O Address Range
+4    3    2    1     Used by the First Card
+=====================================
+On   Off  On   Off   100-143
+On   Off  Off  On    140-183
+On   Off  Off  Off   180-1C3       <==== Default
+Off  On   On   Off   200-243
+Off  On   Off  On    240-283
+Off  On   Off  Off   280-2C3
+Off  Off  On   Off   300-343
+Off  Off  Off  On    340-383
+Off  Off  Off  Off   380-3C3
+
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+
 REPORTING BUGS
 --------------
 
diff --git a/Documentation/s390/monreader.txt b/Documentation/s390/monreader.txt
index 2150e5fc39738e..d843bb04906edd 100644
--- a/Documentation/s390/monreader.txt
+++ b/Documentation/s390/monreader.txt
@@ -1,5 +1,5 @@
 
-Date  : 2004-Nov-04
+Date  : 2004-Nov-26
 Author: Gerald Schaefer (geraldsc@de.ibm.com)
 
 
@@ -72,7 +72,8 @@ the same DCSS. The CP command Q MONITOR (Class E privileged) shows the name
 of the monitor DCSS, if already defined, and the users connected to the
 *MONITOR service.
 Refer to the "z/VM Performance" book (SC24-6109-00) on how to create a monitor
-DCSS, you need Class E privileges to define and save a DCSS.
+DCSS if your z/VM doesn't have one already, you need Class E privileges to
+define and save a DCSS.
 
 Example:
 --------
@@ -121,20 +122,41 @@ supported.
 
 Read:
 -----
-Reading from the device provides a set of one or more contiguous monitor
-records, there is no control data (unlike the CMS MONWRITE utility output).
-The monitor record layout can be found here (z/VM 5.1):
-http://www.vm.ibm.com/pubs/mon510/index.html
-
-Each set of records is exclusively composed of either event records or sample
-records. The end of such a set of records is indicated by a successful read
-with a return value of 0 (0-Byte read).
-Any received data must be considered invalid until a complete record set was
-read successfully, including the closing 0-Byte read. Therefore you should
+Reading from the device provides a 12 Byte monitor control element (MCE),
+followed by a set of one or more contiguous monitor records (similar to the
+output of the CMS utility MONWRITE without the 4K control blocks). The MCE
+contains information on the type of the following record set (sample/event
+data), the monitor domains contained within it and the start and end address
+of the record set in the monitor DCSS. The start and end address can be used
+to determine the size of the record set, the end address is the address of the
+last byte of data. The start address is needed to handle "end-of-frame" records
+correctly (domain 1, record 13), i.e. it can be used to determine the record
+start offset relative to a 4K page (frame) boundary.
+
+See "Appendix A: *MONITOR" in the "z/VM Performance" document for a description
+of the monitor control element layout. The layout of the monitor records can
+be found here (z/VM 5.1): http://www.vm.ibm.com/pubs/mon510/index.html
+
+The layout of the data stream provided by the monreader device is as follows:
+...
+<0 byte read>
+<first MCE>              \
+<first set of records>    |
+...                       |- data set
+<last MCE>                |
+<last set of records>    /
+<0 byte read>
+...
+
+There may be more than one combination of MCE and corresponding record set
+within one data set and the end of each data set is indicated by a successful
+read with a return value of 0 (0 byte read).
+Any received data must be considered invalid until a complete set was
+read successfully, including the closing 0 byte read. Therefore you should
 always read the complete set into a buffer before processing the data.
 
-The maximum size of a set of records can be as large as the size of the
-monitor DCSS, so design the buffer adequately or use dynamic memory allocation
+The maximum size of a data set can be as large as the size of the
+monitor DCSS, so design the buffer adequately or use dynamic memory allocation.
 The size of the monitor DCSS will be printed into syslog after loading the
 module. You can also use the (Class E privileged) CP command Q NSS MAP to
 list all available segments and information about them.
@@ -155,7 +177,7 @@ EOVERFLOW: message limit reached, the data read since the last successful
 
 In the last case (EOVERFLOW) there may be missing data, in the first two cases
 (EIO, EFAULT) there will be missing data. It's up to the application if it will
-continue reading subsequent records or rather exit.
+continue reading subsequent data or rather exit.
 
 Open:
 -----
@@ -163,8 +185,8 @@ Only one user is allowed to open the char device. If it is already in use, the
 open function will fail (return a negative value) and set errno to EBUSY.
 The open function may also fail if an IUCV connection to the *MONITOR service
 cannot be established. In this case errno will be set to EIO and an error
-message with an IPUSER SEVER code will be printed into syslog.
-The IPUSER SEVER codes are described in the "z/VM Performance" book.
+message with an IPUSER SEVER code will be printed into syslog. The IPUSER SEVER
+codes are described in the "z/VM Performance" book, Appendix A.
 
 NOTE:
 -----
diff --git a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid
index ad266137fa8865..79a9aed8e5d7eb 100644
--- a/Documentation/scsi/ChangeLog.megaraid
+++ b/Documentation/scsi/ChangeLog.megaraid
@@ -1,3 +1,21 @@
+Release Date	: Thu Dec  9 19:02:14 EST 2004 - Sreenivas Bagalkote <sreenib@lsil.com>
+
+Current Version	: 2.20.4.1 (scsi module), 2.20.2.3 (cmm module)
+Older Version	: 2.20.4.1 (scsi module), 2.20.2.2 (cmm module)
+
+i.	Fix a bug in kioc's dma buffer deallocation
+
+Release Date	: Thu Nov  4 18:24:56 EST 2004 - Sreenivas Bagalkote <sreenib@lsil.com>
+
+Current Version	: 2.20.4.1 (scsi module), 2.20.2.2 (cmm module)
+Older Version	: 2.20.4.0 (scsi module), 2.20.2.1 (cmm module)
+
+i.	Handle IOCTL cmd timeouts more properly.
+
+ii.	pci_dma_sync_{sg,single}_for_cpu was introduced into megaraid_mbox
+	incorrectly (instead of _for_device). Changed to appropriate
+	pci_dma_sync_{sg,single}_for_device.
+
 Release Date	: Wed Oct 06 11:15:29 EDT 2004 - Sreenivas Bagalkote <sreenib@lsil.com>
 Current Version	: 2.20.4.0 (scsi module), 2.20.2.1 (cmm module)
 Older Version	: 2.20.4.0 (scsi module), 2.20.2.0 (cmm module)
diff --git a/Documentation/sound/oss/ChangeLog.awe b/Documentation/sound/oss/ChangeLog.awe
deleted file mode 100644
index 330cc0e5f10278..00000000000000
--- a/Documentation/sound/oss/ChangeLog.awe
+++ /dev/null
@@ -1,230 +0,0 @@
-ver.0.4.3p4
-	- Bug fix for invalid memory detection when initialized twice
-	- Add sample sharing function - works together with awesfx-0.4.3p3
-	- Add AWE_PROBE_DATA for probing sample id
-
-ver.0.4.3p3
-	- Replace memset to MEMSET (for FreeBSD)
-	- Add PAN_EXCHANGE switch
-
-ver.0.4.3p2
-	- MIDI emulation device is added
-	- Controls volume and filter targets
-	- Include chorus/reverb/equalizer values in MISC_MODE
-
-ver.0.4.3p1
-	- Change the volume calculation method
-	- Support for Tom Lees' PnP driver (v0.3)
-
-ver.0.4.2d
-	- Support for OSS/Free 3.8 on 2.0 kernels.
-	- Support for Linux PnP driver
-	- Support for module (for recent 2.1 kernels and RH5.0)
-	- Support for FreeBSD-3.0 system
-
-ver.0.4.2c
-	- Add a mode to enable drum channel toggle via bank number
-	  change.
-
-ver.0.4.2b
-	- Clear voice position after note on
-	- Change nrvoices according to the current playing mode
-
-ver.0.4.2a
-	- Fix a bug in pitch calculation with scale parameter
-	- Change default chorus & reverb modes
-
-ver.0.4.2
-	- Use indirect voice allocation mode; used as default mode
-	- Add preset mapping
-	- Free buffers when resetting samples
-	- Set default preset/bank/drumset as variable
-	- Fix a bug in exclusive note-off
-	- Add channel reset control macro
-	- Change modwheel sensitivity as variable
-	- Add lock option in open_patch
-	- Add channel priority mode macro, and disable it as default
-	- Add unset effect macro
-	- Add user defined chorus/reverb modes
-	- Do not initialize effect parameters when allocating voices
-	- Accept realtime filter-Q parameter change
-	- Check value range of set/add effects
-	- Change drum flags automatically when receiving bank #128
-
-ver.0.4.1	development versions
-
-ver.0.4.0c
-	- Fix kernel oops when setting AWE_FX_ATTEN
-
-ver.0.4.0b
-	- Do not kill_note in start_note when velocity is zero
-
-ver.0.4.0a
-	- Fix a bug in channel pressure effects
-
-ver.0.4.0
-	- Support dynamic buffer allocation
-	- Add functions to open/close/unload a patch
-	- Change from pointer to integer index in voice/sample lists
-	- Support for Linux/Alpha-AXP
-	- Fix for FreeBSD
-	- Add sostenuto control
-	- Add midi channel priority
-	- Fix a bug in all notes off control
-	- Use AWE_DEFAULT_MEMSIZE always if defined
-	- Fix a bug in awe_reset causes seg fault when no DRAM onboard
-	- Use awe_mem_start variable instead of constant
-
-ver.0.3.3c
-	- Fix IOCTL_TO_USER for OSS-3.8 (on Linux-2.1.25)
-	- Fix i/o macros for mixer controls
-
-ver.0.3.3b
-	- Fix version number in awe_version.h
-	- Fix a small bug in noteoff/release all
-
-ver.0.3.3a
-	- Fix all notes/sounds off
-	- Add layer effect control
-	- Add misc mode controls; realtime pan, version number, etc.
-	- Move gus bank control in misc mode control
-	- Modify awe_operations for OSS3.8b5
-	- Fix installation script
-
-ver.0.3.3
-	- Add bass/treble control in Emu8000 chip
-	- Add mixer device
-	- Fix sustain on to value 127
-
-ver.0.3.2
-	- Refuse linux-2.0.0 at installation
-	- Move awe_voice.h to /usr/include/linux
-
-ver.0.3.1b (not released)
-	- Rewrite chorus/reverb mode change functions
-	- Rewrite awe_detect & awe_check_dram routines
-
-ver.0.3.1a
-	- Fix a bug to reset voice counter in awe_reset
-	- Fix voice balance on GUS mode
-	- Make symlink on /usr/include/asm in install script
-
-ver.0.3.1
-	- Remove zero size arrays from awe_voice.h
-	- Fix init_fm routine
-	- Remove all samples except primary samples in REMOVE_LAST_SAMPLES
-
-ver.0.3.0a
-	- Add AWE_NOTEOFF_ALL control
-	- Remove AWE_INIT_ATTEN control
-
-ver.0.3.0
-	- Fix decay time table
-	- Add exclusive sounds mode
-	- Add capability to get current status
-
-ver.0.2.99e
-	- Add #ifdef for all sounds/notes off controls.
-	- Fix bugs on searching the default drumset/preset.
-	- Fix usslite patch to modify the default Config.in.
-
-ver.0.2.99d
-	- Fix bugs of attack/hold parameters
-	- Fix attack & decay time table
-
-ver.0.2.99c
-	- Change volume control messages (main & expression volume)
-	  to accesspt normal MIDI parameters in channel mode.
-	- Use channel mode in SEQ2 controls.
-
-ver.0.2.99b
-	- #ifdef patch manager functions (for OSS-3.7)
-
-ver.0.2.99a
-	- Fix sustain bug
-
-ver.0.2.99 (0.3 beta)
-	- Support multiple instruments
-
-ver.0.2.0c
-	- Add copyright notice
-	- FreeBSD 2.2-ALPHA integration
-
-ver.0.2.0b
-	- Remove buffered reading appended in v0.2.0a
-	- Remove SMAxW register check on writing
-	- Support Linux 2.1.x kernel
-	- Rewrite installation script
-
-ver.0.2.0a
-	- Define SEQUENCER_C for tuning.h for FreeBSD system
-	- Improvement of sample loading speed
-	- Fix installation script
-	- Add PnP driver functions for ISA PnP driver support
-
-ver.0.2.0
-	- Includes FreeBSD port
-	- Can load GUS compatible patches
-	- Change values of hardware control parameters for compatibility
-	  with GUS driver
-	- Accept 8bit or unsigned wave data
-	- Accept no blank loop data
-	- Add sample mode flags in sample_info
-
-ver.0.1.6
-	- Add voice effects control
-	- Fix awe_voice.h for word alignment
-
-ver.0.1.5c
-	- Fix FM(OPL) playback problem
-
-ver.0.1.5b
-	- Fix pitch calculation for fixed midi key
-
-ver.0.1.5a
-	- Fix bugs in removing samples from linked list.
-
-ver.0.1.5
-	- Add checksum verification for sample uploading
-	  (not compatible from older sample_info structure)
-	- Fix sample offset pointers to (actual value - 1)
-	- Add sequencer command to initialize awe32
-
-ver.0.1.4c
-	- Fix card detection and memory check function to avoid system crash
-	  at booting
-
-ver.0.1.4b
-	- Add release sustain mode
-	- Initialize FM each time after loading samples
-
-ver.0.1.4a
-	- Fix AWE card detection code
-	- Correct FM initialize position 
-	- Add non-releasing mode on voice info
-
-ver.0.1.4
-	- Add AWE card and DRAM detection codes
-	- Add FM initialization code
-	- Modify volume control
-	- Remove linear volume mode
-	- Change memory management; not using malloc dynamically
-	- Add remove-samples command
-	- Use internal id implicitly at loading samples
-
-ver.0.1.3
-	- Fix a bug on patch uploading to RAM
-
-ver.0.1.2
-	- Divide to separated packages
-	- Fix disagreed macro conditions
-	- Fix unresolved function bugs
-	- Integrate VoxWare and USS-Lite driver source (awe_voice.c)
-	  and remove awe_card.c
-
-ver.0.1.1
-	- Fix wrong sample numbers in sbktext
-	- Fix txt2sfx bug
-	- Fix pan parameter calculation
-	- Append USS-Lite/Linux2.0 driver
-
diff --git a/Documentation/sound/oss/ChangeLog.multisound b/Documentation/sound/oss/ChangeLog.multisound
deleted file mode 100644
index a05a74365dd354..00000000000000
--- a/Documentation/sound/oss/ChangeLog.multisound
+++ /dev/null
@@ -1,213 +0,0 @@
-1998-12-04  Andrew T. Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.8.2.2
-
-	* Add msndreset program to shell archive.
-
-1998-11-11  Andrew T. Veliath  <andrewv@usa.net>
-
-	* msnd_pinnacle.c (mixer_ioctl): Add a mixer ioctl for
-	SOUND_MIXER_PRIVATE1 which does a full reset on the card.
-	(mixer_set): Move line in recording source to input monitor, aux
-	input level added, some mixer fixes.
-
-1998-09-10  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.8.2
-
-	* Add SNDCTL_DSP_GETOSPACE and SNDCTL_DSP_GETISPACE ioctls.
-
-1998-09-09  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.8.1
-	
-	* msnd_pinnacle.c: Fix resetting of default audio parameters. Turn
-	flush code from dsp_halt into dsp_write_flush, and use that for
-	SNDCTL_DSP_SYNC.
-
-1998-09-07  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.8.0
-
-	* Provide separate signal parameters for play and record.
-	
-	* Cleanups to locking and interrupt handling, change default
-	fifosize to 128kB.
-
-	* Update version to 0.7.15
-
-	* Interprocess full-duplex support (ie `cat /dev/dsp > /dev/dsp').
-
-	* More mutex sections for read and write fifos (read + write locks
-	added).
-
-1998-09-05  Andrew Veliath  <andrewtv@usa.net>
-
-	* msnd_pinnacle.c: (chk_send_dsp_cmd) Do full DSP reset upon DSP
-	timeout (when not in interrupt; maintains mixer settings).  Fixes
-	to flushing and IRQ ref counting. Rewrote queuing for smoother
-	playback and fixed initial playback cutoff problem.
-
-1998-09-03  Andrew Veliath  <andrewtv@usa.net>
-
-	* Replaced packed structure accesses with standard C equivalents.
-
-1998-09-01  Andrew Veliath  <andrewtv@usa.net>
-
-	* msnd_pinnacle.c: Add non-PnP configuration to driver code, which
-	  will facilitate compiled-in operation.
-
-1998-08-29  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.7.6
-	
-	* msnd_pinnacle.c (dsp_ioctl): Add DSP_GETFMTS, change SAMPLESIZE
-	  to DSP_SETFMT.
-
-	* Update version to 0.7.5
-	
-	* Create pinnaclecfg.c and turn MultiSound doc into a shell
-	  archive with pinnaclecfg.c included.  pinnaclecfg.c can
-	  now fully configure the card in non-PnP mode, including the
-	  joystick and IDE controller.  Also add an isapnp conf
-	  example.
-
-	* Reduce DSP reset timeout from 20000 to 100
-
-1998-08-06  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.7.2
-	
-	* After A/D calibration, do an explicit set to the line input,
-	  rather than using set_recsrc
-
-1998-07-20  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.7.1
-
-	* Add more OSS ioctls
-	
-1998-07-19  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update doc file
-	
-	* Bring back DIGITAL1 with digital parameter to msnd_pinnacle.c
-	  and CONFIG_MSNDPIN_DIGITAL.  I'm not sure this actually works,
-	  since I find audio playback goes into a very speeded mode of
-	  operation, however it might be due to a lack of a digital
-	  source, which I don't have to test.
-
-1998-07-18  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.7.0
-
-	* Can now compile with Alan Cox' 2.0.34-modular-sound patch (so
-	  now it requires >= 2.1.106 or 2.0.34-ms) (note for 2.0.34-ms it
-	  is in the Experimental section)
-
-	* More modularization, consolidation, also some MIDI hooks
-	  installed for future MIDI modules
-
-	* Write flush
-
-	* Change default speed, channels, bit size to OSS/Free defaults
-
-1998-06-02  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.5b
-
-	* Fix version detection
-	
-	* Remove underflow and overflow resets (delay was too long)
-
-	* Replace spinlocked bitops with atomic bit ops
-
-1998-05-27  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.5a
-	
-	* Better recovery from underflow or overflow conditions
-	
-	* Fix a deadlock condition with one thread reading and the other
-	  writing
-
-1998-05-26  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.5
-	
-	* Separate reset queue functions for play and record
-
-	* Add delays in dsp_halt
-
-1998-05-24  Andrew Veliath  <andrewtv@usa.net>
-
-	* Add a check for Linux >= 2.1.95
-	
-	* Remove DIGITAL1 input until I figure out how to make it work
-	
-	* Add HAVE_DSPCODEH which when not defined will load firmware from
-	  files using mod_firmware_load, then release memory after they
-	  are uploaded (requires reorganized OSS).
-
-1998-05-22  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.4c
-
-	* Hopefully fix the mixer volume problem
-
-1998-05-19  Andrew Veliath  <andrewtv@usa.net>
-
-	* Add __initfuncs and __initdatas to reduce resident code size
-
-	* Move bunch of code around, remove some protos
-
-	* Integrate preliminary changes for Alan Cox's OSS reorganization
-	  for non-OSS drivers to coexist with OSS devices on the same
-	  major.  To compile standalone, must now define STANDALONE.
-
-1998-05-16  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.4b
-	
-	* Integrated older card support into a unified driver, tested on a
-	  MultiSound Classic c/o Kendrick Vargas.
-
-1998-05-15  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.4
-	
-	* Fix read/write return values
-
-1998-05-13  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.3
-
-	* Stop play gracefully
-
-	* Add busy flag
-	
-	* Add major and calibrate_signal module parameters
-	
-	* Add ADC calibration
-
-	* Add some OSS compatibility ioctls
-
-	* Add mixer record selection
-	
-	* Add O_NONBLOCK support, separate read/write wait queues
-
-	* Add sample bit size ioctl, expanded sample rate ioctl
-
-	* Playback suspension now resumes
-
-	* Use signal_pending after interruptible_sleep_on
-	
-	* Add recording, change ints to bit flags
-
-1998-05-11  Andrew Veliath  <andrewtv@usa.net>
-
-	* Update version to 0.2
-
-	* Add preliminary playback support
-
-	* Use new Turtle Beach DSP code
\ No newline at end of file
diff --git a/Documentation/stable_api_nonsense.txt b/Documentation/stable_api_nonsense.txt
new file mode 100644
index 00000000000000..c33c99c5100ccc
--- /dev/null
+++ b/Documentation/stable_api_nonsense.txt
@@ -0,0 +1,193 @@
+The Linux Kernel Driver Interface
+(all of your questions answered and then some)
+
+Greg Kroah-Hartman <greg@kroah.com>
+
+This is being written to try to explain why Linux does not have a binary
+kernel interface, nor does it have a stable kernel interface.  Please
+realize that this article describes the _in kernel_ interfaces, not the
+kernel to userspace interfaces.  The kernel to userspace interface is
+the one that application programs use, the syscall interface.  That
+interface is _very_ stable over time, and will not break.  I have old
+programs that were built on a pre 0.9something kernel that still works
+just fine on the latest 2.6 kernel release.  This interface is the one
+that users and application programmers can count on being stable.
+
+
+Executive Summary
+-----------------
+You think you want a stable kernel interface, but you really do not, and
+you don't even know it.  What you want is a stable running driver, and
+you get that only if your driver is in the main kernel tree.  You also
+get lots of other good benefits if your driver is in the main kernel
+tree, all of which has made Linux into such a strong, stable, and mature
+operating system which is the reason you are using it in the first
+place.
+
+
+Intro
+-----
+
+It's only the odd person who wants to write a kernel driver that needs
+to worry about the in-kernel interfaces changing.  For the majority of
+the world, they neither see this interface, nor do they care about it at
+all.
+
+First off, I'm not going to address _any_ legal issues about closed
+source, hidden source, binary blobs, source wrappers, or any other term
+that describes kernel drivers that do not have their source code
+released under the GPL.  Please consult a lawyer if you have any legal
+questions, I'm a programmer and hence, I'm just going to be describing
+the technical issues here (not to make light of the legal issues, they
+are real, and you do need to be aware of them at all times.)
+
+So, there are two main topics here, binary kernel interfaces and stable
+kernel source interfaces.  They both depend on each other, but we will
+discuss the binary stuff first to get it out of the way.
+
+
+Binary Kernel Interface
+-----------------------
+Assuming that we had a stable kernel source interface for the kernel, a
+binary interface would naturally happen too, right?  Wrong.  Please
+consider the following facts about the Linux kernel:
+  - Depending on the version of the C compiler you use, different kernel
+    data structures will contain different alignment of structures, and
+    possibly include different functions in different ways (putting
+    functions inline or not.)  The individual function organization
+    isn't that important, but the different data structure padding is
+    very important.
+  - Depending on what kernel build options you select, a wide range of
+    different things can be assumed by the kernel:
+      - different structures can contain different fields
+      - Some functions may not be implemented at all, (i.e. some locks
+	compile away to nothing for non-SMP builds.)
+      - Parameter passing of variables from function to function can be
+	done in different ways (the CONFIG_REGPARM option controls
+	this.)
+      - Memory within the kernel can be aligned in different ways,
+	depending on the build options.
+  - Linux runs on a wide range of different processor architectures.
+    There is no way that binary drivers from one architecture will run
+    on another architecture properly.
+
+Now a number of these issues can be addressed by simply compiling your
+module for the exact specific kernel configuration, using the same exact
+C compiler that the kernel was built with.  This is sufficient if you
+want to provide a module for a specific release version of a specific
+Linux distribution.  But multiply that single build by the number of
+different Linux distributions and the number of different supported
+releases of the Linux distribution and you quickly have a nightmare of
+different build options on different releases.  Also realize that each
+Linux distribution release contains a number of different kernels, all
+tuned to different hardware types (different processor types and
+different options), so for even a single release you will need to create
+multiple versions of your module.
+
+Trust me, you will go insane over time if you try to support this kind
+of release, I learned this the hard way a long time ago...
+
+
+Stable Kernel Source Interfaces
+-------------------------------
+
+This is a much more "volatile" topic if you talk to people who try to
+keep a Linux kernel driver that is not in the main kernel tree up to
+date over time.
+
+Linux kernel development is continuous and at a rapid pace, never
+stopping to slow down.  As such, the kernel developers find bugs in
+current interfaces, or figure out a better way to do things.  If they do
+that, they then fix the current interfaces to work better.  When they do
+so, function names may change, structures may grow or shrink, and
+function parameters may be reworked.  If this happens, all of the
+instances of where this interface is used within the kernel are fixed up
+at the same time, ensuring that everything continues to work properly.
+
+As a specific examples of this, the in-kernel USB interfaces have
+undergone at least three different reworks over the lifetime of this
+subsystem.  These reworks were done to address a number of different
+issues:
+  - A change from a synchronous model of data streams to an asynchronous
+    one.  This reduced the complexity of a number of drivers and
+    increased the throughput of all USB drivers such that we are now
+    running almost all USB devices at their maximum speed possible.
+  - A change was made in the way data packets were allocated from the
+    USB core by USB drivers so that all drivers now needed to provide
+    more information to the USB core to fix a number of documented
+    deadlocks.
+
+This is in stark contrast to a number of closed source operating systems
+which have had to maintain their older USB interfaces over time.  This
+provides the ability for new developers to accidentally use the old
+interfaces and do things in improper ways, causing the stability of the
+operating system to suffer.
+
+In both of these instances, all developers agreed that these were
+important changes that needed to be made, and they were made, with
+relatively little pain.  If Linux had to ensure that it preserve a
+stable source interface, a new interface would have been created, and
+the older, broken one would have had to be maintained over time, leading
+to extra work for the USB developers.  Since all Linux USB developers do
+their work on their own time, asking programmers to do extra work for no
+gain, for free, is not a possibility.
+
+Security issues are also a very important for Linux.  When a
+security issue is found, it is fixed in a very short amount of time.  A
+number of times this has caused internal kernel interfaces to be
+reworked to prevent the security problem from occurring.  When this
+happens, all drivers that use the interfaces were also fixed at the
+same time, ensuring that the security problem was fixed and could not
+come back at some future time accidentally.  If the internal interfaces
+were not allowed to change, fixing this kind of security problem and
+insuring that it could not happen again would not be possible.
+
+Kernel interfaces are cleaned up over time.  If there is no one using a
+current interface, it is deleted.  This ensures that the kernel remains
+as small as possible, and that all potential interfaces are tested as
+well as they can be (unused interfaces are pretty much impossible to
+test for validity.)
+
+
+What to do
+----------
+
+So, if you have a Linux kernel driver that is not in the main kernel
+tree, what are you, a developer, supposed to do?  Releasing a binary
+driver for every different kernel version for every distribution is a
+nightmare, and trying to keep up with an ever changing kernel interface
+is also a rough job.
+
+Simple, get your kernel driver into the main kernel tree (remember we
+are talking about GPL released drivers here, if your code doesn't fall
+under this category, good luck, you are on your own here, you leech
+<insert link to leech comment from Andrew and Linus here>.)  If your
+driver is in the tree, and a kernel interface changes, it will be fixed
+up by the person who did the kernel change in the first place.  This
+ensures that your driver is always buildable, and works over time, with
+very little effort on your part.
+
+The very good side affects of having your driver in the main kernel tree
+are:
+  - The quality of the driver will rise as the maintenance costs (to the
+    original developer) will decrease.
+  - Other developers will add features to your driver.
+  - Other people will find and fix bugs in your driver.
+  - Other people will find tuning opportunities in your driver.
+  - Other people will update the driver for you when external interface
+    changes require it.
+  - The driver automatically gets shipped in all Linux distributions
+    without having to ask the distros to add it.
+    
+As Linux supports a larger number of different devices "out of the box"
+than any other operating system, and it supports these devices on more
+different processor architectures than any other operating system, this
+proven type of development model must be doing something right :)
+
+
+
+------
+
+Thanks to Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder,
+Robert Love, and Nishanth Aravamudan for their review and comments on
+early drafts of this paper.
diff --git a/Documentation/usb/gadget_serial.txt b/Documentation/usb/gadget_serial.txt
new file mode 100644
index 00000000000000..a938c3dd13d657
--- /dev/null
+++ b/Documentation/usb/gadget_serial.txt
@@ -0,0 +1,332 @@
+
+                 Linux Gadget Serial Driver v2.0
+                           11/20/2004
+
+
+License and Disclaimer
+----------------------
+This program is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License as
+published by the Free Software Foundation; either version 2 of
+the License, or (at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public
+License along with this program; if not, write to the Free
+Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+MA 02111-1307 USA.
+
+This document and the the gadget serial driver itself are
+Copyright (C) 2004 by Al Borchers (alborchers@steinerpoint.com).
+
+If you have questions, problems, or suggestions for this driver
+please contact Al Borchers at alborchers@steinerpoint.com.
+
+
+Prerequisites
+-------------
+Versions of the gadget serial driver are available for the
+2.4 Linux kernels, but this document assumes you are using
+version 2.0 or later of the gadget serial driver in a 2.6
+Linux kernel.
+
+This document assumes that you are familiar with Linux and
+Windows and know how to configure and build Linux kernels, run
+standard utilities, use minicom and HyperTerminal, and work with
+USB and serial devices.  It also assumes you configure the Linux
+gadget and usb drivers as modules.
+
+
+Overview
+--------
+The gadget serial driver is a Linux USB gadget driver, a USB device
+side driver.  It runs on a Linux system that has USB device side
+hardware; for example, a PDA, an embedded Linux system, or a PC
+with a USB development card.
+
+The gadget serial driver talks over USB to either a CDC ACM driver
+or a generic USB serial driver running on a host PC.
+
+   Host
+   --------------------------------------
+  | Host-Side   CDC ACM       USB Host   |
+  | Operating |   or        | Controller |   USB
+  | System    | Generic USB | Driver     |--------
+  | (Linux or | Serial      | and        |        |
+  | Windows)    Driver        USB Stack  |        |
+   --------------------------------------         |
+                                                  |
+                                                  |
+                                                  |
+   Gadget                                         |
+   --------------------------------------         |
+  | Gadget                   USB Periph. |        |
+  | Device-Side |  Gadget  | Controller  |        |
+  | Linux       |  Serial  | Driver      |--------
+  | Operating   |  Driver  | and         |
+  | System                   USB Stack   |
+   --------------------------------------
+
+On the device-side Linux system, the gadget serial driver looks
+like a serial device.
+
+On the host-side system, the gadget serial device looks like a
+CDC ACM compliant class device or a simple vendor specific device
+with bulk in and bulk out endpoints, and it is treated similarly
+to other serial devices.
+
+The host side driver can potentially be any ACM compliant driver
+or any driver that can talk to a device with a simple bulk in/out
+interface.  Gadget serial has been tested with the Linux ACM driver,
+the Windows usbser.sys ACM driver, and the Linux USB generic serial
+driver.
+
+With the gadget serial driver and the host side ACM or generic
+serial driver running, you should be able to communicate between
+the host and the gadget side systems as if they were connected by a
+serial cable.
+
+The gadget serial driver only provides simple unreliable data
+communication.  It does not yet handle flow control or many other
+features of normal serial devices.
+
+
+Installing the Gadget Serial Driver
+-----------------------------------
+To use the gadget serial driver you must configure the Linux gadget
+side kernel for "Support for USB Gadgets", for a "USB Peripheral
+Controller" (for example, net2280), and for the "Serial Gadget"
+driver.  All this are listed under "USB Gadget Support" when
+configuring the kernel.  Then rebuild and install the kernel or
+modules.
+
+The gadget serial driver uses major number 127, for now.  So you
+will need to create a device node for it, like this:
+
+  mknod /dev/ttygserial c 127 0
+
+You only need to do this once.
+
+Then you must load the gadget serial driver.  To load it as an
+ACM device, do this:
+
+  modprobe g_serial use_acm=1
+
+To load it as a vendor specific bulk in/out device, do this:
+
+  modprobe g_serial
+
+This will also automatically load the underlying gadget peripheral
+controller driver.  This must be done each time you reboot the gadget
+side Linux system.  You can add this to the start up scripts, if
+desired.
+
+If gadget serial is loaded as an ACM device you will want to use
+either the Windows or Linux ACM driver on the host side.  If gadget
+serial is loaded as a bulk in/out device, you will want to use the
+Linux generic serial driver on the host side.  Follow the appropriate
+instructions below to install the host side driver.
+
+
+Installing the Windows Host ACM Driver
+--------------------------------------
+To use the Windows ACM driver you must have the files "gserial.inf"
+and "usbser.sys" together in a folder on the Windows machine.
+
+The "gserial.inf" file is given here.
+
+-------------------- CUT HERE --------------------
+[Version]
+Signature="$Windows NT$"
+Class=Ports
+ClassGuid={4D36E978-E325-11CE-BFC1-08002BE10318}
+Provider=%LINUX%
+DriverVer=08/17/2004,0.0.2.0
+; Copyright (C) 2004 Al Borchers (alborchers@steinerpoint.com)
+
+[Manufacturer]
+%LINUX%=GSerialDeviceList
+
+[GSerialDeviceList]
+%GSERIAL%=GSerialInstall, USB\VID_0525&PID_A4A7
+
+[DestinationDirs]
+DefaultDestDir=10,System32\Drivers
+
+[GSerialInstall]
+CopyFiles=GSerialCopyFiles
+AddReg=GSerialAddReg
+
+[GSerialCopyFiles]
+usbser.sys
+
+[GSerialAddReg]
+HKR,,DevLoader,,*ntkern
+HKR,,NTMPDriver,,usbser.sys
+HKR,,EnumPropPages32,,"MsPorts.dll,SerialPortPropPageProvider"
+
+[GSerialInstall.Services]
+AddService = usbser,0x0002,GSerialService
+
+[GSerialService]
+DisplayName = %GSERIAL_DISPLAY_NAME%
+ServiceType = 1                  ; SERVICE_KERNEL_DRIVER
+StartType = 3                    ; SERVICE_DEMAND_START
+ErrorControl = 1                 ; SERVICE_ERROR_NORMAL
+ServiceBinary = %10%\System32\Drivers\usbser.sys
+LoadOrderGroup = Base
+
+[Strings]
+LINUX = "Linux"
+GSERIAL = "Gadget Serial"
+GSERIAL_DISPLAY_NAME = "USB Gadget Serial Driver"
+-------------------- CUT HERE --------------------
+
+The "usbser.sys" file comes with various versions of Windows.
+For example, it can be found on Windows XP typically in
+
+  C:\WINDOWS\Driver Cache\i386\driver.cab
+
+Or it can be found on the Windows 98SE CD in the "win98" folder
+in the "DRIVER11.CAB" through "DRIVER20.CAB" cab files.  You will
+need the DOS "expand" program, the Cygwin "cabextract" program, or
+a similar program to unpack these cab files and extract "usbser.sys".
+
+For example, to extract "usbser.sys" into the current directory
+on Windows XP, open a DOS window and run a command like
+
+  expand C:\WINDOWS\Driver~1\i386\driver.cab -F:usbser.sys .
+
+(Thanks to Nishant Kamat for pointing out this DOS command.)
+
+When the gadget serial driver is loaded and the USB device connected
+to the Windows host with a USB cable, Windows should recognize the
+gadget serial device and ask for a driver.  Tell Windows to find the
+driver in the folder that contains "gserial.inf" and "usbser.sys".
+
+For example, on Windows XP, when the gadget serial device is first
+plugged in, the "Found New Hardware Wizard" starts up.  Select
+"Install from a list or specific location (Advanced)", then on
+the next screen select "Include this location in the search" and
+enter the path or browse to the folder containing "gserial.inf" and
+"usbser.sys".  Windows will complain that the Gadget Serial driver
+has not passed Windows Logo testing, but select "Continue anyway"
+and finish the driver installation.
+
+On Windows XP, in the "Device Manager" (under "Control Panel",
+"System", "Hardware") expand the "Ports (COM & LPT)" entry and you
+should see "Gadget Serial" listed as the driver for one of the COM
+ports.
+
+To uninstall the Windows XP driver for "Gadget Serial", right click
+on the "Gadget Serial" entry in the "Device Manager" and select
+"Uninstall".
+
+
+Installing the Linux Host ACM Driver
+------------------------------------
+To use the Linux ACM driver you must configure the Linux host side
+kernel for "Support for Host-side USB" and for "USB Modem (CDC ACM)
+support".
+
+Once the gadget serial driver is loaded and the USB device connected
+to the Linux host with a USB cable, the host system should recognize
+the gadget serial device.  For example, the command
+
+  cat /proc/bus/usb/devices
+
+should show something like this:
+
+T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  5 Spd=480 MxCh= 0
+D:  Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
+P:  Vendor=0525 ProdID=a4a7 Rev= 2.01
+S:  Manufacturer=Linux 2.6.8.1 with net2280
+S:  Product=Gadget Serial
+S:  SerialNumber=0
+C:* #Ifs= 2 Cfg#= 2 Atr=c0 MxPwr=  2mA
+I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm
+E:  Ad=83(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
+I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm
+E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+
+If the host side Linux system is configured properly, the ACM driver
+should be loaded automatically.  The command "lsmod" should show the
+"acm" module is loaded.
+
+
+Installing the Linux Host Generic USB Serial Driver
+---------------------------------------------------
+To use the Linux generic USB serial driver you must configure the
+Linux host side kernel for "Support for Host-side USB", for "USB
+Serial Converter support", and for the "USB Generic Serial Driver".
+
+Once the gadget serial driver is loaded and the USB device connected
+to the Linux host with a USB cable, the host system should recognize
+the gadget serial device.  For example, the command
+
+  cat /proc/bus/usb/devices
+
+should show something like this:
+
+T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  6 Spd=480 MxCh= 0
+D:  Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
+P:  Vendor=0525 ProdID=a4a6 Rev= 2.01
+S:  Manufacturer=Linux 2.6.8.1 with net2280
+S:  Product=Gadget Serial
+S:  SerialNumber=0
+C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  2mA
+I:  If#= 0 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=serial
+E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+
+You must explicitly load the usbserial driver with parameters to
+configure it to recognize the gadget serial device, like this:
+
+  modprobe usbserial vendor=0x0525 product=0xA4A6
+
+If everything is working, usbserial will print a message in the
+system log saying something like "Gadget Serial converter now
+attached to ttyUSB0".
+
+
+Testing with Minicom or HyperTerminal
+-------------------------------------
+Once the gadget serial driver and the host driver are both installed,
+and a USB cable connects the gadget device to the host, you should
+be able to communicate over USB between the gadget and host systems.
+You can use minicom or HyperTerminal to try this out.
+
+On the gadget side run "minicom -s" to configure a new minicom
+session.  Under "Serial port setup" set "/dev/ttygserial" as the
+"Serial Device".  Set baud rate, data bits, parity, and stop bits,
+to 9600, 8, none, and 1--these settings mostly do not matter.
+Under "Modem and dialing" erase all the modem and dialing strings.
+
+On a Linux host running the ACM driver, configure minicom similarly
+but use "/dev/ttyACM0" as the "Serial Device".  (If you have other
+ACM devices connected, change the device name appropriately.)
+
+On a Linux host running the USB generic serial driver, configure
+minicom similarly, but use "/dev/ttyUSB0" as the "Serial Device".
+(If you have other USB serial devices connected, change the device
+name appropriately.)
+
+On a Windows host configure a new HyperTerminal session to use the
+COM port assigned to Gadget Serial.  The "Port Settings" will be
+set automatically when HyperTerminal connects to the gadget serial
+device, so you can leave them set to the default values--these
+settings mostly do not matter.
+
+With minicom configured and running on the gadget side and with
+minicom or HyperTerminal configured and running on the host side,
+you should be able to send data back and forth between the gadget
+side and host side systems.  Anything you type on the terminal
+window on the gadget side should appear in the terminal window on
+the host side and vice versa.
+
+