9 files changed, 522 insertions, 627 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index ceddcff4082a..e638e15a8895 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -1,3 +1,46 @@
+What:           /sys/bus/pci/drivers/.../bind
+Date:           December 2003
+Contact:        linux-pci@vger.kernel.org
+Description:
+                Writing a device location to this file will cause
+                the driver to attempt to bind to the device found at
+                this location.  This is useful for overriding default
+                bindings.  The format for the location is: DDDD:BB:DD.F.
+                That is Domain:Bus:Device.Function and is the same as
+                found in /sys/bus/pci/devices/.  For example:
+                # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/bind
+                (Note: kernels before 2.6.28 may require echo -n).
+What:           /sys/bus/pci/drivers/.../unbind
+Date:           December 2003
+Contact:        linux-pci@vger.kernel.org
+Description:
+                Writing a device location to this file will cause the
+                driver to attempt to unbind from the device found at
+                this location.  This may be useful when overriding default
+                bindings.  The format for the location is: DDDD:BB:DD.F.
+                That is Domain:Bus:Device.Function and is the same as
+                found in /sys/bus/pci/devices/. For example:
+                # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind
+                (Note: kernels before 2.6.28 may require echo -n).
+What:           /sys/bus/pci/drivers/.../new_id
+Date:           December 2003
+Contact:        linux-pci@vger.kernel.org
+Description:
+                Writing a device ID to this file will attempt to
+                dynamically add a new device ID to a PCI device driver.
+                This may allow the driver to support more hardware than
+                was included in the driver's static device ID support
+                table at compile time.  The format for the device ID is:
+                VVVV DDDD SVVV SDDD CCCC MMMM PPPP.  That is Vendor ID,
+                Device ID, Subsystem Vendor ID, Subsystem Device ID,
+                Class, Class Mask, and Private Driver Data.  The Vendor ID
+                and Device ID fields are required, the rest are optional.
+                Upon successfully adding an ID, the driver will probe
+                for the device and attempt to bind to it.  For example:
+                # echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id
 What:           /sys/bus/pci/devices/.../vpd
 Date:           February 2008
 Contact:        Ben Hutchings <bhutchings@solarflare.com>
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index dc3154e49279..1462ed86d40a 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -6,7 +6,7 @@
 # To add a new book the only step required is to add the book to the
 # list of DOCBOOKS.
-DOCBOOKS := z8530book.xml mcabook.xml \
+DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \
            kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
            procfs-guide.xml writing_usb_driver.xml networking.xml \
            kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl
new file mode 100644
index 000000000000..94a20fe8fedf
--- /dev/null
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -0,0 +1,418 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+        "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
+<book id="LinuxDriversAPI">
+ <bookinfo>
+  <title>Linux Device Drivers</title>
+  <legalnotice>
+   <para>
+     This documentation 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.
+   </para>
+   <para>
+     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.
+   </para>
+   <para>
+     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
+   </para>
+   <para>
+     For more details see the file COPYING in the source
+     distribution of Linux.
+   </para>
+  </legalnotice>
+ </bookinfo>
+<toc></toc>
+  <chapter id="Basics">
+     <title>Driver Basics</title>
+     <sect1><title>Driver Entry and Exit points</title>
+!Iinclude/linux/init.h
+     </sect1>
+     <sect1><title>Atomic and pointer manipulation</title>
+!Iarch/x86/include/asm/atomic_32.h
+!Iarch/x86/include/asm/unaligned.h
+     </sect1>
+     <sect1><title>Delaying, scheduling, and timer routines</title>
+!Iinclude/linux/sched.h
+!Ekernel/sched.c
+!Ekernel/timer.c
+     </sect1>
+     <sect1><title>High-resolution timers</title>
+!Iinclude/linux/ktime.h
+!Iinclude/linux/hrtimer.h
+!Ekernel/hrtimer.c
+     </sect1>
+     <sect1><title>Workqueues and Kevents</title>
+!Ekernel/workqueue.c
+     </sect1>
+     <sect1><title>Internal Functions</title>
+!Ikernel/exit.c
+!Ikernel/signal.c
+!Iinclude/linux/kthread.h
+!Ekernel/kthread.c
+     </sect1>
+     <sect1><title>Kernel objects manipulation</title>
+<!--
+X!Iinclude/linux/kobject.h
+-->
+!Elib/kobject.c
+     </sect1>
+     <sect1><title>Kernel utility functions</title>
+!Iinclude/linux/kernel.h
+!Ekernel/printk.c
+!Ekernel/panic.c
+!Ekernel/sys.c
+!Ekernel/rcupdate.c
+     </sect1>
+     <sect1><title>Device Resource Management</title>
+!Edrivers/base/devres.c
+     </sect1>
+  </chapter>
+  <chapter id="devdrivers">
+     <title>Device drivers infrastructure</title>
+     <sect1><title>Device Drivers Base</title>
+<!--
+X!Iinclude/linux/device.h
+-->
+!Edrivers/base/driver.c
+!Edrivers/base/core.c
+!Edrivers/base/class.c
+!Edrivers/base/firmware_class.c
+!Edrivers/base/transport_class.c
+<!-- Cannot be included, because
+     attribute_container_add_class_device_adapter
+ and attribute_container_classdev_to_container
+     exceed allowed 44 characters maximum
+X!Edrivers/base/attribute_container.c
+-->
+!Edrivers/base/sys.c
+<!--
+X!Edrivers/base/interface.c
+-->
+!Edrivers/base/platform.c
+!Edrivers/base/bus.c
+     </sect1>
+     <sect1><title>Device Drivers Power Management</title>
+!Edrivers/base/power/main.c
+     </sect1>
+     <sect1><title>Device Drivers ACPI Support</title>
+<!-- Internal functions only
+X!Edrivers/acpi/sleep/main.c
+X!Edrivers/acpi/sleep/wakeup.c
+X!Edrivers/acpi/motherboard.c
+X!Edrivers/acpi/bus.c
+-->
+!Edrivers/acpi/scan.c
+!Idrivers/acpi/scan.c
+<!-- No correct structured comments
+X!Edrivers/acpi/pci_bind.c
+-->
+     </sect1>
+     <sect1><title>Device drivers PnP support</title>
+!Idrivers/pnp/core.c
+<!-- No correct structured comments
+X!Edrivers/pnp/system.c
+ -->
+!Edrivers/pnp/card.c
+!Idrivers/pnp/driver.c
+!Edrivers/pnp/manager.c
+!Edrivers/pnp/support.c
+     </sect1>
+     <sect1><title>Userspace IO devices</title>
+!Edrivers/uio/uio.c
+!Iinclude/linux/uio_driver.h
+     </sect1>
+  </chapter>
+  <chapter id="parportdev">
+     <title>Parallel Port Devices</title>
+!Iinclude/linux/parport.h
+!Edrivers/parport/ieee1284.c
+!Edrivers/parport/share.c
+!Idrivers/parport/daisy.c
+  </chapter>
+  <chapter id="message_devices">
+        <title>Message-based devices</title>
+     <sect1><title>Fusion message devices</title>
+!Edrivers/message/fusion/mptbase.c
+!Idrivers/message/fusion/mptbase.c
+!Edrivers/message/fusion/mptscsih.c
+!Idrivers/message/fusion/mptscsih.c
+!Idrivers/message/fusion/mptctl.c
+!Idrivers/message/fusion/mptspi.c
+!Idrivers/message/fusion/mptfc.c
+!Idrivers/message/fusion/mptlan.c
+     </sect1>
+     <sect1><title>I2O message devices</title>
+!Iinclude/linux/i2o.h
+!Idrivers/message/i2o/core.h
+!Edrivers/message/i2o/iop.c
+!Idrivers/message/i2o/iop.c
+!Idrivers/message/i2o/config-osm.c
+!Edrivers/message/i2o/exec-osm.c
+!Idrivers/message/i2o/exec-osm.c
+!Idrivers/message/i2o/bus-osm.c
+!Edrivers/message/i2o/device.c
+!Idrivers/message/i2o/device.c
+!Idrivers/message/i2o/driver.c
+!Idrivers/message/i2o/pci.c
+!Idrivers/message/i2o/i2o_block.c
+!Idrivers/message/i2o/i2o_scsi.c
+!Idrivers/message/i2o/i2o_proc.c
+     </sect1>
+  </chapter>
+  <chapter id="snddev">
+     <title>Sound Devices</title>
+!Iinclude/sound/core.h
+!Esound/sound_core.c
+!Iinclude/sound/pcm.h
+!Esound/core/pcm.c
+!Esound/core/device.c
+!Esound/core/info.c
+!Esound/core/rawmidi.c
+!Esound/core/sound.c
+!Esound/core/memory.c
+!Esound/core/pcm_memory.c
+!Esound/core/init.c
+!Esound/core/isadma.c
+!Esound/core/control.c
+!Esound/core/pcm_lib.c
+!Esound/core/hwdep.c
+!Esound/core/pcm_native.c
+!Esound/core/memalloc.c
+<!-- FIXME: Removed for now since no structured comments in source
+X!Isound/sound_firmware.c
+-->
+  </chapter>
+  <chapter id="uart16x50">
+     <title>16x50 UART Driver</title>
+!Iinclude/linux/serial_core.h
+!Edrivers/serial/serial_core.c
+!Edrivers/serial/8250.c
+  </chapter>
+  <chapter id="fbdev">
+     <title>Frame Buffer Library</title>
+     <para>
+       The frame buffer drivers depend heavily on four data structures.
+       These structures are declared in include/linux/fb.h.  They are
+       fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs.
+       The last three can be made available to and from userland.
+     </para>
+     <para>
+       fb_info defines the current state of a particular video card.
+       Inside fb_info, there exists a fb_ops structure which is a
+       collection of needed functions to make fbdev and fbcon work.
+       fb_info is only visible to the kernel.
+     </para>
+     <para>
+       fb_var_screeninfo is used to describe the features of a video card
+       that are user defined.  With fb_var_screeninfo, things such as
+       depth and the resolution may be defined.
+     </para>
+     <para>
+       The next structure is fb_fix_screeninfo. This defines the
+       properties of a card that are created when a mode is set and can't
+       be changed otherwise.  A good example of this is the start of the
+       frame buffer memory.  This "locks" the address of the frame buffer
+       memory, so that it cannot be changed or moved.
+     </para>
+     <para>
+       The last structure is fb_monospecs. In the old API, there was
+       little importance for fb_monospecs. This allowed for forbidden things
+       such as setting a mode of 800x600 on a fix frequency monitor. With
+       the new API, fb_monospecs prevents such things, and if used
+       correctly, can prevent a monitor from being cooked.  fb_monospecs
+       will not be useful until kernels 2.5.x.
+     </para>
+     <sect1><title>Frame Buffer Memory</title>
+!Edrivers/video/fbmem.c
+     </sect1>
+<!--
+     <sect1><title>Frame Buffer Console</title>
+X!Edrivers/video/console/fbcon.c
+     </sect1>
+-->
+     <sect1><title>Frame Buffer Colormap</title>
+!Edrivers/video/fbcmap.c
+     </sect1>
+<!-- FIXME:
+  drivers/video/fbgen.c has no docs, which stuffs up the sgml.  Comment
+  out until somebody adds docs.  KAO
+     <sect1><title>Frame Buffer Generic Functions</title>
+X!Idrivers/video/fbgen.c
+     </sect1>
+KAO -->
+     <sect1><title>Frame Buffer Video Mode Database</title>
+!Idrivers/video/modedb.c
+!Edrivers/video/modedb.c
+     </sect1>
+     <sect1><title>Frame Buffer Macintosh Video Mode Database</title>
+!Edrivers/video/macmodes.c
+     </sect1>
+     <sect1><title>Frame Buffer Fonts</title>
+        <para>
+           Refer to the file drivers/video/console/fonts.c for more information.
+        </para>
+<!-- FIXME: Removed for now since no structured comments in source
+X!Idrivers/video/console/fonts.c
+-->
+     </sect1>
+  </chapter>
+  <chapter id="input_subsystem">
+     <title>Input Subsystem</title>
+!Iinclude/linux/input.h
+!Edrivers/input/input.c
+!Edrivers/input/ff-core.c
+!Edrivers/input/ff-memless.c
+  </chapter>
+  <chapter id="spi">
+      <title>Serial Peripheral Interface (SPI)</title>
+  <para>
+        SPI is the "Serial Peripheral Interface", widely used with
+        embedded systems because it is a simple and efficient
+        interface:  basically a multiplexed shift register.
+        Its three signal wires hold a clock (SCK, often in the range
+        of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and
+        a "Master In, Slave Out" (MISO) data line.
+        SPI is a full duplex protocol; for each bit shifted out the
+        MOSI line (one per clock) another is shifted in on the MISO line.
+        Those bits are assembled into words of various sizes on the
+        way to and from system memory.
+        An additional chipselect line is usually active-low (nCS);
+        four signals are normally used for each peripheral, plus
+        sometimes an interrupt.
+  </para>
+  <para>
+        The SPI bus facilities listed here provide a generalized
+        interface to declare SPI busses and devices, manage them
+        according to the standard Linux driver model, and perform
+        input/output operations.
+        At this time, only "master" side interfaces are supported,
+        where Linux talks to SPI peripherals and does not implement
+        such a peripheral itself.
+        (Interfaces to support implementing SPI slaves would
+        necessarily look different.)
+  </para>
+  <para>
+        The programming interface is structured around two kinds of driver,
+        and two kinds of device.
+        A "Controller Driver" abstracts the controller hardware, which may
+        be as simple as a set of GPIO pins or as complex as a pair of FIFOs
+        connected to dual DMA engines on the other side of the SPI shift
+        register (maximizing throughput).  Such drivers bridge between
+        whatever bus they sit on (often the platform bus) and SPI, and
+        expose the SPI side of their device as a
+        <structname>struct spi_master</structname>.
+        SPI devices are children of that master, represented as a
+        <structname>struct spi_device</structname> and manufactured from
+        <structname>struct spi_board_info</structname> descriptors which
+        are usually provided by board-specific initialization code.
+        A <structname>struct spi_driver</structname> is called a
+        "Protocol Driver", and is bound to a spi_device using normal
+        driver model calls.
+  </para>
+  <para>
+        The I/O model is a set of queued messages.  Protocol drivers
+        submit one or more <structname>struct spi_message</structname>
+        objects, which are processed and completed asynchronously.
+        (There are synchronous wrappers, however.)  Messages are
+        built from one or more <structname>struct spi_transfer</structname>
+        objects, each of which wraps a full duplex SPI transfer.
+        A variety of protocol tweaking options are needed, because
+        different chips adopt very different policies for how they
+        use the bits transferred with SPI.
+  </para>
+!Iinclude/linux/spi/spi.h
+!Fdrivers/spi/spi.c spi_register_board_info
+!Edrivers/spi/spi.c
+  </chapter>
+  <chapter id="i2c">
+     <title>I<superscript>2</superscript>C and SMBus Subsystem</title>
+     <para>
+        I<superscript>2</superscript>C (or without fancy typography, "I2C")
+        is an acronym for the "Inter-IC" bus, a simple bus protocol which is
+        widely used where low data rate communications suffice.
+        Since it's also a licensed trademark, some vendors use another
+        name (such as "Two-Wire Interface", TWI) for the same bus.
+        I2C only needs two signals (SCL for clock, SDA for data), conserving
+        board real estate and minimizing signal quality issues.
+        Most I2C devices use seven bit addresses, and bus speeds of up
+        to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet
+        found wide use.
+        I2C is a multi-master bus; open drain signaling is used to
+        arbitrate between masters, as well as to handshake and to
+        synchronize clocks from slower clients.
+     </para>
+     <para>
+        The Linux I2C programming interfaces support only the master
+        side of bus interactions, not the slave side.
+        The programming interface is structured around two kinds of driver,
+        and two kinds of device.
+        An I2C "Adapter Driver" abstracts the controller hardware; it binds
+        to a physical device (perhaps a PCI device or platform_device) and
+        exposes a <structname>struct i2c_adapter</structname> representing
+        each I2C bus segment it manages.
+        On each I2C bus segment will be I2C devices represented by a
+        <structname>struct i2c_client</structname>.  Those devices will
+        be bound to a <structname>struct i2c_driver</structname>,
+        which should follow the standard Linux driver model.
+        (At this writing, a legacy model is more widely used.)
+        There are functions to perform various I2C protocol operations; at
+        this writing all such functions are usable only from task context.
+     </para>
+     <para>
+        The System Management Bus (SMBus) is a sibling protocol.  Most SMBus
+        systems are also I2C conformant.  The electrical constraints are
+        tighter for SMBus, and it standardizes particular protocol messages
+        and idioms.  Controllers that support I2C can also support most
+        SMBus operations, but SMBus controllers don't support all the protocol
+        options that an I2C controller will.
+        There are functions to perform various SMBus protocol operations,
+        either using I2C primitives or by issuing SMBus commands to
+        i2c_adapter devices which don't support those I2C operations.
+     </para>
+!Iinclude/linux/i2c.h
+!Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info
+!Edrivers/i2c/i2c-core.c
+  </chapter>
+</book>
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index 5818ff75786a..bc962cda6504 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -38,58 +38,6 @@
 <toc></toc>
-  <chapter id="Basics">
-     <title>Driver Basics</title>
-     <sect1><title>Driver Entry and Exit points</title>
-!Iinclude/linux/init.h
-     </sect1>
-     <sect1><title>Atomic and pointer manipulation</title>
-!Iarch/x86/include/asm/atomic_32.h
-!Iarch/x86/include/asm/unaligned.h
-     </sect1>
-     <sect1><title>Delaying, scheduling, and timer routines</title>
-!Iinclude/linux/sched.h
-!Ekernel/sched.c
-!Ekernel/timer.c
-     </sect1>
-     <sect1><title>High-resolution timers</title>
-!Iinclude/linux/ktime.h
-!Iinclude/linux/hrtimer.h
-!Ekernel/hrtimer.c
-     </sect1>
-     <sect1><title>Workqueues and Kevents</title>
-!Ekernel/workqueue.c
-     </sect1>
-     <sect1><title>Internal Functions</title>
-!Ikernel/exit.c
-!Ikernel/signal.c
-!Iinclude/linux/kthread.h
-!Ekernel/kthread.c
-     </sect1>
-     <sect1><title>Kernel objects manipulation</title>
-<!--
-X!Iinclude/linux/kobject.h
-->
-!Elib/kobject.c
-     </sect1>
-     <sect1><title>Kernel utility functions</title>
-!Iinclude/linux/kernel.h
-!Ekernel/printk.c
-!Ekernel/panic.c
-!Ekernel/sys.c
-!Ekernel/rcupdate.c
-     </sect1>
-     <sect1><title>Device Resource Management</title>
-!Edrivers/base/devres.c
-     </sect1>
-  </chapter>
  <chapter id="adt">
     <title>Data Types</title>
     <sect1><title>Doubly Linked Lists</title>
@@ -298,62 +246,6 @@ X!Earch/x86/kernel/mca_32.c
 !Ikernel/acct.c
  </chapter>
-  <chapter id="devdrivers">
-     <title>Device drivers infrastructure</title>
-     <sect1><title>Device Drivers Base</title>
-<!--
-X!Iinclude/linux/device.h
-->
-!Edrivers/base/driver.c
-!Edrivers/base/core.c
-!Edrivers/base/class.c
-!Edrivers/base/firmware_class.c
-!Edrivers/base/transport_class.c
-<!-- Cannot be included, because
-     attribute_container_add_class_device_adapter
- and attribute_container_classdev_to_container
-     exceed allowed 44 characters maximum
-X!Edrivers/base/attribute_container.c
-->
-!Edrivers/base/sys.c
-<!--
-X!Edrivers/base/interface.c
-->
-!Edrivers/base/platform.c
-!Edrivers/base/bus.c
-     </sect1>
-     <sect1><title>Device Drivers Power Management</title>
-!Edrivers/base/power/main.c
-     </sect1>
-     <sect1><title>Device Drivers ACPI Support</title>
-<!-- Internal functions only
-X!Edrivers/acpi/sleep/main.c
-X!Edrivers/acpi/sleep/wakeup.c
-X!Edrivers/acpi/motherboard.c
-X!Edrivers/acpi/bus.c
-->
-!Edrivers/acpi/scan.c
-!Idrivers/acpi/scan.c
-<!-- No correct structured comments
-X!Edrivers/acpi/pci_bind.c
-->
-     </sect1>
-     <sect1><title>Device drivers PnP support</title>
-!Idrivers/pnp/core.c
-<!-- No correct structured comments
-X!Edrivers/pnp/system.c
- -->
-!Edrivers/pnp/card.c
-!Idrivers/pnp/driver.c
-!Edrivers/pnp/manager.c
-!Edrivers/pnp/support.c
-     </sect1>
-     <sect1><title>Userspace IO devices</title>
-!Edrivers/uio/uio.c
-!Iinclude/linux/uio_driver.h
-     </sect1>
-  </chapter>
  <chapter id="blkdev">
     <title>Block Devices</title>
 !Eblock/blk-core.c
@@ -381,275 +273,6 @@ X!Edrivers/pnp/system.c
 !Edrivers/char/misc.c
  </chapter>
-  <chapter id="parportdev">
-     <title>Parallel Port Devices</title>
-!Iinclude/linux/parport.h
-!Edrivers/parport/ieee1284.c
-!Edrivers/parport/share.c
-!Idrivers/parport/daisy.c
-  </chapter>
-  <chapter id="message_devices">
-        <title>Message-based devices</title>
-     <sect1><title>Fusion message devices</title>
-!Edrivers/message/fusion/mptbase.c
-!Idrivers/message/fusion/mptbase.c
-!Edrivers/message/fusion/mptscsih.c
-!Idrivers/message/fusion/mptscsih.c
-!Idrivers/message/fusion/mptctl.c
-!Idrivers/message/fusion/mptspi.c
-!Idrivers/message/fusion/mptfc.c
-!Idrivers/message/fusion/mptlan.c
-     </sect1>
-     <sect1><title>I2O message devices</title>
-!Iinclude/linux/i2o.h
-!Idrivers/message/i2o/core.h
-!Edrivers/message/i2o/iop.c
-!Idrivers/message/i2o/iop.c
-!Idrivers/message/i2o/config-osm.c
-!Edrivers/message/i2o/exec-osm.c
-!Idrivers/message/i2o/exec-osm.c
-!Idrivers/message/i2o/bus-osm.c
-!Edrivers/message/i2o/device.c
-!Idrivers/message/i2o/device.c
-!Idrivers/message/i2o/driver.c
-!Idrivers/message/i2o/pci.c
-!Idrivers/message/i2o/i2o_block.c
-!Idrivers/message/i2o/i2o_scsi.c
-!Idrivers/message/i2o/i2o_proc.c
-     </sect1>
-  </chapter>
-  <chapter id="snddev">
-     <title>Sound Devices</title>
-!Iinclude/sound/core.h
-!Esound/sound_core.c
-!Iinclude/sound/pcm.h
-!Esound/core/pcm.c
-!Esound/core/device.c
-!Esound/core/info.c
-!Esound/core/rawmidi.c
-!Esound/core/sound.c
-!Esound/core/memory.c
-!Esound/core/pcm_memory.c
-!Esound/core/init.c
-!Esound/core/isadma.c
-!Esound/core/control.c
-!Esound/core/pcm_lib.c
-!Esound/core/hwdep.c
-!Esound/core/pcm_native.c
-!Esound/core/memalloc.c
-<!-- FIXME: Removed for now since no structured comments in source
-X!Isound/sound_firmware.c
-->
-  </chapter>
-  <chapter id="uart16x50">
-     <title>16x50 UART Driver</title>
-!Iinclude/linux/serial_core.h
-!Edrivers/serial/serial_core.c
-!Edrivers/serial/8250.c
-  </chapter>
-  <chapter id="fbdev">
-     <title>Frame Buffer Library</title>
-     <para>
-       The frame buffer drivers depend heavily on four data structures.  
-       These structures are declared in include/linux/fb.h.  They are 
-       fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs. 
-       The last three can be made available to and from userland. 
-     </para>
-     <para>
-       fb_info defines the current state of a particular video card. 
-       Inside fb_info, there exists a fb_ops structure which is a 
-       collection of needed functions to make fbdev and fbcon work.
-       fb_info is only visible to the kernel.
-     </para>
-     <para>
-       fb_var_screeninfo is used to describe the features of a video card 
-       that are user defined.  With fb_var_screeninfo, things such as
-       depth and the resolution may be defined.
-     </para>
-     <para>
-       The next structure is fb_fix_screeninfo. This defines the 
-       properties of a card that are created when a mode is set and can't 
-       be changed otherwise.  A good example of this is the start of the 
-       frame buffer memory.  This "locks" the address of the frame buffer
-       memory, so that it cannot be changed or moved.
-     </para>
-     <para>
-       The last structure is fb_monospecs. In the old API, there was 
-       little importance for fb_monospecs. This allowed for forbidden things 
-       such as setting a mode of 800x600 on a fix frequency monitor. With 
-       the new API, fb_monospecs prevents such things, and if used 
-       correctly, can prevent a monitor from being cooked.  fb_monospecs
-       will not be useful until kernels 2.5.x.
-     </para>
-     <sect1><title>Frame Buffer Memory</title>
-!Edrivers/video/fbmem.c
-     </sect1>
-<!--
-     <sect1><title>Frame Buffer Console</title>
-X!Edrivers/video/console/fbcon.c
-     </sect1>
-->
-     <sect1><title>Frame Buffer Colormap</title>
-!Edrivers/video/fbcmap.c
-     </sect1>
-<!-- FIXME:
-  drivers/video/fbgen.c has no docs, which stuffs up the sgml.  Comment
-  out until somebody adds docs.  KAO
-     <sect1><title>Frame Buffer Generic Functions</title>
-X!Idrivers/video/fbgen.c
-     </sect1>
-KAO -->
-     <sect1><title>Frame Buffer Video Mode Database</title>
-!Idrivers/video/modedb.c
-!Edrivers/video/modedb.c
-     </sect1>
-     <sect1><title>Frame Buffer Macintosh Video Mode Database</title>
-!Edrivers/video/macmodes.c
-     </sect1>
-     <sect1><title>Frame Buffer Fonts</title>
-        <para>
-           Refer to the file drivers/video/console/fonts.c for more information.
-        </para>
-<!-- FIXME: Removed for now since no structured comments in source
-X!Idrivers/video/console/fonts.c
-->
-     </sect1>
-  </chapter>
-  <chapter id="input_subsystem">
-     <title>Input Subsystem</title>
-!Iinclude/linux/input.h
-!Edrivers/input/input.c
-!Edrivers/input/ff-core.c
-!Edrivers/input/ff-memless.c
-  </chapter>
-  <chapter id="spi">
-      <title>Serial Peripheral Interface (SPI)</title>
-  <para>
-        SPI is the "Serial Peripheral Interface", widely used with
-        embedded systems because it is a simple and efficient
-        interface:  basically a multiplexed shift register.
-        Its three signal wires hold a clock (SCK, often in the range
-        of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and
-        a "Master In, Slave Out" (MISO) data line.
-        SPI is a full duplex protocol; for each bit shifted out the
-        MOSI line (one per clock) another is shifted in on the MISO line.
-        Those bits are assembled into words of various sizes on the
-        way to and from system memory.
-        An additional chipselect line is usually active-low (nCS);
-        four signals are normally used for each peripheral, plus
-        sometimes an interrupt.
-  </para>
-  <para>
-        The SPI bus facilities listed here provide a generalized
-        interface to declare SPI busses and devices, manage them
-        according to the standard Linux driver model, and perform
-        input/output operations.
-        At this time, only "master" side interfaces are supported,
-        where Linux talks to SPI peripherals and does not implement
-        such a peripheral itself.
-        (Interfaces to support implementing SPI slaves would
-        necessarily look different.)
-  </para>
-  <para>
-        The programming interface is structured around two kinds of driver,
-        and two kinds of device.
-        A "Controller Driver" abstracts the controller hardware, which may
-        be as simple as a set of GPIO pins or as complex as a pair of FIFOs
-        connected to dual DMA engines on the other side of the SPI shift
-        register (maximizing throughput).  Such drivers bridge between
-        whatever bus they sit on (often the platform bus) and SPI, and
-        expose the SPI side of their device as a
-        <structname>struct spi_master</structname>.
-        SPI devices are children of that master, represented as a
-        <structname>struct spi_device</structname> and manufactured from
-        <structname>struct spi_board_info</structname> descriptors which
-        are usually provided by board-specific initialization code.
-        A <structname>struct spi_driver</structname> is called a
-        "Protocol Driver", and is bound to a spi_device using normal
-        driver model calls.
-  </para>
-  <para>
-        The I/O model is a set of queued messages.  Protocol drivers
-        submit one or more <structname>struct spi_message</structname>
-        objects, which are processed and completed asynchronously.
-        (There are synchronous wrappers, however.)  Messages are
-        built from one or more <structname>struct spi_transfer</structname>
-        objects, each of which wraps a full duplex SPI transfer.
-        A variety of protocol tweaking options are needed, because
-        different chips adopt very different policies for how they
-        use the bits transferred with SPI.
-  </para>
-!Iinclude/linux/spi/spi.h
-!Fdrivers/spi/spi.c spi_register_board_info
-!Edrivers/spi/spi.c
-  </chapter>
-  <chapter id="i2c">
-     <title>I<superscript>2</superscript>C and SMBus Subsystem</title>
-     <para>
-        I<superscript>2</superscript>C (or without fancy typography, "I2C")
-        is an acronym for the "Inter-IC" bus, a simple bus protocol which is
-        widely used where low data rate communications suffice.
-        Since it's also a licensed trademark, some vendors use another
-        name (such as "Two-Wire Interface", TWI) for the same bus.
-        I2C only needs two signals (SCL for clock, SDA for data), conserving
-        board real estate and minimizing signal quality issues.
-        Most I2C devices use seven bit addresses, and bus speeds of up
-        to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet
-        found wide use.
-        I2C is a multi-master bus; open drain signaling is used to
-        arbitrate between masters, as well as to handshake and to
-        synchronize clocks from slower clients.
-     </para>
-     <para>
-        The Linux I2C programming interfaces support only the master
-        side of bus interactions, not the slave side.
-        The programming interface is structured around two kinds of driver,
-        and two kinds of device.
-        An I2C "Adapter Driver" abstracts the controller hardware; it binds
-        to a physical device (perhaps a PCI device or platform_device) and
-        exposes a <structname>struct i2c_adapter</structname> representing
-        each I2C bus segment it manages.
-        On each I2C bus segment will be I2C devices represented by a
-        <structname>struct i2c_client</structname>.  Those devices will
-        be bound to a <structname>struct i2c_driver</structname>,
-        which should follow the standard Linux driver model.
-        (At this writing, a legacy model is more widely used.)
-        There are functions to perform various I2C protocol operations; at
-        this writing all such functions are usable only from task context.
-     </para>
-     <para>
-        The System Management Bus (SMBus) is a sibling protocol.  Most SMBus
-        systems are also I2C conformant.  The electrical constraints are
-        tighter for SMBus, and it standardizes particular protocol messages
-        and idioms.  Controllers that support I2C can also support most
-        SMBus operations, but SMBus controllers don't support all the protocol
-        options that an I2C controller will.
-        There are functions to perform various SMBus protocol operations,
-        either using I2C primitives or by issuing SMBus commands to
-        i2c_adapter devices which don't support those I2C operations.
-     </para>
-!Iinclude/linux/i2c.h
-!Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info
-!Edrivers/i2c/i2c-core.c
-  </chapter>
  <chapter id="clk">
     <title>Clock Framework</title>
diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt
index a05ec50f8004..a7cbfff40d07 100644
--- a/Documentation/driver-model/device.txt
+++ b/Documentation/driver-model/device.txt
@@ -127,9 +127,11 @@ void unlock_device(struct device * dev);
 Attributes
 ~~~~~~~~~~
 struct device_attribute {
-        struct attribute        attr;
+        struct attribute        attr;
-        ssize_t (*show)(struct device * dev, char * buf, size_t count, loff_t off);
+        ssize_t (*show)(struct device *dev, struct device_attribute *attr,
-        ssize_t (*store)(struct device * dev, const char * buf, size_t count, loff_t off);
+                        char *buf);
+        ssize_t (*store)(struct device *dev, struct device_attribute *attr,
+                         const char *buf, size_t count);
 };
 Attributes of devices can be exported via drivers using a simple
diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop
deleted file mode 100644
index 5515469de7cf..000000000000
--- a/Documentation/dvb/README.flexcop
+++ /dev/null
@@ -1,205 +0,0 @@
-This README escorted the skystar2-driver rewriting procedure. It describes the
-state of the new flexcop-driver set and some internals are written down here
-too.
-This document hopefully describes things about the flexcop and its
-device-offsprings. Goal was to write an easy-to-write and easy-to-read set of
-drivers based on the skystar2.c and other information.
-Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been
-touched and rewritten.
-History & News
-==============
-  2005-04-01 - correct USB ISOC transfers (thanks to Vadim Catana)
-General coding processing
-=========================
-We should proceed as follows (as long as no one complains):
-0) Think before start writing code!
-1) rewriting the skystar2.c with the help of the flexcop register descriptions
-and splitting up the files to a pci-bus-part and a flexcop-part.
-The new driver will be called b2c2-flexcop-pci.ko/b2c2-flexcop-usb.ko for the
-device-specific part and b2c2-flexcop.ko for the common flexcop-functions.
-2) Search for errors in the leftover of flexcop-pci.c (compare with pluto2.c
-and other pci drivers)
-3) make some beautification (see 'Improvements when rewriting (refactoring) is
-done')
-4) Testing the new driver and maybe substitute the skystar2.c with it, to reach
-a wider tester audience.
-5) creating an usb-bus-part using the already written flexcop code for the pci
-card.
-Idea: create a kernel-object for the flexcop and export all important
-functions. This option saves kernel-memory, but maybe a lot of functions have
-to be exported to kernel namespace.
-Current situation
-=================
-0) Done :)
-1) Done (some minor issues left)
-2) Done
-3) Not ready yet, more information is necessary
-4) next to be done (see the table below)
-5) USB driver is working (yes, there are some minor issues)
-What seems to be ready?
-----------------------
-1) Rewriting
-1a) i2c is cut off from the flexcop-pci.c and seems to work
-1b) moved tuner and demod stuff from flexcop-pci.c to flexcop-tuner-fe.c
-1c) moved lnb and diseqc stuff from flexcop-pci.c to flexcop-tuner-fe.c
-1e) eeprom (reading MAC address)
-1d) sram (no dynamic sll size detection (commented out) (using default as JJ told me))
-1f) misc. register accesses for reading parameters (e.g. resetting, revision)
-1g) pid/mac filter (flexcop-hw-filter.c)
-1i) dvb-stuff initialization in flexcop.c (done)
-1h) dma stuff (now just using the size-irq, instead of all-together, to be done)
-1j) remove flexcop initialization from flexcop-pci.c completely (done)
-1l) use a well working dma IRQ method (done, see 'Known bugs and problems and TODO')
-1k) cleanup flexcop-files (remove unused EXPORT_SYMBOLs, make static from
-non-static where possible, moved code to proper places)
-2) Search for errors in the leftover of flexcop-pci.c (partially done)
-5a) add MAC address reading
-5c) feeding of ISOC data to the software demux (format of the isochronous data
-and speed optimization, no real error) (thanks to Vadim Catana)
-What to do in the near future?
--------------------------------------
-(no special order here)
-5) USB driver
-5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting)
-Testing changes
---------------
-O             = item is working
-P             = item is partially working
-X             = item is not working
-N             = item does not apply here
-<empty field> = item need to be examined
-       | PCI                               | USB
-item   | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312
-------+-------+---------+---------+-------+-------+---------+---------+-------
-1a)    | O     |         |         |       | N     | N       | N       | N
-1b)    | O     |         |         |       |       |         | O       |
-1c)    | N     | N       |         |       | N     | N       | O       |
-1d)    |                 O                 |                 O
-1e)    |                 O                 |                 O
-1f)    |                                   P
-1g)    |                                   O
-1h)    |                 P                 |
-1i)    |                 O                 |                 N
-1j)    |                 O                 |                 N
-1l)    |                 O                 |                 N
-2)     |                 O                 |                 N
-5a)    |                 N                 |                 O
-5b)*   |                 N                 |
-5c)    |                 N                 |                 O
-* - not done yet
-Known bugs and problems and TODO
--------------------------------
-1g/h/l) when pid filtering is enabled on the pci card
-DMA usage currently:
-  The DMA is splitted in 2 equal-sized subbuffers. The Flexcop writes to first
-  address and triggers an IRQ when it's full and starts writing to the second
-  address. When the second address is full, the IRQ is triggered again, and
-  the flexcop writes to first address again, and so on.
-  The buffersize of each address is currently 640*188 bytes.
-  Problem is, when using hw-pid-filtering and doing some low-bandwidth
-  operation (like scanning) the buffers won't be filled enough to trigger
-  the IRQ. That's why:
-  When PID filtering is activated, the timer IRQ is used. Every 1.97 ms the IRQ
-  is triggered.  Is the current write address of DMA1 different to the one
-  during the last IRQ, then the data is passed to the demuxer.
-  There is an additional DMA-IRQ-method: packet count IRQ. This isn't
-  implemented correctly yet.
-  The solution is to disable HW PID filtering, but I don't know how the DVB
-  API software demux behaves on slow systems with 45MBit/s TS.
-Solved bugs :)
--------------
-1g) pid-filtering (somehow pid index 4 and 5 (EMM_PID and ECM_PID) aren't
-working)
-SOLUTION: also index 0 was affected, because net_translation is done for
-these indexes by default
-5b) isochronous transfer does only work in the first attempt (for the Sky2PC
-USB, Air2PC is working) SOLUTION: the flexcop was going asleep and never really
-woke up again (don't know if this need fixes, see
-flexcop-fe-tuner.c:flexcop_sleep)
-NEWS: when the driver is loaded and unloaded and loaded again (w/o doing
-anything in the while the driver is loaded the first time), no transfers take
-place anymore.
-Improvements when rewriting (refactoring) is done
-=================================================
- split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control
-  (enable sleeping for other demods than dvb-s)
- add support for CableStar (stv0297 Microtune 203x/ALPS) (almost done, incompatibilities with the Nexus-CA)
-Debugging
---------
- add verbose debugging to skystar2.c (dump the reg_dw_data) and compare it
-  with this flexcop, this is important, because i2c is now using the
-  flexcop_ibi_value union from flexcop-reg.h (do you have a better idea for
-  that, please tell us so).
-Everything which is identical in the following table, can be put into a common
-flexcop-module.
-                  PCI                  USB
-------------------------------------------------------------------------------
-Different:
-Register access:  accessing IO memory  USB control message
-I2C bus:          I2C bus of the FC    USB control message
-Data transfer:    DMA                  isochronous transfer
-EEPROM transfer:  through i2c bus      not clear yet
-Identical:
-Streaming:                 accessing registers
-PID Filtering:             accessing registers
-Sram destinations:         accessing registers
-Tuner/Demod:                     I2C bus
-DVB-stuff:            can be written for common use
-Acknowledgements (just for the rewriting part)
-================
-Bjarne Steinsbo thought a lot in the first place of the pci part for this code
-sharing idea.
-Andreas Oberritter for providing a recent PCI initialization template
-(pluto2.c).
-Boleslaw Ciesielski for pointing out a problem with firmware loader.
-Vadim Catana for correcting the USB transfer.
-comments, critics and ideas to linux-dvb@linuxtv.org.
diff --git a/Documentation/dvb/technisat.txt b/Documentation/dvb/technisat.txt
index cdf6ee4b2da1..3f435ffb289c 100644
--- a/Documentation/dvb/technisat.txt
+++ b/Documentation/dvb/technisat.txt
@@ -1,5 +1,5 @@
-How to set up the Technisat devices
+How to set up the Technisat/B2C2 Flexcop devices
-===================================
+================================================
 1) Find out what device you have
 ================================
@@ -16,54 +16,60 @@ DVB: registering frontend 0 (Conexant CX24123/CX24109)...
 If the Technisat is the only TV device in your box get rid of unnecessary modules and check this one:
 "Multimedia devices" => "Customise analog and hybrid tuner modules to build"
-In this directory uncheck every driver which is activated there.
+In this directory uncheck every driver which is activated there (except "Simple tuner support" for case 9 only).
 Then please activate:
 2a) Main module part:
 a.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters"
-b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card OR
+b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card
+OR
 c.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC USB" in case of an USB 1.1 adapter
 d.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Enable debug for the B2C2 FlexCop drivers"
 Notice: d.) is helpful for troubleshooting
 2b) Frontend module part:
-1.) Revision 2.3:
+1.) SkyStar DVB-S Revision 2.3:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink VP310/MT312/ZL10313 based"
-2.) Revision 2.6:
+2.) SkyStar DVB-S Revision 2.6:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0299 based"
-3.) Revision 2.7:
+3.) SkyStar DVB-S Revision 2.7:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "Samsung S5H1420 based"
 c.)"Multimedia devices" => "Customise DVB frontends" => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS"
 d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller"
-4.) Revision 2.8:
+4.) SkyStar DVB-S Revision 2.8:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24113/CX24128 tuner for DVB-S/DSS"
 c.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24123 based"
 d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller"
-5.) DVB-T card:
+5.) AirStar DVB-T card:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink MT352 based"
-6.) DVB-C card:
+6.) CableStar DVB-C card:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0297 based"
-7.) ATSC card 1st generation:
+7.) AirStar ATSC card 1st generation:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "Broadcom BCM3510"
-8.) ATSC card 2nd generation:
+8.) AirStar ATSC card 2nd generation:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "NxtWave Communications NXT2002/NXT2004 based"
-c.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based"
+c.)"Multimedia devices" => "Customise DVB frontends" => "Generic I2C PLL based tuners"
-Author: Uwe Bugla <uwe.bugla@gmx.de> December 2008
+9.) AirStar ATSC card 3rd generation:
+a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
+b.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based"
+c.)"Multimedia devices" => "Customise analog and hybrid tuner modules to build" => "Simple tuner support"
+Author: Uwe Bugla <uwe.bugla@gmx.de> February 2009
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index 9e9c348275a9..7e81e37c0b1e 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -2,8 +2,10 @@
 sysfs - _The_ filesystem for exporting kernel objects. 
 Patrick Mochel  <mochel@osdl.org>
+Mike Murphy <mamurph@cs.clemson.edu>
-10 January 2003
+Revised:    22 February 2009
+Original:   10 January 2003
 What it is:
@@ -64,12 +66,13 @@ An attribute definition is simply:
 struct attribute {
        char                    * name;
+        struct module           *owner;
        mode_t                  mode;
 };
-int sysfs_create_file(struct kobject * kobj, struct attribute * attr);
+int sysfs_create_file(struct kobject * kobj, const struct attribute * attr);
-void sysfs_remove_file(struct kobject * kobj, struct attribute * attr);
+void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr);
 A bare attribute contains no means to read or write the value of the
@@ -80,9 +83,11 @@ a specific object type.
 For example, the driver model defines struct device_attribute like:
 struct device_attribute {
-        struct attribute        attr;
+        struct attribute        attr;
-        ssize_t (*show)(struct device * dev, char * buf);
+        ssize_t (*show)(struct device *dev, struct device_attribute *attr,
-        ssize_t (*store)(struct device * dev, const char * buf);
+                        char *buf);
+        ssize_t (*store)(struct device *dev, struct device_attribute *attr,
+                         const char *buf, size_t count);
 };
 int device_create_file(struct device *, struct device_attribute *);
@@ -90,12 +95,8 @@ void device_remove_file(struct device *, struct device_attribute *);
 It also defines this helper for defining device attributes: 
-#define DEVICE_ATTR(_name, _mode, _show, _store)      \
+#define DEVICE_ATTR(_name, _mode, _show, _store) \
-struct device_attribute dev_attr_##_name = {            \
+struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)
-        .attr = {.name  = __stringify(_name) , .mode   = _mode },      \
-        .show   = _show,                                \
-        .store  = _store,                               \
-};
 For example, declaring
@@ -107,9 +108,9 @@ static struct device_attribute dev_attr_foo = {
       .attr    = {
                .name = "foo",
                .mode = S_IWUSR | S_IRUGO,
+                .show = show_foo,
+                .store = store_foo,
        },
-        .show = show_foo,
-        .store = store_foo,
 };
@@ -161,10 +162,12 @@ To read or write attributes, show() or store() methods must be
 specified when declaring the attribute. The method types should be as
 simple as those defined for device attributes:
-        ssize_t (*show)(struct device * dev, char * buf);
+ssize_t (*show)(struct device * dev, struct device_attribute * attr,
-        ssize_t (*store)(struct device * dev, const char * buf);
+                char * buf);
+ssize_t (*store)(struct device * dev, struct device_attribute * attr,
+                 const char * buf);
-IOW, they should take only an object and a buffer as parameters. 
+IOW, they should take only an object, an attribute, and a buffer as parameters.
 sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the
@@ -299,14 +302,16 @@ The following interface layers currently exist in sysfs:
 Structure:
 struct device_attribute {
-        struct attribute        attr;
+        struct attribute        attr;
-        ssize_t (*show)(struct device * dev, char * buf);
+        ssize_t (*show)(struct device *dev, struct device_attribute *attr,
-        ssize_t (*store)(struct device * dev, const char * buf);
+                        char *buf);
+        ssize_t (*store)(struct device *dev, struct device_attribute *attr,
+                         const char *buf, size_t count);
 };
 Declaring:
-DEVICE_ATTR(_name, _str, _mode, _show, _store);
+DEVICE_ATTR(_name, _mode, _show, _store);
 Creation/Removal:
@@ -342,7 +347,8 @@ Structure:
 struct driver_attribute {
        struct attribute        attr;
        ssize_t (*show)(struct device_driver *, char * buf);
-        ssize_t (*store)(struct device_driver *, const char * buf);
+        ssize_t (*store)(struct device_driver *, const char * buf,
+                         size_t count);
 };
 Declaring:
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index b182626739ea..54f21a5c262b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -114,7 +114,7 @@ In addition, the following text indicates that the option:
 Parameters denoted with BOOT are actually interpreted by the boot
 loader, and have no meaning to the kernel directly.
 Do not modify the syntax of boot loader parameters without extreme
-need or coordination with <Documentation/x86/i386/boot.txt>.
+need or coordination with <Documentation/x86/boot.txt>.
 There are also arch-specific kernel-parameters not documented here.
 See for example <Documentation/x86/x86_64/boot-options.txt>.
@@ -134,7 +134,7 @@ and is between 256 and 4096 characters. It is defined in the file
        acpi=           [HW,ACPI,X86-64,i386]
                        Advanced Configuration and Power Interface
-                        Format: { force | off | ht | strict | noirq }
+                        Format: { force | off | ht | strict | noirq | rsdt }
                        force -- enable ACPI if default was off
                        off -- disable ACPI if default was on
                        noirq -- do not use ACPI for IRQ routing
@@ -868,8 +868,10 @@ and is between 256 and 4096 characters. It is defined in the file
        icn=            [HW,ISDN]
                        Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
-        ide=            [HW] (E)IDE subsystem
+        ide-core.nodma= [HW] (E)IDE subsystem
-                        Format: ide=nodma or ide=doubler
+                        Format: =0.0 to prevent dma on hda, =0.1 hdb =1.0 hdc
+                        .vlb_clock .pci_clock .noflush .noprobe .nowerr .cdrom
+                        .chs .ignore_cable are additional options
                        See Documentation/ide/ide.txt.
        idebus=         [HW] (E)IDE subsystem - VLB/PCI bus speed
@@ -2449,7 +2451,7 @@ and is between 256 and 4096 characters. It is defined in the file
                        See Documentation/fb/modedb.txt.
        vga=            [BOOT,X86-32] Select a particular video mode
-                        See Documentation/x86/i386/boot.txt and
+                        See Documentation/x86/boot.txt and
                        Documentation/svga.txt.
                        Use vga=ask for menu.
                        This is actually a boot loader parameter; the value is