---

yaml
---
r: 109491
b: refs/heads/master
c: 9662e08
h: refs/heads/master
i:
  109489: 42eed8c
  109487: d182dfc
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 4eb57c98b8d2a812441b33911ca3cf9602699654
+refs/heads/master: 9662e0802445a1f56cef11bbd0d520b07238424a

trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt

@@ -13,21 +13,6 @@ Introduction
   data-sheet/users manual to find out the complete list.
 
 
-GPIOLIB
--------
-
-  With the event of the GPIOLIB in drivers/gpio, support for some
-  of the GPIO functions such as reading and writing a pin will
-  be removed in favour of this common access method.
-
-  Once all the extant drivers have been converted, the functions
-  listed below will be removed (they may be marked as __deprecated
-  in the near future).
-
-  - s3c2410_gpio_getpin
-  - s3c2410_gpio_setpin
-
-
 Headers
 -------
 

trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt

@@ -8,10 +8,9 @@ Introduction
 
   The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
   by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
-  S3C2412, S3C2413, S3C2440, S3C2442 and S3C2443 devices are supported.
-
-  Support for the S3C2400 and S3C24A0 series are in progress.
+  S3C2412, S3C2413, S3C2440 and S3C2442 devices are supported.
 
+  Support for the S3C2400 series is in progress.
 
 Configuration
 -------------
@@ -39,22 +38,6 @@ Layout
   Register, kernel and platform data definitions are held in the
   arch/arm/mach-s3c2410 directory./include/mach
 
-arch/arm/plat-s3c24xx:
-
-  Files in here are either common to all the s3c24xx family,
-  or are common to only some of them with names to indicate this
-  status. The files that are not common to all are generally named
-  with the initial cpu they support in the series to ensure a short
-  name without any possibility of confusion with newer devices.
-
-  As an example, initially s3c244x would cover s3c2440 and s3c2442, but
-  with the s3c2443 which does not share many of the same drivers in
-  this directory, the name becomes invalid. We stick to s3c2440-<x>
-  to indicate a driver that is s3c2440 and s3c2442 compatible.
-
-  This does mean that to find the status of any given SoC, a number
-  of directories may need to be searched.
-
 
 Machines
 --------
@@ -176,17 +159,6 @@ NAND
   For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt
 
 
-SD/MMC
-------
-
-  The SD/MMC hardware pre S3C2443 is supported in the current
-  kernel, the driver is drivers/mmc/host/s3cmci.c and supports
-  1 and 4 bit SD or MMC cards.
-
-  The SDIO behaviour of this driver has not been fully tested. There is no
-  current support for hardware SDIO interrupts.
-
-
 Serial
 ------
 
@@ -206,9 +178,6 @@ GPIO
   The core contains support for manipulating the GPIO, see the
   documentation in GPIO.txt in the same directory as this file.
 
-  Newer kernels carry GPIOLIB, and support is being moved towards
-  this with some of the older support in line to be removed.
-
 
 Clock Management
 ----------------

trunk/Documentation/filesystems/ubifs.txt

@@ -57,7 +57,7 @@ Similarly to JFFS2, UBIFS supports on-the-flight compression which makes
 it possible to fit quite a lot of data to the flash.
 
 Similarly to JFFS2, UBIFS is tolerant of unclean reboots and power-cuts.
-It does not need stuff like fsck.ext2. UBIFS automatically replays its
+It does not need stuff like ckfs.ext2. UBIFS automatically replays its
 journal and recovers from crashes, ensuring that the on-flash data
 structures are consistent.
 

trunk/Documentation/hwmon/ibmaem

@@ -1,11 +1,8 @@
 Kernel driver ibmaem
 ======================
 
-This driver talks to the IBM Systems Director Active Energy Manager, known
-henceforth as AEM.
-
 Supported systems:
-  * Any recent IBM System X server with AEM support.
+  * Any recent IBM System X server with Active Energy Manager support.
     This includes the x3350, x3550, x3650, x3655, x3755, x3850 M2,
     x3950 M2, and certain HS2x/LS2x/QS2x blades.  The IPMI host interface
     driver ("ipmi-si") needs to be loaded for this driver to do anything.
@@ -17,22 +14,24 @@ Author: Darrick J. Wong
 Description
 -----------
 
-This driver implements sensor reading support for the energy and power meters
-available on various IBM System X hardware through the BMC.  All sensor banks
-will be exported as platform devices; this driver can talk to both v1 and v2
-interfaces.  This driver is completely separate from the older ibmpex driver.
+This driver implements sensor reading support for the energy and power
+meters available on various IBM System X hardware through the BMC.  All
+sensor banks will be exported as platform devices; this driver can talk
+to both v1 and v2 interfaces.  This driver is completely separate from the
+older ibmpex driver.
 
-The v1 AEM interface has a simple set of features to monitor energy use.  There
-is a register that displays an estimate of raw energy consumption since the
-last BMC reset, and a power sensor that returns average power use over a
-configurable interval.
+The v1 AEM interface has a simple set of features to monitor energy use.
+There is a register that displays an estimate of raw energy consumption
+since the last BMC reset, and a power sensor that returns average power
+use over a configurable interval.
 
-The v2 AEM interface is a bit more sophisticated, being able to present a wider
-range of energy and power use registers, the power cap as set by the AEM
-software, and temperature sensors.
+The v2 AEM interface is a bit more sophisticated, being able to present
+a wider range of energy and power use registers, the power cap as
+set by the AEM software, and temperature sensors.
 
 Special Features
 ----------------
 
-The "power_cap" value displays the current system power cap, as set by the AEM
-software.  Setting the power cap from the host is not currently supported.
+The "power_cap" value displays the current system power cap, as set by
+the Active Energy Manager software.  Setting the power cap from the host
+is not currently supported.

trunk/Documentation/laptops/thinkpad-acpi.txt

@@ -44,7 +44,7 @@ detailed description):
 	- LCD brightness control
 	- Volume control
 	- Fan control and monitoring: fan speed, fan enable/disable
-	- Experimental: WAN enable and disable
+	- WAN enable and disable
 
 A compatibility table by model and feature is maintained on the web
 site, http://ibm-acpi.sf.net/. I appreciate any success or failure
@@ -1375,18 +1375,13 @@ with EINVAL, try to set pwm1_enable to 1 and pwm1 to at least 128 (255
 would be the safest choice, though).
 
 
-EXPERIMENTAL: WAN
------------------
+WAN
+---
 
 procfs: /proc/acpi/ibm/wan
 sysfs device attribute: wwan_enable (deprecated)
 sysfs rfkill class: switch "tpacpi_wwan_sw"
 
-This feature is marked EXPERIMENTAL because the implementation
-directly accesses hardware registers and may not work as expected. USE
-WITH CAUTION! To use this feature, you need to supply the
-experimental=1 parameter when loading the module.
-
 This feature shows the presence and current state of a W-WAN (Sierra
 Wireless EV-DO) device.
 

trunk/Documentation/sound/alsa/ALSA-Configuration.txt

@@ -1144,6 +1144,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
 
     This module supports autoprobe and multiple cards.
 
+    Power management is _not_ supported.
+
   Module snd-ice1712
   ------------------
 
@@ -1626,6 +1628,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
 
     This module supports autoprobe and multiple cards.
 
+    Power management is _not_ supported.
+
   Module snd-pcsp
   -----------------
 
@@ -2077,11 +2081,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
   Module snd-virtuoso
   -------------------
 
-    Module for sound cards based on the Asus AV100/AV200 chips,
-    i.e., Xonar D1, DX, D2 and D2X.
+    Module for sound cards based on the Asus AV200 chip, i.e.,
+    Xonar D2 and Xonar D2X.
 
     This module supports autoprobe and multiple cards.
 
+    Power management is _not_ supported.
+
   Module snd-vx222
   ----------------
 

trunk/Documentation/vm/page_migration

@@ -18,11 +18,10 @@ migrate_pages function call takes two sets of nodes and moves pages of a
 process that are located on the from nodes to the destination nodes.
 Page migration functions are provided by the numactl package by Andi Kleen
 (a version later than 0.9.3 is required. Get it from
-ftp://oss.sgi.com/www/projects/libnuma/download/). numactl provides libnuma
-which provides an interface similar to other numa functionality for page
-migration.  cat /proc/<pid>/numa_maps allows an easy review of where the
-pages of a process are located. See also the numa_maps documentation in the
-proc(5) man page.
+ftp://ftp.suse.com/pub/people/ak). numactl provided libnuma which
+provides an interface similar to other numa functionality for page migration.
+cat /proc/<pid>/numa_maps allows an easy review of where the pages of
+a process are located. See also the numa_maps manpage in the numactl package.
 
 Manual migration is useful if for example the scheduler has relocated
 a process to a processor on a distant node. A batch scheduler or an

trunk/MAINTAINERS

@@ -175,18 +175,12 @@ M:	bcrl@kvack.org
 L:	linux-aio@kvack.org
 S:	Supported
 
-ABIT UGURU 1,2 HARDWARE MONITOR DRIVER
+ABIT UGURU HARDWARE MONITOR DRIVER
 P:	Hans de Goede
 M:	j.w.r.degoede@hhs.nl
 L:	lm-sensors@lm-sensors.org
 S:	Maintained
 
-ABIT UGURU 3 HARDWARE MONITOR DRIVER
-P:	Alistair John Strachan
-M:	alistair@devzero.co.uk
-L:	lm-sensors@lm-sensors.org
-S:	Maintained
-
 ACENIC DRIVER
 P:	Jes Sorensen
 M:	jes@trained-monkey.org
@@ -3754,16 +3748,6 @@ L:	linux-visws-devel@lists.sf.net
 W:	http://linux-visws.sf.net
 S:	Maintained for 2.6.
 
-SGI GRU DRIVER
-P:	Jack Steiner
-M:	steiner@sgi.com
-S:	Maintained
-
-SGI XP/XPC/XPNET DRIVER
-P:	Dean Nelson
-M:	dcn@sgi.com
-S:	Maintained
-
 SIMTEC EB110ATX (Chalice CATS)
 P:	Ben Dooks
 P:	Vincent Sanders

trunk/arch/arm/boot/compressed/.gitignore

@@ -1,3 +1,2 @@
-font.c
 piggy.gz
-vmlinux.lds
+font.c

trunk/arch/arm/common/dmabounce.c

@@ -246,9 +246,9 @@ map_single(struct device *dev, void *ptr, size_t size,
 		}
 
 		dev_dbg(dev,
-			"%s: unsafe buffer %p (dma=%#x) mapped to %p (dma=%#x)\n",
-			__func__, buf->ptr, virt_to_dma(dev, buf->ptr),
-			buf->safe, buf->safe_dma_addr);
+			"%s: unsafe buffer %p (phy=%p) mapped to %p (phy=%p)\n",
+			__func__, buf->ptr, (void *) virt_to_dma(dev, buf->ptr),
+			buf->safe, (void *) buf->safe_dma_addr);
 
 		if ((dir == DMA_TO_DEVICE) ||
 		    (dir == DMA_BIDIRECTIONAL)) {
@@ -292,9 +292,9 @@ unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size,
 		BUG_ON(buf->size != size);
 
 		dev_dbg(dev,
-			"%s: unsafe buffer %p (dma=%#x) mapped to %p (dma=%#x)\n",
-			__func__, buf->ptr, virt_to_dma(dev, buf->ptr),
-			buf->safe, buf->safe_dma_addr);
+			"%s: unsafe buffer %p (phy=%p) mapped to %p (phy=%p)\n",
+			__func__, buf->ptr, (void *) virt_to_dma(dev, buf->ptr),
+			buf->safe, (void *) buf->safe_dma_addr);
 
 		DO_STATS ( device_info->bounce_count++ );
 
@@ -321,8 +321,9 @@ unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size,
 	}
 }
 
-static int sync_single(struct device *dev, dma_addr_t dma_addr, size_t size,
-			enum dma_data_direction dir)
+static inline void
+sync_single(struct device *dev, dma_addr_t dma_addr, size_t size,
+		enum dma_data_direction dir)
 {
 	struct dmabounce_device_info *device_info = dev->archdata.dmabounce;
 	struct safe_buffer *buf = NULL;
@@ -354,9 +355,9 @@ static int sync_single(struct device *dev, dma_addr_t dma_addr, size_t size,
 		 */
 
 		dev_dbg(dev,
-			"%s: unsafe buffer %p (dma=%#x) mapped to %p (dma=%#x)\n",
-			__func__, buf->ptr, virt_to_dma(dev, buf->ptr),
-			buf->safe, buf->safe_dma_addr);
+			"%s: unsafe buffer %p (phy=%p) mapped to %p (phy=%p)\n",
+			__func__, buf->ptr, (void *) virt_to_dma(dev, buf->ptr),
+			buf->safe, (void *) buf->safe_dma_addr);
 
 		DO_STATS ( device_info->bounce_count++ );
 
@@ -382,9 +383,8 @@ static int sync_single(struct device *dev, dma_addr_t dma_addr, size_t size,
 		 * No need to sync the safe buffer - it was allocated
 		 * via the coherent allocators.
 		 */
-		return 0;
 	} else {
-		return 1;
+		dma_cache_maint(dma_to_virt(dev, dma_addr), size, dir);
 	}
 }
 
@@ -474,29 +474,25 @@ dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
 	}
 }
 
-void dma_sync_single_range_for_cpu(struct device *dev, dma_addr_t dma_addr,
-				   unsigned long offset, size_t size,
-				   enum dma_data_direction dir)
+void
+dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_addr, size_t size,
+				enum dma_data_direction dir)
 {
-	dev_dbg(dev, "%s(dma=%#x,off=%#lx,size=%zx,dir=%x)\n",
-		__func__, dma_addr, offset, size, dir);
+	dev_dbg(dev, "%s(ptr=%p,size=%d,dir=%x)\n",
+		__func__, (void *) dma_addr, size, dir);
 
-	if (sync_single(dev, dma_addr, offset + size, dir))
-		dma_cache_maint(dma_to_virt(dev, dma_addr) + offset, size, dir);
+	sync_single(dev, dma_addr, size, dir);
 }
-EXPORT_SYMBOL(dma_sync_single_range_for_cpu);
 
-void dma_sync_single_range_for_device(struct device *dev, dma_addr_t dma_addr,
-				      unsigned long offset, size_t size,
-				      enum dma_data_direction dir)
+void
+dma_sync_single_for_device(struct device *dev, dma_addr_t dma_addr, size_t size,
+				enum dma_data_direction dir)
 {
-	dev_dbg(dev, "%s(dma=%#x,off=%#lx,size=%zx,dir=%x)\n",
-		__func__, dma_addr, offset, size, dir);
+	dev_dbg(dev, "%s(ptr=%p,size=%d,dir=%x)\n",
+		__func__, (void *) dma_addr, size, dir);
 
-	if (sync_single(dev, dma_addr, offset + size, dir))
-		dma_cache_maint(dma_to_virt(dev, dma_addr) + offset, size, dir);
+	sync_single(dev, dma_addr, size, dir);
 }
-EXPORT_SYMBOL(dma_sync_single_range_for_device);
 
 void
 dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nents,
@@ -648,6 +644,8 @@ EXPORT_SYMBOL(dma_map_single);
 EXPORT_SYMBOL(dma_unmap_single);
 EXPORT_SYMBOL(dma_map_sg);
 EXPORT_SYMBOL(dma_unmap_sg);
+EXPORT_SYMBOL(dma_sync_single_for_cpu);
+EXPORT_SYMBOL(dma_sync_single_for_device);
 EXPORT_SYMBOL(dma_sync_sg_for_cpu);
 EXPORT_SYMBOL(dma_sync_sg_for_device);
 EXPORT_SYMBOL(dmabounce_register_dev);