14 files changed, 231 insertions, 39 deletions

diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss
index 0a92a7c93a62..4f29e5f1ebfa 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss
+++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss
@@ -31,3 +31,31 @@ Date:		March 2009
 Kernel Version: 2.6.30
 Contact:        iss_storagedev@hp.com
 Description:    A symbolic link to /sys/block/cciss!cXdY
+
+Where:          /sys/bus/pci/devices/<dev>/ccissX/rescan
+Date:           August 2009
+Kernel Version: 2.6.31
+Contact:        iss_storagedev@hp.com
+Description:    Kicks of a rescan of the controller to discover logical
+                drive topology changes.
+
+Where:          /sys/bus/pci/devices/<dev>/ccissX/cXdY/lunid
+Date:           August 2009
+Kernel Version: 2.6.31
+Contact:        iss_storagedev@hp.com
+Description:    Displays the 8-byte LUN ID used to address logical
+                drive Y of controller X.
+
+Where:          /sys/bus/pci/devices/<dev>/ccissX/cXdY/raid_level
+Date:           August 2009
+Kernel Version: 2.6.31
+Contact:        iss_storagedev@hp.com
+Description:    Displays the RAID level of logical drive Y of
+                controller X.
+
+Where:          /sys/bus/pci/devices/<dev>/ccissX/cXdY/usage_count
+Date:           August 2009
+Kernel Version: 2.6.31
+Contact:        iss_storagedev@hp.com
+Description:    Displays the usage count (number of opens) of logical drive Y
+                of controller X.
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index b7f9d3b4bbf6..72651f788f4e 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -232,7 +232,7 @@ your e-mail client so that it sends your patches untouched.
 When sending patches to Linus, always follow step #7.
 
 Large changes are not appropriate for mailing lists, and some
-maintainers.  If your patch, uncompressed, exceeds 40 kB in size,
+maintainers.  If your patch, uncompressed, exceeds 300 kB in size,
 it is preferred that you store your patch on an Internet-accessible
 server, and provide instead a URL (link) pointing to your patch.
 
diff --git a/Documentation/arm/tcm.txt b/Documentation/arm/tcm.txt
new file mode 100644
index 000000000000..77fd9376e6d7
--- /dev/null
+++ b/Documentation/arm/tcm.txt
@@ -0,0 +1,147 @@
+ARM TCM (Tightly-Coupled Memory) handling in Linux
+----
+Written by Linus Walleij <linus.walleij@stericsson.com>
+
+Some ARM SoC:s have a so-called TCM (Tightly-Coupled Memory).
+This is usually just a few (4-64) KiB of RAM inside the ARM
+processor.
+
+Due to being embedded inside the CPU The TCM has a
+Harvard-architecture, so there is an ITCM (instruction TCM)
+and a DTCM (data TCM). The DTCM can not contain any
+instructions, but the ITCM can actually contain data.
+The size of DTCM or ITCM is minimum 4KiB so the typical
+minimum configuration is 4KiB ITCM and 4KiB DTCM.
+
+ARM CPU:s have special registers to read out status, physical
+location and size of TCM memories. arch/arm/include/asm/cputype.h
+defines a CPUID_TCM register that you can read out from the
+system control coprocessor. Documentation from ARM can be found
+at http://infocenter.arm.com, search for "TCM Status Register"
+to see documents for all CPUs. Reading this register you can
+determine if ITCM (bit 0) and/or DTCM (bit 16) is present in the
+machine.
+
+There is further a TCM region register (search for "TCM Region
+Registers" at the ARM site) that can report and modify the location
+size of TCM memories at runtime. This is used to read out and modify
+TCM location and size. Notice that this is not a MMU table: you
+actually move the physical location of the TCM around. At the
+place you put it, it will mask any underlying RAM from the
+CPU so it is usually wise not to overlap any physical RAM with
+the TCM.
+
+The TCM memory can then be remapped to another address again using
+the MMU, but notice that the TCM if often used in situations where
+the MMU is turned off. To avoid confusion the current Linux
+implementation will map the TCM 1 to 1 from physical to virtual
+memory in the location specified by the machine.
+
+TCM is used for a few things:
+
+- FIQ and other interrupt handlers that need deterministic
+  timing and cannot wait for cache misses.
+
+- Idle loops where all external RAM is set to self-refresh
+  retention mode, so only on-chip RAM is accessible by
+  the CPU and then we hang inside ITCM waiting for an
+  interrupt.
+
+- Other operations which implies shutting off or reconfiguring
+  the external RAM controller.
+
+There is an interface for using TCM on the ARM architecture
+in <asm/tcm.h>. Using this interface it is possible to:
+
+- Define the physical address and size of ITCM and DTCM.
+
+- Tag functions to be compiled into ITCM.
+
+- Tag data and constants to be allocated to DTCM and ITCM.
+
+- Have the remaining TCM RAM added to a special
+  allocation pool with gen_pool_create() and gen_pool_add()
+  and provice tcm_alloc() and tcm_free() for this
+  memory. Such a heap is great for things like saving
+  device state when shutting off device power domains.
+
+A machine that has TCM memory shall select HAVE_TCM in
+arch/arm/Kconfig for itself, and then the
+rest of the functionality will depend on the physical
+location and size of ITCM and DTCM to be defined in
+mach/memory.h for the machine. Code that needs to use
+TCM shall #include <asm/tcm.h> If the TCM is not located
+at the place given in memory.h it will be moved using
+the TCM Region registers.
+
+Functions to go into itcm can be tagged like this:
+int __tcmfunc foo(int bar);
+
+Variables to go into dtcm can be tagged like this:
+int __tcmdata foo;
+
+Constants can be tagged like this:
+int __tcmconst foo;
+
+To put assembler into TCM just use
+.section ".tcm.text" or .section ".tcm.data"
+respectively.
+
+Example code:
+
+#include <asm/tcm.h>
+
+/* Uninitialized data */
+static u32 __tcmdata tcmvar;
+/* Initialized data */
+static u32 __tcmdata tcmassigned = 0x2BADBABEU;
+/* Constant */
+static const u32 __tcmconst tcmconst = 0xCAFEBABEU;
+
+static void __tcmlocalfunc tcm_to_tcm(void)
+{
+        int i;
+        for (i = 0; i < 100; i++)
+                tcmvar ++;
+}
+
+static void __tcmfunc hello_tcm(void)
+{
+        /* Some abstract code that runs in ITCM */
+        int i;
+        for (i = 0; i < 100; i++) {
+                tcmvar ++;
+        }
+        tcm_to_tcm();
+}
+
+static void __init test_tcm(void)
+{
+        u32 *tcmem;
+        int i;
+
+        hello_tcm();
+        printk("Hello TCM executed from ITCM RAM\n");
+
+        printk("TCM variable from testrun: %u @ %p\n", tcmvar, &tcmvar);
+        tcmvar = 0xDEADBEEFU;
+        printk("TCM variable: 0x%x @ %p\n", tcmvar, &tcmvar);
+
+        printk("TCM assigned variable: 0x%x @ %p\n", tcmassigned, &tcmassigned);
+
+        printk("TCM constant: 0x%x @ %p\n", tcmconst, &tcmconst);
+
+        /* Allocate some TCM memory from the pool */
+        tcmem = tcm_alloc(20);
+        if (tcmem) {
+                printk("TCM Allocated 20 bytes of TCM @ %p\n", tcmem);
+                tcmem[0] = 0xDEADBEEFU;
+                tcmem[1] = 0x2BADBABEU;
+                tcmem[2] = 0xCAFEBABEU;
+                tcmem[3] = 0xDEADBEEFU;
+                tcmem[4] = 0x2BADBABEU;
+                for (i = 0; i < 5; i++)
+                        printk("TCM tcmem[%d] = %08x\n", i, tcmem[i]);
+                tcm_free(tcmem, 20);
+        }
+}
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt
index 18b5ec8cea45..bf4f4b7e11b3 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -282,9 +282,16 @@ stripe=n		Number of filesystem blocks that mballoc will try
                         to use for allocation size and alignment. For RAID5/6
                         systems this should be the number of data
                         disks *  RAID chunk size in file system blocks.
-delalloc        (*)     Deferring block allocation until write-out time.
-nodelalloc              Disable delayed allocation. Blocks are allocation
-                        when data is copied from user to page cache.
+
+delalloc        (*)     Defer block allocation until just before ext4
+                        writes out the block(s) in question.  This
+                        allows ext4 to better allocation decisions
+                        more efficiently.
+nodelalloc              Disable delayed allocation.  Blocks are allocated
+                        when the data is copied from userspace to the
+                        page cache, either via the write(2) system call
+                        or when an mmap'ed page which was previously
+                        unallocated is written for the first time.
 
 max_batch_time=usec     Maximum amount of time ext4 should wait for
                         additional filesystem operations to be batch
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index b5aee7838a00..2c48f945546b 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1113,7 +1113,6 @@ Table 1-12: Files in /proc/fs/ext4/<devname>
 ..............................................................................
  File            Content                                        
  mb_groups       details of multiblock allocator buddy cache of free blocks
- mb_history      multiblock allocation history
 ..............................................................................
 
 
diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt
index b58b84b50fa2..eed520fd0c8e 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt
@@ -102,7 +102,7 @@ shortname=lower|win95|winnt|mixed
                  winnt: emulate the Windows NT rule for display/create.
                  mixed: emulate the Windows NT rule for display,
                         emulate the Windows 95 rule for create.
-                 Default setting is `lower'.
+                 Default setting is `mixed'.
 
 tz=UTC        -- Interpret timestamps as UTC rather than local time.
                  This option disables the conversion of timestamps
diff --git a/Documentation/hwmon/ltc4215 b/Documentation/hwmon/ltc4215
index 2e6a21eb656c..c196a1846259 100644
--- a/Documentation/hwmon/ltc4215
+++ b/Documentation/hwmon/ltc4215
@@ -22,12 +22,13 @@ Usage Notes
 -----------
 
 This driver does not probe for LTC4215 devices, due to the fact that some
-of the possible addresses are unfriendly to probing. You will need to use
-the "force" parameter to tell the driver where to find the device.
+of the possible addresses are unfriendly to probing. You will have to
+instantiate the devices explicitly.
 
 Example: the following will load the driver for an LTC4215 at address 0x44
 on I2C bus #0:
-$ modprobe ltc4215 force=0,0x44
+$ modprobe ltc4215
+$ echo ltc4215 0x44 > /sys/bus/i2c/devices/i2c-0/new_device
 
 
 Sysfs entries
diff --git a/Documentation/hwmon/ltc4245 b/Documentation/hwmon/ltc4245
index bae7a3adc5d8..02838a47d862 100644
--- a/Documentation/hwmon/ltc4245
+++ b/Documentation/hwmon/ltc4245
@@ -23,12 +23,13 @@ Usage Notes
 -----------
 
 This driver does not probe for LTC4245 devices, due to the fact that some
-of the possible addresses are unfriendly to probing. You will need to use
-the "force" parameter to tell the driver where to find the device.
+of the possible addresses are unfriendly to probing. You will have to
+instantiate the devices explicitly.
 
 Example: the following will load the driver for an LTC4245 at address 0x23
 on I2C bus #1:
-$ modprobe ltc4245 force=1,0x23
+$ modprobe ltc4245
+$ echo ltc4245 0x23 > /sys/bus/i2c/devices/i2c-1/new_device
 
 
 Sysfs entries
diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices
index c740b7b41088..e89490270aba 100644
--- a/Documentation/i2c/instantiating-devices
+++ b/Documentation/i2c/instantiating-devices
@@ -188,7 +188,7 @@ segment, the address is sufficient to uniquely identify the device to be
 deleted.
 
 Example:
-# echo eeprom 0x50 > /sys/class/i2c-adapter/i2c-3/new_device
+# echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
 
 While this interface should only be used when in-kernel device declaration
 can't be done, there is a variety of cases where it can be helpful:
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt
index 6d03487ef1c7..aafcaa634191 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -199,18 +199,22 @@ kind to allow it (and it often doesn't!).
 
 Not all bits in the mask can be modified.  Not all bits that can be
 modified do anything.  Not all hot keys can be individually controlled
-by the mask.  Some models do not support the mask at all, and in those
-models, hot keys cannot be controlled individually.  The behaviour of
-the mask is, therefore, highly dependent on the ThinkPad model.
+by the mask.  Some models do not support the mask at all.  The behaviour
+of the mask is, therefore, highly dependent on the ThinkPad model.
+
+The driver will filter out any unmasked hotkeys, so even if the firmware
+doesn't allow disabling an specific hotkey, the driver will not report
+events for unmasked hotkeys.
 
 Note that unmasking some keys prevents their default behavior.  For
 example, if Fn+F5 is unmasked, that key will no longer enable/disable
-Bluetooth by itself.
+Bluetooth by itself in firmware.
 
-Note also that not all Fn key combinations are supported through ACPI.
-For example, on the X40, the brightness, volume and "Access IBM" buttons
-do not generate ACPI events even with this driver.  They *can* be used
-through the "ThinkPad Buttons" utility, see http://www.nongnu.org/tpb/
+Note also that not all Fn key combinations are supported through ACPI
+depending on the ThinkPad model and firmware version.  On those
+ThinkPads, it is still possible to support some extra hotkeys by
+polling the "CMOS NVRAM" at least 10 times per second.  The driver
+attempts to enables this functionality automatically when required.
 
 procfs notes:
 
@@ -255,18 +259,11 @@ sysfs notes:
                 1: does nothing
 
         hotkey_mask:
-                bit mask to enable driver-handling (and depending on
+                bit mask to enable reporting (and depending on
                 the firmware, ACPI event generation) for each hot key
                 (see above).  Returns the current status of the hot keys
                 mask, and allows one to modify it.
 
-                Note: when NVRAM polling is active, the firmware mask
-                will be different from the value returned by
-                hotkey_mask.  The driver will retain enabled bits for
-                hotkeys that are under NVRAM polling even if the
-                firmware refuses them, and will not set these bits on
-                the firmware hot key mask.
-
         hotkey_all_mask:
                 bit mask that should enable event reporting for all
                 supported hot keys, when echoed to hotkey_mask above.
@@ -279,7 +276,8 @@ sysfs notes:
                 bit mask that should enable event reporting for all
                 supported hot keys, except those which are always
                 handled by the firmware anyway.  Echo it to
-                hotkey_mask above, to use.
+                hotkey_mask above, to use.  This is the default mask
+                used by the driver.
 
         hotkey_source_mask:
                 bit mask that selects which hot keys will the driver
@@ -287,9 +285,10 @@ sysfs notes:
                 based on the capabilities reported by the ACPI firmware,
                 but it can be overridden at runtime.
 
-                Hot keys whose bits are set in both hotkey_source_mask
-                and also on hotkey_mask are polled for in NVRAM.  Only a
-                few hot keys are available through CMOS NVRAM polling.
+                Hot keys whose bits are set in hotkey_source_mask are
+                polled for in NVRAM, and reported as hotkey events if
+                enabled in hotkey_mask.  Only a few hot keys are
+                available through CMOS NVRAM polling.
 
                 Warning: when in NVRAM mode, the volume up/down/mute
                 keys are synthesized according to changes in the mixer,
@@ -525,6 +524,7 @@ compatibility purposes when hotkey_report_mode is set to 1.
 0x2305          System is waking up from suspend to eject bay
 0x2404          System is waking up from hibernation to undock
 0x2405          System is waking up from hibernation to eject bay
+0x5010          Brightness level changed/control event
 
 The above events are never propagated by the driver.
 
@@ -532,7 +532,6 @@ The above events are never propagated by the driver.
 0x4003          Undocked (see 0x2x04), can sleep again
 0x500B          Tablet pen inserted into its storage bay
 0x500C          Tablet pen removed from its storage bay
-0x5010          Brightness level changed (newer Lenovo BIOSes)
 
 The above events are propagated by the driver.
 
@@ -621,6 +620,8 @@ For Lenovo models *with* ACPI backlight control:
 2. Do *NOT* load up ACPI video, enable the hotkeys in thinkpad-acpi,
    and map them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN.  Process
    these keys on userspace somehow (e.g. by calling xbacklight).
+   The driver will do this automatically if it detects that ACPI video
+   has been disabled.
 
 
 Bluetooth
@@ -1459,3 +1460,8 @@ Sysfs interface changelog:
 0x020400:       Marker for 16 LEDs support.  Also, LEDs that are known
                 to not exist in a given model are not registered with
                 the LED sysfs class anymore.
+
+0x020500:       Updated hotkey driver, hotkey_mask is always available
+                and it is always able to disable hot keys.  Very old
+                thinkpads are properly supported.  hotkey_bios_mask
+                is deprecated and marked for removal.
diff --git a/Documentation/i2c/chips/eeprom b/Documentation/misc-devices/eeprom
index f7e8104b5764..f7e8104b5764 100644
--- a/Documentation/i2c/chips/eeprom
+++ b/Documentation/misc-devices/eeprom
diff --git a/Documentation/i2c/chips/max6875 b/Documentation/misc-devices/max6875
index 10ca43cd1a72..1e89ee3ccc1b 100644
--- a/Documentation/i2c/chips/max6875
+++ b/Documentation/misc-devices/max6875
@@ -42,10 +42,12 @@ General Remarks
 
 Valid addresses for the MAX6875 are 0x50 and 0x52.
 Valid addresses for the MAX6874 are 0x50, 0x52, 0x54 and 0x56.
-The driver does not probe any address, so you must force the address.
+The driver does not probe any address, so you explicitly instantiate the
+devices.
 
 Example:
-$ modprobe max6875 force=0,0x50
+$ modprobe max6875
+$ echo max6875 0x50 > /sys/bus/i2c/devices/i2c-0/new_device
 
 The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple
 addresses.  For example, for address 0x50, it also reserves 0x51.
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt
index f1708b79f963..75fddb40f416 100644
--- a/Documentation/sound/alsa/HD-Audio-Models.txt
+++ b/Documentation/sound/alsa/HD-Audio-Models.txt
@@ -209,6 +209,7 @@ AD1884A / AD1883 / AD1984A / AD1984B
   laptop        laptop with HP jack sensing
   mobile        mobile devices with HP jack sensing
   thinkpad      Lenovo Thinkpad X300
+  touchsmart    HP Touchsmart
 
 AD1884
 ======
diff --git a/Documentation/w1/masters/ds2482 b/Documentation/w1/masters/ds2482
index 9210d6fa5024..299b91c7609f 100644
--- a/Documentation/w1/masters/ds2482
+++ b/Documentation/w1/masters/ds2482
@@ -24,8 +24,8 @@ General Remarks
 
 Valid addresses are 0x18, 0x19, 0x1a, and 0x1b.
 However, the device cannot be detected without writing to the i2c bus, so no
-detection is done.
-You should force the device address.
+detection is done. You should instantiate the device explicitly.
 
-$ modprobe ds2482 force=0,0x18
+$ modprobe ds2482
+$ echo ds2482 0x18 > /sys/bus/i2c/devices/i2c-0/new_device