---

yaml
---
r: 303363
b: refs/heads/master
c: 6ba5a69
h: refs/heads/master
i:
  303361: d33af6f
  303359: 6b43915
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 0f8b7137dbf651a0a048c70f3a83a76bca02e18a
+refs/heads/master: 6ba5a69ee92c29c2ffc814dad6ac61c4cd49090c

trunk/Documentation/ABI/stable/sysfs-driver-usb-usbtmc

@@ -1,5 +1,5 @@
-What:		/sys/bus/usb/drivers/usbtmc/*/interface_capabilities
-What:		/sys/bus/usb/drivers/usbtmc/*/device_capabilities
+What:		/sys/bus/usb/drivers/usbtmc/devices/*/interface_capabilities
+What:		/sys/bus/usb/drivers/usbtmc/devices/*/device_capabilities
 Date:		August 2008
 Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
@@ -12,8 +12,8 @@ Description:
 		The files are read only.
 
 
-What:		/sys/bus/usb/drivers/usbtmc/*/usb488_interface_capabilities
-What:		/sys/bus/usb/drivers/usbtmc/*/usb488_device_capabilities
+What:		/sys/bus/usb/drivers/usbtmc/devices/*/usb488_interface_capabilities
+What:		/sys/bus/usb/drivers/usbtmc/devices/*/usb488_device_capabilities
 Date:		August 2008
 Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
@@ -27,7 +27,7 @@ Description:
 		The files are read only.
 
 
-What:		/sys/bus/usb/drivers/usbtmc/*/TermChar
+What:		/sys/bus/usb/drivers/usbtmc/devices/*/TermChar
 Date:		August 2008
 Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
@@ -40,7 +40,7 @@ Description:
 		sent to the device or not.
 
 
-What:		/sys/bus/usb/drivers/usbtmc/*/TermCharEnabled
+What:		/sys/bus/usb/drivers/usbtmc/devices/*/TermCharEnabled
 Date:		August 2008
 Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
@@ -51,7 +51,7 @@ Description:
 		published by the USB-IF.
 
 
-What:		/sys/bus/usb/drivers/usbtmc/*/auto_abort
+What:		/sys/bus/usb/drivers/usbtmc/devices/*/auto_abort
 Date:		August 2008
 Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:

trunk/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml

@@ -1,6 +1,6 @@
     <refentry id="V4L2-PIX-FMT-NV12M">
       <refmeta>
-	<refentrytitle>V4L2_PIX_FMT_NV12M ('NM12')</refentrytitle>
+	<refentrytitle>V4L2_PIX_FMT_NV12M ('NV12M')</refentrytitle>
 	&manvol;
       </refmeta>
       <refnamediv>

trunk/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml

@@ -1,6 +1,6 @@
     <refentry id="V4L2-PIX-FMT-YUV420M">
       <refmeta>
-	<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12')</refentrytitle>
+	<refentrytitle>V4L2_PIX_FMT_YUV420M ('YU12M')</refentrytitle>
 	&manvol;
       </refmeta>
       <refnamediv>

trunk/Documentation/cgroups/memory.txt

@@ -34,7 +34,8 @@ Current Status: linux-2.6.34-mmotm(development version of 2010/April)
 
 Features:
  - accounting anonymous pages, file caches, swap caches usage and limiting them.
- - pages are linked to per-memcg LRU exclusively, and there is no global LRU.
+ - private LRU and reclaim routine. (system's global LRU and private LRU
+   work independently from each other)
  - optionally, memory+swap usage can be accounted and limited.
  - hierarchical accounting
  - soft limit
@@ -153,7 +154,7 @@ updated. page_cgroup has its own LRU on cgroup.
 2.2.1 Accounting details
 
 All mapped anon pages (RSS) and cache pages (Page Cache) are accounted.
-Some pages which are never reclaimable and will not be on the LRU
+Some pages which are never reclaimable and will not be on the global LRU
 are not accounted. We just account pages under usual VM management.
 
 RSS pages are accounted at page_fault unless they've already been accounted

trunk/Documentation/feature-removal-schedule.txt

@@ -531,11 +531,3 @@ Why:	There appear to be no production users of the get_robust_list syscall,
 	of ASLR. It was only ever intended for debugging, so it should be
 	removed.
 Who:	Kees Cook <keescook@chromium.org>
-
-----------------------------
-
-What:	setitimer accepts user NULL pointer (value)
-When:	3.6
-Why:	setitimer is not returning -EFAULT if user pointer is NULL. This
-	violates the spec.
-Who:	Sasikantha Babu <sasikanth.v19@gmail.com>

trunk/Documentation/filesystems/vfs.txt

@@ -114,7 +114,7 @@ members are defined:
 struct file_system_type {
 	const char *name;
 	int fs_flags;
-        struct dentry *(*mount) (struct file_system_type *, int,
+        struct dentry (*mount) (struct file_system_type *, int,
                        const char *, void *);
         void (*kill_sb) (struct super_block *);
         struct module *owner;

trunk/Documentation/power/freezing-of-tasks.txt

@@ -9,39 +9,38 @@ architectures).
 
 II. How does it work?
 
-There are three per-task flags used for that, PF_NOFREEZE, PF_FROZEN
+There are four per-task flags used for that, PF_NOFREEZE, PF_FROZEN, TIF_FREEZE
 and PF_FREEZER_SKIP (the last one is auxiliary).  The tasks that have
 PF_NOFREEZE unset (all user space processes and some kernel threads) are
 regarded as 'freezable' and treated in a special way before the system enters a
 suspend state as well as before a hibernation image is created (in what follows
 we only consider hibernation, but the description also applies to suspend).
 
 Namely, as the first step of the hibernation procedure the function
-freeze_processes() (defined in kernel/power/process.c) is called.  A system-wide
-variable system_freezing_cnt (as opposed to a per-task flag) is used to indicate
-whether the system is to undergo a freezing operation. And freeze_processes()
-sets this variable.  After this, it executes try_to_freeze_tasks() that sends a
-fake signal to all user space processes, and wakes up all the kernel threads.
-All freezable tasks must react to that by calling try_to_freeze(), which
-results in a call to __refrigerator() (defined in kernel/freezer.c), which sets
-the task's PF_FROZEN flag, changes its state to TASK_UNINTERRUPTIBLE and makes
-it loop until PF_FROZEN is cleared for it. Then, we say that the task is
-'frozen' and therefore the set of functions handling this mechanism is referred
-to as 'the freezer' (these functions are defined in kernel/power/process.c,
-kernel/freezer.c & include/linux/freezer.h). User space processes are generally
-frozen before kernel threads.
+freeze_processes() (defined in kernel/power/process.c) is called.  It executes
+try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and
+either wakes them up, if they are kernel threads, or sends fake signals to them,
+if they are user space processes.  A task that has TIF_FREEZE set, should react
+to it by calling the function called __refrigerator() (defined in
+kernel/freezer.c), which sets the task's PF_FROZEN flag, changes its state
+to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is cleared for it.
+Then, we say that the task is 'frozen' and therefore the set of functions
+handling this mechanism is referred to as 'the freezer' (these functions are
+defined in kernel/power/process.c, kernel/freezer.c & include/linux/freezer.h).
+User space processes are generally frozen before kernel threads.
 
 __refrigerator() must not be called directly.  Instead, use the
 try_to_freeze() function (defined in include/linux/freezer.h), that checks
-if the task is to be frozen and makes the task enter __refrigerator().
+the task's TIF_FREEZE flag and makes the task enter __refrigerator() if the
+flag is set.
 
 For user space processes try_to_freeze() is called automatically from the
 signal-handling code, but the freezable kernel threads need to call it
 explicitly in suitable places or use the wait_event_freezable() or
 wait_event_freezable_timeout() macros (defined in include/linux/freezer.h)
-that combine interruptible sleep with checking if the task is to be frozen and
-calling try_to_freeze().  The main loop of a freezable kernel thread may look
-like the following one:
+that combine interruptible sleep with checking if TIF_FREEZE is set and calling
+try_to_freeze().  The main loop of a freezable kernel thread may look like the
+following one:
 
 	set_freezable();
 	do {
@@ -54,7 +53,7 @@ like the following one:
 (from drivers/usb/core/hub.c::hub_thread()).
 
 If a freezable kernel thread fails to call try_to_freeze() after the freezer has
-initiated a freezing operation, the freezing of tasks will fail and the entire
+set TIF_FREEZE for it, the freezing of tasks will fail and the entire
 hibernation operation will be cancelled.  For this reason, freezable kernel
 threads must call try_to_freeze() somewhere or use one of the
 wait_event_freezable() and wait_event_freezable_timeout() macros.

trunk/Documentation/security/keys.txt

@@ -123,7 +123,7 @@ KEY SERVICE OVERVIEW
 
 The key service provides a number of features besides keys:
 
- (*) The key service defines three special key types:
+ (*) The key service defines two special key types:
 
      (+) "keyring"
 
@@ -137,18 +137,6 @@ The key service provides a number of features besides keys:
 	 blobs of data. These can be created, updated and read by userspace,
 	 and aren't intended for use by kernel services.
 
-     (+) "logon"
-
-	 Like a "user" key, a "logon" key has a payload that is an arbitrary
-	 blob of data. It is intended as a place to store secrets which are
-	 accessible to the kernel but not to userspace programs.
-
-	 The description can be arbitrary, but must be prefixed with a non-zero
-	 length string that describes the key "subclass". The subclass is
-	 separated from the rest of the description by a ':'. "logon" keys can
-	 be created and updated from userspace, but the payload is only
-	 readable from kernel space.
-
  (*) Each process subscribes to three keyrings: a thread-specific keyring, a
      process-specific keyring, and a session-specific keyring.
 

trunk/Documentation/sound/alsa/HD-Audio-Models.txt

@@ -43,9 +43,7 @@ ALC680
 
 ALC882/883/885/888/889
 ======================
-  acer-aspire-4930g	Acer Aspire 4930G/5930G/6530G/6930G/7730G
-  acer-aspire-8930g	Acer Aspire 8330G/6935G
-  acer-aspire		Acer Aspire others
+  N/A
 
 ALC861/660
 ==========

trunk/Documentation/usb/URB.txt

@@ -168,28 +168,6 @@ that if the completion handler or anyone else tries to resubmit it
 they will get a -EPERM error.  Thus you can be sure that when
 usb_kill_urb() returns, the URB is totally idle.
 
-There is a lifetime issue to consider.  An URB may complete at any
-time, and the completion handler may free the URB.  If this happens
-while usb_unlink_urb or usb_kill_urb is running, it will cause a
-memory-access violation.  The driver is responsible for avoiding this,
-which often means some sort of lock will be needed to prevent the URB
-from being deallocated while it is still in use.
-
-On the other hand, since usb_unlink_urb may end up calling the
-completion handler, the handler must not take any lock that is held
-when usb_unlink_urb is invoked.  The general solution to this problem
-is to increment the URB's reference count while holding the lock, then
-drop the lock and call usb_unlink_urb or usb_kill_urb, and then
-decrement the URB's reference count.  You increment the reference
-count by calling
-
-	struct urb *usb_get_urb(struct urb *urb)
-
-(ignore the return value; it is the same as the argument) and
-decrement the reference count by calling usb_free_urb.  Of course,
-none of this is necessary if there's no danger of the URB being freed
-by the completion handler.
-
 
 1.7. What about the completion handler?
 

trunk/Documentation/usb/usbmon.txt

@@ -183,10 +183,10 @@ An input control transfer to get a port status.
 d5ea89a0 3575914555 S Ci:1:001:0 s a3 00 0000 0003 0004 4 <
 d5ea89a0 3575914560 C Ci:1:001:0 0 4 = 01050000
 
-An output bulk transfer to send a SCSI command 0x28 (READ_10) in a 31-byte
-Bulk wrapper to a storage device at address 5:
+An output bulk transfer to send a SCSI command 0x5E in a 31-byte Bulk wrapper
+to a storage device at address 5:
 
-dd65f0e8 4128379752 S Bo:1:005:2 -115 31 = 55534243 ad000000 00800000 80010a28 20000000 20000040 00000000 000000
+dd65f0e8 4128379752 S Bo:1:005:2 -115 31 = 55534243 5e000000 00000000 00000600 00000000 00000000 00000000 000000
 dd65f0e8 4128379808 C Bo:1:005:2 0 31 >
 
 * Raw binary format and API