11 files changed, 177 insertions, 92 deletions

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 299615d821ac..c3014df066c4 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -262,6 +262,8 @@ mtrr.txt
         - how to use PPro Memory Type Range Registers to increase performance.
 mutex-design.txt
         - info on the generic mutex subsystem.
+namespaces/
+        - directory with various information about namespaces
 nbd.txt
         - info on a TCP implementation of a network block device.
 netlabel/
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 054a7ecf64c6..4953bc258729 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
             procfs-guide.xml writing_usb_driver.xml \
             kernel-api.xml filesystems.xml lsm.xml usb.xml \
             gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
-            genericirq.xml s390-drivers.xml
+            genericirq.xml s390-drivers.xml uio-howto.xml
 
 ###
 # The build process is as follows (targets):
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl
index c119484258b8..fdd7f4f887b7 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -30,6 +30,12 @@
 
 <revhistory>
         <revision>
+        <revnumber>0.4</revnumber>
+        <date>2007-11-26</date>
+        <authorinitials>hjk</authorinitials>
+        <revremark>Removed section about uio_dummy.</revremark>
+        </revision>
+        <revision>
         <revnumber>0.3</revnumber>
         <date>2007-04-29</date>
         <authorinitials>hjk</authorinitials>
@@ -94,6 +100,26 @@ interested in translating it, please email me
         user space. This simplifies development and reduces the risk of
         serious bugs within a kernel module.
         </para>
+        <para>
+        Please note that UIO is not an universal driver interface. Devices
+        that are already handled well by other kernel subsystems (like
+        networking or serial or USB) are no candidates for an UIO driver.
+        Hardware that is ideally suited for an UIO driver fulfills all of
+        the following:
+        </para>
+<itemizedlist>
+<listitem>
+        <para>The device has memory that can be mapped. The device can be
+        controlled completely by writing to this memory.</para>
+</listitem>
+<listitem>
+        <para>The device usually generates interrupts.</para>
+</listitem>
+<listitem>
+        <para>The device does not fit into one of the standard kernel
+        subsystems.</para>
+</listitem>
+</itemizedlist>
 </sect1>
 
 <sect1 id="thanks">
@@ -174,8 +200,9 @@ interested in translating it, please email me
         For cards that don't generate interrupts but need to be
         polled, there is the possibility to set up a timer that
         triggers the interrupt handler at configurable time intervals.
-        See <filename>drivers/uio/uio_dummy.c</filename> for an
-        example of this technique.
+        This interrupt simulation is done by calling
+        <function>uio_event_notify()</function>
+        from the timer's event handler.
         </para>
 
         <para>
@@ -263,63 +290,11 @@ offset = N * getpagesize();
 </sect1>
 </chapter>
 
-<chapter id="using-uio_dummy" xreflabel="Using uio_dummy">
-<?dbhtml filename="using-uio_dummy.html"?>
-<title>Using uio_dummy</title>
-        <para>
-        Well, there is no real use for uio_dummy. Its only purpose is
-        to test most parts of the UIO system (everything except
-        hardware interrupts), and to serve as an example for the
-        kernel module that you will have to write yourself.
-        </para>
-
-<sect1 id="what_uio_dummy_does">
-<title>What uio_dummy does</title>
-        <para>
-        The kernel module <filename>uio_dummy.ko</filename> creates a
-        device that uses a timer to generate periodic interrupts. The
-        interrupt handler does nothing but increment a counter. The
-        driver adds two custom attributes, <varname>count</varname>
-        and <varname>freq</varname>, that appear under
-        <filename>/sys/devices/platform/uio_dummy/</filename>.
-        </para>
-
-        <para>
-        The attribute <varname>count</varname> can be read and
-        written.  The associated file
-        <filename>/sys/devices/platform/uio_dummy/count</filename>
-        appears as a normal text file and contains the total number of
-        timer interrupts. If you look at it (e.g. using
-        <function>cat</function>), you'll notice it is slowly counting
-        up.
-        </para>
-
-        <para>
-        The attribute <varname>freq</varname> can be read and written.
-        The content of
-        <filename>/sys/devices/platform/uio_dummy/freq</filename>
-        represents the number of system timer ticks between two timer
-        interrupts. The default value of <varname>freq</varname> is
-        the value of the kernel variable <varname>HZ</varname>, which
-        gives you an interval of one second. Lower values will
-        increase the frequency. Try the following:
-        </para>
-<programlisting format="linespecific">
-cd /sys/devices/platform/uio_dummy/
-echo 100 > freq
-</programlisting>
-        <para>
-        Use <function>cat count</function> to see how the interrupt
-        frequency changes.
-        </para>
-</sect1>
-</chapter>
-
 <chapter id="custom_kernel_module" xreflabel="Writing your own kernel module">
 <?dbhtml filename="custom_kernel_module.html"?>
 <title>Writing your own kernel module</title>
         <para>
-        Please have a look at <filename>uio_dummy.c</filename> as an
+        Please have a look at <filename>uio_cif.c</filename> as an
         example. The following paragraphs explain the different
         sections of this file.
         </para>
@@ -354,9 +329,8 @@ See the description below for details.
 interrupt, it's your modules task to determine the irq number during
 initialization. If you don't have a hardware generated interrupt but
 want to trigger the interrupt handler in some other way, set
-<varname>irq</varname> to <varname>UIO_IRQ_CUSTOM</varname>. The
-uio_dummy module does this as it triggers the event mechanism in a timer
-routine. If you had no interrupt at all, you could set
+<varname>irq</varname> to <varname>UIO_IRQ_CUSTOM</varname>.
+If you had no interrupt at all, you could set
 <varname>irq</varname> to <varname>UIO_IRQ_NONE</varname>, though this
 rarely makes sense.
 </para></listitem>
diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c
index 42008395534d..9b0e322118b5 100644
--- a/Documentation/lguest/lguest.c
+++ b/Documentation/lguest/lguest.c
@@ -1040,6 +1040,11 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
                 / getpagesize();
         p = get_pages(pages);
 
+        /* Initialize the virtqueue */
+        vq->next = NULL;
+        vq->last_avail_idx = 0;
+        vq->dev = dev;
+
         /* Initialize the configuration. */
         vq->config.num = num_descs;
         vq->config.irq = devices.next_irq++;
@@ -1057,9 +1062,6 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
         for (i = &dev->vq; *i; i = &(*i)->next);
         *i = vq;
 
-        /* Link virtqueue back to device. */
-        vq->dev = dev;
-
         /* Set the routine to call when the Guest does something to this
          * virtqueue. */
         vq->handle_output = handle_output;
@@ -1093,6 +1095,7 @@ static struct device *new_device(const char *name, u16 type, int fd,
         dev->desc = new_dev_desc(type);
         dev->handle_input = handle_input;
         dev->name = name;
+        dev->vq = NULL;
         return dev;
 }
 
diff --git a/Documentation/namespaces/compatibility-list.txt b/Documentation/namespaces/compatibility-list.txt
new file mode 100644
index 000000000000..defc5589bfcd
--- /dev/null
+++ b/Documentation/namespaces/compatibility-list.txt
@@ -0,0 +1,39 @@
+        Namespaces compatibility list
+
+This document contains the information about the problems user
+may have when creating tasks living in different namespaces.
+
+Here's the summary. This matrix shows the known problems, that
+occur when tasks share some namespace (the columns) while living
+in different other namespaces (the rows):
+
+        UTS     IPC     VFS     PID     User    Net
+UTS      X
+IPC              X       1
+VFS                      X
+PID              1       1       X
+User             2       2               X
+Net                                              X
+
+1. Both the IPC and the PID namespaces provide IDs to address
+   object inside the kernel. E.g. semaphore with IPCID or
+   process group with pid.
+
+   In both cases, tasks shouldn't try exposing this ID to some
+   other task living in a different namespace via a shared filesystem
+   or IPC shmem/message. The fact is that this ID is only valid
+   within the namespace it was obtained in and may refer to some
+   other object in another namespace.
+
+2. Intentionally, two equal user IDs in different user namespaces
+   should not be equal from the VFS point of view. In other
+   words, user 10 in one user namespace shouldn't have the same
+   access permissions to files, belonging to user 10 in another
+   namespace.
+
+   The same is true for the IPC namespaces being shared - two users
+   from different user namespaces should not access the same IPC objects
+   even having equal UIDs.
+
+   But currently this is not so.
+
diff --git a/Documentation/parport-lowlevel.txt b/Documentation/parport-lowlevel.txt
index 265fcdcb8e5f..120eb20dbb09 100644
--- a/Documentation/parport-lowlevel.txt
+++ b/Documentation/parport-lowlevel.txt
@@ -339,6 +339,10 @@ Use this function to register your device driver on a parallel port
 ('port').  Once you have done that, you will be able to use
 parport_claim and parport_release in order to use the port.
 
+The ('name') argument is the name of the device that appears in /proc
+filesystem. The string must be valid for the whole lifetime of the
+device (until parport_unregister_device is called).
+
 This function will register three callbacks into your driver:
 'preempt', 'wakeup' and 'irq'.  Each of these may be NULL in order to
 indicate that you do not want a callback.
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index ac1be25c1e25..e9a3cb1d6b06 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1645,8 +1645,9 @@ platforms are moved over to use the flattened-device-tree model.
      MAC addresses passed by the firmware when no information other
      than indices is available to associate an address with a device.
    - phy-connection-type : a string naming the controller/PHY interface type,
-     i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "tbi",
-     or "rtbi".
+     i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal
+     Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only),
+     "tbi", or "rtbi".
 
    Example:
         ucc@2000 {
diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index ec499265deca..10c041ca13c7 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -1,7 +1,7 @@
                      ThinkPad ACPI Extras Driver
 
-                            Version 0.16
-                          August 2nd, 2007
+                            Version 0.17
+                         October 04th, 2007
 
                Borislav Deianov <borislav@users.sf.net>
              Henrique de Moraes Holschuh <hmh@hmh.eng.br>
@@ -923,19 +923,34 @@ sysfs backlight device "thinkpad_screen"
 This feature allows software control of the LCD brightness on ThinkPad
 models which don't have a hardware brightness slider.
 
-It has some limitations: the LCD backlight cannot be actually turned on or off
-by this interface, and in many ThinkPad models, the "dim while on battery"
-functionality will be enabled by the BIOS when this interface is used, and
-cannot be controlled.
-
-The backlight control has eight levels, ranging from 0 to 7.  Some of the
-levels may not be distinct.
-
-There are two interfaces to the firmware for brightness control, EC and CMOS.
-To select which one should be used, use the brightness_mode module parameter:
-brightness_mode=1 selects EC mode, brightness_mode=2 selects CMOS mode,
-brightness_mode=3 selects both EC and CMOS.  The driver tries to autodetect
-which interface to use.
+It has some limitations: the LCD backlight cannot be actually turned on or
+off by this interface, and in many ThinkPad models, the "dim while on
+battery" functionality will be enabled by the BIOS when this interface is
+used, and cannot be controlled.
+
+On IBM (and some of the earlier Lenovo) ThinkPads, the backlight control
+has eight brightness levels, ranging from 0 to 7.  Some of the levels
+may not be distinct.  Later Lenovo models that implement the ACPI
+display backlight brightness control methods have 16 levels, ranging
+from 0 to 15.
+
+There are two interfaces to the firmware for direct brightness control,
+EC and CMOS.  To select which one should be used, use the
+brightness_mode module parameter: brightness_mode=1 selects EC mode,
+brightness_mode=2 selects CMOS mode, brightness_mode=3 selects both EC
+and CMOS.  The driver tries to autodetect which interface to use.
+
+When display backlight brightness controls are available through the
+standard ACPI interface, it is best to use it instead of this direct
+ThinkPad-specific interface.  The driver will disable its native
+backlight brightness control interface if it detects that the standard
+ACPI interface is available in the ThinkPad.
+
+The brightness_enable module parameter can be used to control whether
+the LCD brightness control feature will be enabled when available.
+brightness_enable=0 forces it to be disabled.  brightness_enable=1
+forces it to be enabled when available, even if the standard ACPI
+interface is also available.
 
 Procfs notes:
 
@@ -947,11 +962,11 @@ Procfs notes:
 
 Sysfs notes:
 
-The interface is implemented through the backlight sysfs class, which is poorly
-documented at this time.
+The interface is implemented through the backlight sysfs class, which is
+poorly documented at this time.
 
-Locate the thinkpad_screen device under /sys/class/backlight, and inside it
-there will be the following attributes:
+Locate the thinkpad_screen device under /sys/class/backlight, and inside
+it there will be the following attributes:
 
         max_brightness:
                 Reads the maximum brightness the hardware can be set to.
@@ -961,17 +976,19 @@ there will be the following attributes:
                 Reads what brightness the screen is set to at this instant.
 
         brightness:
-                Writes request the driver to change brightness to the given
-                value.  Reads will tell you what brightness the driver is trying
-                to set the display to when "power" is set to zero and the display
-                has not been dimmed by a kernel power management event.
+                Writes request the driver to change brightness to the
+                given value.  Reads will tell you what brightness the
+                driver is trying to set the display to when "power" is set
+                to zero and the display has not been dimmed by a kernel
+                power management event.
 
         power:
-                power management mode, where 0 is "display on", and 1 to 3 will
-                dim the display backlight to brightness level 0 because
-                thinkpad-acpi cannot really turn the backlight off.  Kernel
-                power management events can temporarily increase the current
-                power management level, i.e. they can dim the display.
+                power management mode, where 0 is "display on", and 1 to 3
+                will dim the display backlight to brightness level 0
+                because thinkpad-acpi cannot really turn the backlight
+                off.  Kernel power management events can temporarily
+                increase the current power management level, i.e. they can
+                dim the display.
 
 
 Volume control -- /proc/acpi/ibm/volume
diff --git a/Documentation/tty.txt b/Documentation/tty.txt
index 048a8762cfb5..8e65c4498c52 100644
--- a/Documentation/tty.txt
+++ b/Documentation/tty.txt
@@ -132,6 +132,14 @@ set_termios()		Notify the tty driver that the device's termios
                         tty->termios. Previous settings should be passed in
                         the "old" argument.
 
+                        The API is defined such that the driver should return
+                        the actual modes selected. This means that the
+                        driver function is responsible for modifying any
+                        bits in the request it cannot fulfill to indicate
+                        the actual modes being used. A device with no
+                        hardware capability for change (eg a USB dongle or
+                        virtual port) can provide NULL for this method.
+
 throttle()              Notify the tty driver that input buffers for the
                         line discipline are close to full, and it should
                         somehow signal that no more characters should be
diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt
index 97842deec471..b2fc4d4a9917 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -278,6 +278,14 @@ optional.  The methods' jobs are quite simple:
         (although the interfaces will be in the same altsettings as
         before the suspend).
 
+If the device is disconnected or powered down while it is suspended,
+the disconnect method will be called instead of the resume or
+reset_resume method.  This is also quite likely to happen when
+waking up from hibernation, as many systems do not maintain suspend
+current to the USB host controllers during hibernation.  (It's
+possible to work around the hibernation-forces-disconnect problem by
+using the USB Persist facility.)
+
 The reset_resume method is used by the USB Persist facility (see
 Documentation/usb/persist.txt) and it can also be used under certain
 circumstances when CONFIG_USB_PERSIST is not enabled.  Currently, if a
diff --git a/Documentation/x86_64/uefi.txt b/Documentation/x86_64/uefi.txt
new file mode 100644
index 000000000000..91a98edfb588
--- /dev/null
+++ b/Documentation/x86_64/uefi.txt
@@ -0,0 +1,29 @@
+General note on [U]EFI x86_64 support
+-------------------------------------
+
+The nomenclature EFI and UEFI are used interchangeably in this document.
+
+Although the tools below are _not_ needed for building the kernel,
+the needed bootloader support and associated tools for x86_64 platforms
+with EFI firmware and specifications are listed below.
+
+1. UEFI specification:  http://www.uefi.org
+
+2. Booting Linux kernel on UEFI x86_64 platform requires bootloader
+   support. Elilo with x86_64 support can be used.
+
+3. x86_64 platform with EFI/UEFI firmware.
+
+Mechanics:
+---------
+- Build the kernel with the following configuration.
+        CONFIG_FB_EFI=y
+        CONFIG_FRAMEBUFFER_CONSOLE=y
+- Create a VFAT partition on the disk
+- Copy the following to the VFAT partition:
+        elilo bootloader with x86_64 support, elilo configuration file,
+        kernel image built in first step and corresponding
+        initrd. Instructions on building elilo  and its dependencies
+        can be found in the elilo sourceforge project.
+- Boot to EFI shell and invoke elilo choosing the kernel image built
+  in first step.