---

yaml
---
r: 188807
b: refs/heads/master
c: 87a6aca
h: refs/heads/master
i:
  188805: 378fd23
  188803: 431a6de
  188799: 349039b
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 2eb645e7b5662da47646f76b41b4141f2c9bf13a
+refs/heads/master: 87a6aca504d65f242589583e04df5e74b5eae1fe

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

@@ -160,7 +160,7 @@ Description:
 		match the driver to the device.  For example:
 		# echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id
 
-What:		/sys/bus/usb/device/.../avoid_reset_quirk
+What:		/sys/bus/usb/device/.../avoid_reset
 Date:		December 2009
 Contact:	Oliver Neukum <oliver@neukum.org>
 Description:

trunk/Documentation/ioctl/ioctl-number.txt

@@ -291,7 +291,6 @@ Code  Seq#(hex)	Include File		Comments
 0x92	00-0F	drivers/usb/mon/mon_bin.c
 0x93	60-7F	linux/auto_fs.h
 0x94	all	fs/btrfs/ioctl.h
-0x97	00-7F	fs/ceph/ioctl.h		Ceph file system
 0x99	00-0F				537-Addinboard driver
 					<mailto:buk@buks.ipn.de>
 0xA0	all	linux/sdp/sdp.h		Industrial Device Project

trunk/Documentation/kobject.txt

@@ -59,56 +59,37 @@ nice to have in other objects.  The C language does not allow for the
 direct expression of inheritance, so other techniques - such as structure
 embedding - must be used.
 
-(As an aside, for those familiar with the kernel linked list implementation,
-this is analogous as to how "list_head" structs are rarely useful on
-their own, but are invariably found embedded in the larger objects of
-interest.)
+So, for example, the UIO code has a structure that defines the memory
+region associated with a uio device:
 
-So, for example, the UIO code in drivers/uio/uio.c has a structure that
-defines the memory region associated with a uio device:
-
-    struct uio_map {
+struct uio_mem {
 	struct kobject kobj;
-	struct uio_mem *mem;
-    };
+	unsigned long addr;
+	unsigned long size;
+	int memtype;
+	void __iomem *internal_addr;
+};
 
-If you have a struct uio_map structure, finding its embedded kobject is
+If you have a struct uio_mem structure, finding its embedded kobject is
 just a matter of using the kobj member.  Code that works with kobjects will
 often have the opposite problem, however: given a struct kobject pointer,
 what is the pointer to the containing structure?  You must avoid tricks
 (such as assuming that the kobject is at the beginning of the structure)
 and, instead, use the container_of() macro, found in <linux/kernel.h>:
 
-    container_of(pointer, type, member)
-
-where:
-
-  * "pointer" is the pointer to the embedded kobject,
-  * "type" is the type of the containing structure, and
-  * "member" is the name of the structure field to which "pointer" points.
-
-The return value from container_of() is a pointer to the corresponding
-container type. So, for example, a pointer "kp" to a struct kobject
-embedded *within* a struct uio_map could be converted to a pointer to the
-*containing* uio_map structure with:
-
-    struct uio_map *u_map = container_of(kp, struct uio_map, kobj);
-
-For convenience, programmers often define a simple macro for "back-casting"
-kobject pointers to the containing type.  Exactly this happens in the
-earlier drivers/uio/uio.c, as you can see here:
-
-    struct uio_map {
-        struct kobject kobj;
-        struct uio_mem *mem;
-    };
+	container_of(pointer, type, member)
 
-    #define to_map(map) container_of(map, struct uio_map, kobj)
+where pointer is the pointer to the embedded kobject, type is the type of
+the containing structure, and member is the name of the structure field to
+which pointer points.  The return value from container_of() is a pointer to
+the given type. So, for example, a pointer "kp" to a struct kobject
+embedded within a struct uio_mem could be converted to a pointer to the
+containing uio_mem structure with:
 
-where the macro argument "map" is a pointer to the struct kobject in
-question.  That macro is subsequently invoked with:
+    struct uio_mem *u_mem = container_of(kp, struct uio_mem, kobj);
 
-    struct uio_map *map = to_map(kobj);
+Programmers often define a simple macro for "back-casting" kobject pointers
+to the containing type.
 
 
 Initialization of kobjects
@@ -406,5 +387,4 @@ called, and the objects in the former circle release each other.
 Example code to copy from
 
 For a more complete example of using ksets and kobjects properly, see the
-example programs samples/kobject/{kobject-example.c,kset-example.c},
-which will be built as loadable modules if you select CONFIG_SAMPLE_KOBJECT.
+sample/kobject/kset-example.c code.

trunk/Documentation/networking/Makefile

@@ -6,5 +6,3 @@ hostprogs-y := ifenslave
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
-
-obj-m := timestamping/

trunk/Documentation/networking/timestamping/Makefile

@@ -1,13 +1,6 @@
-# kbuild trick to avoid linker error. Can be omitted if a module is built.
-obj- := dummy.o
+CPPFLAGS = -I../../../include
 
-# List of programs to build
-hostprogs-y := timestamping
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
-
-HOSTCFLAGS_timestamping.o += -I$(objtree)/usr/include
+timestamping: timestamping.c
 
 clean:
 	rm -f timestamping

trunk/Documentation/networking/timestamping/timestamping.c

@@ -41,9 +41,9 @@
 #include <arpa/inet.h>
 #include <net/if.h>
 
-#include <asm/types.h>
-#include <linux/net_tstamp.h>
-#include <linux/errqueue.h>
+#include "asm/types.h"
+#include "linux/net_tstamp.h"
+#include "linux/errqueue.h"
 
 #ifndef SO_TIMESTAMPING
 # define SO_TIMESTAMPING         37
@@ -164,7 +164,7 @@ static void printpacket(struct msghdr *msg, int res,
 
 	gettimeofday(&now, 0);
 
-	printf("%ld.%06ld: received %s data, %d bytes from %s, %zu bytes control messages\n",
+	printf("%ld.%06ld: received %s data, %d bytes from %s, %d bytes control messages\n",
 	       (long)now.tv_sec, (long)now.tv_usec,
 	       (recvmsg_flags & MSG_ERRQUEUE) ? "error" : "regular",
 	       res,
@@ -173,7 +173,7 @@ static void printpacket(struct msghdr *msg, int res,
 	for (cmsg = CMSG_FIRSTHDR(msg);
 	     cmsg;
 	     cmsg = CMSG_NXTHDR(msg, cmsg)) {
-		printf("   cmsg len %zu: ", cmsg->cmsg_len);
+		printf("   cmsg len %d: ", cmsg->cmsg_len);
 		switch (cmsg->cmsg_level) {
 		case SOL_SOCKET:
 			printf("SOL_SOCKET ");

trunk/MAINTAINERS

@@ -1441,15 +1441,6 @@ F:	arch/powerpc/include/asm/spu*.h
 F:	arch/powerpc/oprofile/*cell*
 F:	arch/powerpc/platforms/cell/
 
-CEPH DISTRIBUTED FILE SYSTEM CLIENT
-M:	Sage Weil <sage@newdream.net>
-L:	ceph-devel@lists.sourceforge.net
-W:	http://ceph.newdream.net/
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git
-S:	Supported
-F:	Documentation/filesystems/ceph.txt
-F:	fs/ceph
-
 CERTIFIED WIRELESS USB (WUSB) SUBSYSTEM:
 M:	David Vrabel <david.vrabel@csr.com>
 L:	linux-usb@vger.kernel.org
@@ -5223,21 +5214,6 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next-2.6.git
 S:	Maintained
 F:	arch/sparc/
 
-SPARC SERIAL DRIVERS
-M:	"David S. Miller" <davem@davemloft.net>
-L:	sparclinux@vger.kernel.org
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6.git
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next-2.6.git
-S:	Maintained
-F:	drivers/serial/suncore.c
-F:	drivers/serial/suncore.h
-F:	drivers/serial/sunhv.c
-F:	drivers/serial/sunsab.c
-F:	drivers/serial/sunsab.h
-F:	drivers/serial/sunsu.c
-F:	drivers/serial/sunzilog.c
-F:	drivers/serial/sunzilog.h
-
 SPECIALIX IO8+ MULTIPORT SERIAL CARD DRIVER
 M:	Roger Wolff <R.E.Wolff@BitWizard.nl>
 S:	Supported