---

yaml
---
r: 348813
b: refs/heads/master
c: 886d751
h: refs/heads/master
i:
  348811: 3f9c9ab
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: c4ef9bc4f7e1807d499d3d427712df9f8aa2dcbb
+refs/heads/master: 886d751a2ea99a160f2d0a472231566d9cb0cf58

trunk/Documentation/ABI/testing/sysfs-bus-rbd

@@ -70,10 +70,6 @@ snap_*
 
 	A directory per each snapshot
 
-parent
-
-	Information identifying the pool, image, and snapshot id for
-	the parent image in a layered rbd image (format 2 only).
 
 Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
 -------------------------------------------------------------

trunk/Documentation/ABI/testing/sysfs-devices-node

@@ -0,0 +1,7 @@
+What:		/sys/devices/system/node/nodeX/compact
+Date:		February 2010
+Contact:	Mel Gorman <mel@csn.ul.ie>
+Description:
+		When this file is written to, all memory within that node
+		will be compacted. When it completes, memory will be freed
+		into blocks which have as many contiguous pages as possible

trunk/Documentation/DocBook/media/v4l/driver.xml

@@ -116,15 +116,15 @@ my_suspend              (struct pci_dev *               pci_dev,
 	return 0; /* a negative value on error, 0 on success. */
 }
 
-static void
+static void __devexit
 my_remove               (struct pci_dev *               pci_dev)
 {
 	my_device *my = pci_get_drvdata (pci_dev);
 
 	/* Describe me. */
 }
 
-static int
+static int __devinit
 my_probe                (struct pci_dev *               pci_dev,
 			 const struct pci_device_id *   pci_id)
 {
@@ -157,7 +157,7 @@ my_pci_driver = {
 	.id_table = my_pci_device_ids,
 
 	.probe    = my_probe,
-	.remove   = my_remove,
+	.remove   = __devexit_p (my_remove),
 
 	/* Power management functions. */
 	.suspend  = my_suspend,

trunk/Documentation/PCI/pci-iov-howto.txt

@@ -76,7 +76,7 @@ To notify SR-IOV core of Virtual Function Migration:
 
 Following piece of code illustrates the usage of the SR-IOV API.
 
-static int dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
+static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
 	pci_enable_sriov(dev, NR_VIRTFN);
 
@@ -85,7 +85,7 @@ static int dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	return 0;
 }
 
-static void dev_remove(struct pci_dev *dev)
+static void __devexit dev_remove(struct pci_dev *dev)
 {
 	pci_disable_sriov(dev);
 
@@ -131,7 +131,7 @@ static struct pci_driver dev_driver = {
 	.name =		"SR-IOV Physical Function driver",
 	.id_table =	dev_id_table,
 	.probe =	dev_probe,
-	.remove =	dev_remove,
+	.remove =	__devexit_p(dev_remove),
 	.suspend =	dev_suspend,
 	.resume =	dev_resume,
 	.shutdown =	dev_shutdown,

trunk/Documentation/PCI/pci.txt

@@ -183,13 +183,33 @@ Please mark the initialization and cleanup functions where appropriate
 			initializes.
 	__exit		Exit code. Ignored for non-modular drivers.
 
+
+	__devinit	Device initialization code.
+			Identical to __init if the kernel is not compiled
+			with CONFIG_HOTPLUG, normal function otherwise.
+	__devexit	The same for __exit.
+
 Tips on when/where to use the above attributes:
 	o The module_init()/module_exit() functions (and all
 	  initialization functions called _only_ from these)
 	  should be marked __init/__exit.
 
 	o Do not mark the struct pci_driver.
 
+	o The ID table array should be marked __devinitconst; this is done
+	  automatically if the table is declared with DEFINE_PCI_DEVICE_TABLE().
+
+	o The probe() and remove() functions should be marked __devinit
+	  and __devexit respectively.  All initialization functions
+	  exclusively called by the probe() routine, can be marked __devinit.
+	  Ditto for remove() and __devexit.
+
+	o If mydriver_remove() is marked with __devexit(), then all address
+	  references to mydriver_remove must use __devexit_p(mydriver_remove)
+	  (in the struct pci_driver declaration for example).
+	  __devexit_p() will generate the function name _or_ NULL if the
+	  function will be discarded.  For an example, see drivers/net/tg3.c.
+
 	o Do NOT mark a function if you are not sure which mark to use.
 	  Better to not mark the function than mark the function wrong.
 

trunk/Documentation/acpi/enumeration.txt

@@ -185,7 +185,7 @@ input driver:
 			.acpi_match_table  ACPI_PTR(mpu3050_acpi_match),
 		},
 		.probe		= mpu3050_probe,
-		.remove		= mpu3050_remove,
+		.remove		= __devexit_p(mpu3050_remove),
 		.id_table	= mpu3050_ids,
 	};
 

trunk/Documentation/devicetree/bindings/clock/imx23-clock.txt

@@ -60,6 +60,11 @@ clks: clkctrl@80040000 {
 	compatible = "fsl,imx23-clkctrl";
 	reg = <0x80040000 0x2000>;
 	#clock-cells = <1>;
+	clock-output-names =
+		...
+		"uart",		/* 32 */
+		...
+		"end_of_list";
 };
 
 auart0: serial@8006c000 {

trunk/Documentation/devicetree/bindings/clock/imx25-clock.txt

@@ -146,6 +146,10 @@ clks: ccm@53f80000 {
 	compatible = "fsl,imx25-ccm";
 	reg = <0x53f80000 0x4000>;
 	interrupts = <31>;
+	clock-output-names = ...
+			"uart_ipg",
+			"uart_serial",
+			...;
 };
 
 uart1: serial@43f90000 {

trunk/Documentation/devicetree/bindings/clock/imx28-clock.txt

@@ -83,6 +83,11 @@ clks: clkctrl@80040000 {
 	compatible = "fsl,imx28-clkctrl";
 	reg = <0x80040000 0x2000>;
 	#clock-cells = <1>;
+	clock-output-names =
+		...
+		"uart",		/* 45 */
+		...
+		"end_of_list";
 };
 
 auart0: serial@8006a000 {

trunk/Documentation/devicetree/bindings/clock/imx6q-clock.txt

@@ -211,6 +211,10 @@ clks: ccm@020c4000 {
 	reg = <0x020c4000 0x4000>;
 	interrupts = <0 87 0x04 0 88 0x04>;
 	#clock-cells = <1>;
+	clock-output-names = ...
+			     "uart_ipg",
+			     "uart_serial",
+			     ...;
 };
 
 uart1: serial@02020000 {

trunk/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt

@@ -1,19 +1,4 @@
-Driver a GPIO line that can be used to turn the power off.
-
-The driver supports both level triggered and edge triggered power off.
-At driver load time, the driver will request the given gpio line and
-install a pm_power_off handler. If the optional properties 'input' is
-not found, the GPIO line will be driven in the inactive
-state. Otherwise its configured as an input.
-
-When the pm_power_off is called, the gpio is configured as an output,
-and drive active, so triggering a level triggered power off
-condition. This will also cause an inactive->active edge condition, so
-triggering positive edge triggered power off. After a delay of 100ms,
-the GPIO is set to inactive, thus causing an active->inactive edge,
-triggering negative edge triggered power off. After another 100ms
-delay the GPIO is driver active again. If the power is still on and
-the CPU still running after a 3000ms delay, a WARN_ON(1) is emitted.
+GPIO line that should be set high/low to power off a device
 
 Required properties:
 - compatible : should be "gpio-poweroff".
@@ -28,9 +13,10 @@ Optional properties:
   property is not specified, the GPIO is initialized as an output in its
   inactive state.
 
+
 Examples:
 
 gpio-poweroff {
 	compatible = "gpio-poweroff";
-	gpios = <&gpio 4 0>;
+	gpios = <&gpio 4 0>; /* GPIO 4 Active Low */
 };

trunk/Documentation/filesystems/00-INDEX

@@ -50,8 +50,6 @@ ext4.txt
 	- info, mount options and specifications for the Ext4 filesystem.
 files.txt
 	- info on file management in the Linux kernel.
-f2fs.txt
-	- info and mount options for the F2FS filesystem.
 fuse.txt
 	- info on the Filesystem in User SpacE including mount options.
 gfs2.txt

trunk/Documentation/filesystems/Locking

@@ -80,6 +80,7 @@ rename:		yes (all)	(see below)
 readlink:	no
 follow_link:	no
 put_link:	no
+truncate:	yes		(see below)
 setattr:	yes
 permission:	no (may not block if called in rcu-walk mode)
 get_acl:	no
@@ -95,6 +96,11 @@ atomic_open:	yes
 	Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
 victim.
 	cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
+	->truncate() is never called directly - it's a callback, not a
+method. It's called by vmtruncate() - deprecated library function used by
+->setattr(). Locking information above applies to that call (i.e. is
+inherited from ->setattr() - vmtruncate() is used when ATTR_SIZE had been
+passed).
 
 See Documentation/filesystems/directory-locking for more detailed discussion
 of the locking scheme for directory operations.

trunk/Documentation/filesystems/caching/backend-api.txt

@@ -308,18 +308,6 @@ performed on the denizens of the cache.  These are held in a structure of type:
      obtained by calling object->cookie->def->get_aux()/get_attr().
 
 
- (*) Invalidate data object [mandatory]:
-
-	int (*invalidate_object)(struct fscache_operation *op)
-
-     This is called to invalidate a data object (as pointed to by op->object).
-     All the data stored for this object should be discarded and an
-     attr_changed operation should be performed.  The caller will follow up
-     with an object update operation.
-
-     fscache_op_complete() must be called on op before returning.
-
-
  (*) Discard object [mandatory]:
 
 	void (*drop_object)(struct fscache_object *object)
@@ -431,10 +419,7 @@ performed on the denizens of the cache.  These are held in a structure of type:
 
      If an I/O error occurs, fscache_io_error() should be called and -ENOBUFS
      returned if possible or fscache_end_io() called with a suitable error
-     code.
-
-     fscache_put_retrieval() should be called after a page or pages are dealt
-     with.  This will complete the operation when all pages are dealt with.
+     code..
 
 
  (*) Request pages be read from cache [mandatory]:
@@ -541,27 +526,6 @@ FS-Cache provides some utilities that a cache backend may make use of:
      error value should be 0 if successful and an error otherwise.
 
 
- (*) Record that one or more pages being retrieved or allocated have been dealt
-     with:
-
-	void fscache_retrieval_complete(struct fscache_retrieval *op,
-					int n_pages);
-
-     This is called to record the fact that one or more pages have been dealt
-     with and are no longer the concern of this operation.  When the number of
-     pages remaining in the operation reaches 0, the operation will be
-     completed.
-
-
- (*) Record operation completion:
-
-	void fscache_op_complete(struct fscache_operation *op);
-
-     This is called to record the completion of an operation.  This deducts
-     this operation from the parent object's run state, potentially permitting
-     one or more pending operations to start running.
-
-
  (*) Set highest store limit:
 
 	void fscache_set_store_limit(struct fscache_object *object,