---

yaml
---
r: 215444
b: refs/heads/master
c: 0abee52
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: a5190b4eea1f1c53ee26b3d1176441cafa8e7f79
+refs/heads/master: 0abee5260babe0a12d468b485a28336551697925

trunk/CREDITS

@@ -3554,12 +3554,12 @@ E: cvance@nai.com
 D: portions of the Linux Security Module (LSM) framework and security modules
 
 N: Petr Vandrovec
-E: petr@vandrovec.name
+E: vandrove@vc.cvut.cz
 D: Small contributions to ncpfs
 D: Matrox framebuffer driver
-S: 21513 Conradia Ct
-S: Cupertino, CA 95014
-S: USA
+S: Chudenicka 8
+S: 10200 Prague 10, Hostivar
+S: Czech Republic
 
 N: Thibaut Varene
 E: T-Bone@parisc-linux.org

trunk/Documentation/DocBook/device-drivers.tmpl

@@ -46,6 +46,7 @@
 
      <sect1><title>Atomic and pointer manipulation</title>
 !Iarch/x86/include/asm/atomic.h
+!Iarch/x86/include/asm/unaligned.h
      </sect1>
 
      <sect1><title>Delaying, scheduling, and timer routines</title>

trunk/Documentation/DocBook/kernel-api.tmpl

@@ -57,6 +57,7 @@
      </para>
 
      <sect1><title>String Conversions</title>
+!Ilib/vsprintf.c
 !Elib/vsprintf.c
      </sect1>
      <sect1><title>String Manipulation</title>

trunk/Documentation/DocBook/kernel-locking.tmpl

@@ -1961,12 +1961,6 @@ machines due to caching.
    </sect1>
   </chapter>
 
-  <chapter id="apiref">
-   <title>Mutex API reference</title>
-!Iinclude/linux/mutex.h
-!Ekernel/mutex.c
-  </chapter>
-
   <chapter id="references">
    <title>Further reading</title>
 

trunk/Documentation/cgroups/blkio-controller.txt

@@ -217,7 +217,6 @@ Details of cgroup files
 CFQ sysfs tunable
 =================
 /sys/block/<disk>/queue/iosched/group_isolation
------------------------------------------------
 
 If group_isolation=1, it provides stronger isolation between groups at the
 expense of throughput. By default group_isolation is 0. In general that
@@ -244,33 +243,6 @@ By default one should run with group_isolation=0. If that is not sufficient
 and one wants stronger isolation between groups, then set group_isolation=1
 but this will come at cost of reduced throughput.
 
-/sys/block/<disk>/queue/iosched/slice_idle
-------------------------------------------
-On a faster hardware CFQ can be slow, especially with sequential workload.
-This happens because CFQ idles on a single queue and single queue might not
-drive deeper request queue depths to keep the storage busy. In such scenarios
-one can try setting slice_idle=0 and that would switch CFQ to IOPS
-(IO operations per second) mode on NCQ supporting hardware.
-
-That means CFQ will not idle between cfq queues of a cfq group and hence be
-able to driver higher queue depth and achieve better throughput. That also
-means that cfq provides fairness among groups in terms of IOPS and not in
-terms of disk time.
-
-/sys/block/<disk>/queue/iosched/group_idle
-------------------------------------------
-If one disables idling on individual cfq queues and cfq service trees by
-setting slice_idle=0, group_idle kicks in. That means CFQ will still idle
-on the group in an attempt to provide fairness among groups.
-
-By default group_idle is same as slice_idle and does not do anything if
-slice_idle is enabled.
-
-One can experience an overall throughput drop if you have created multiple
-groups and put applications in that group which are not driving enough
-IO to keep disk busy. In that case set group_idle=0, and CFQ will not idle
-on individual groups and throughput should improve.
-
 What works
 ==========
 - Currently only sync IO queues are support. All the buffered writes are

trunk/Documentation/feature-removal-schedule.txt

@@ -564,12 +564,3 @@ Who:	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
 
 ----------------------------
 
-What:	iwlwifi disable_hw_scan module parameters
-When:	2.6.40
-Why:	Hareware scan is the prefer method for iwlwifi devices for
-	scanning operation. Remove software scan support for all the
-	iwlwifi devices.
-
-Who:	Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
-----------------------------

trunk/Documentation/gpio.txt

@@ -109,19 +109,17 @@ use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
 
 If you want to initialize a structure with an invalid GPIO number, use
 some negative number (perhaps "-EINVAL"); that will never be valid.  To
-test if such number from such a structure could reference a GPIO, you
-may use this predicate:
+test if a number could reference a GPIO, you may use this predicate:
 
 	int gpio_is_valid(int number);
 
 A number that's not valid will be rejected by calls which may request
 or free GPIOs (see below).  Other numbers may also be rejected; for
-example, a number might be valid but temporarily unused on a given board.
+example, a number might be valid but unused on a given board.
+
+Whether a platform supports multiple GPIO controllers is currently a
+platform-specific implementation issue.
 
-Whether a platform supports multiple GPIO controllers is a platform-specific
-implementation issue, as are whether that support can leave "holes" in the space
-of GPIO numbers, and whether new controllers can be added at runtime.  Such issues
-can affect things including whether adjacent GPIO numbers are both valid.
 
 Using GPIOs
 -----------
@@ -482,16 +480,12 @@ To support this framework, a platform's Kconfig will "select" either
 ARCH_REQUIRE_GPIOLIB or ARCH_WANT_OPTIONAL_GPIOLIB
 and arrange that its <asm/gpio.h> includes <asm-generic/gpio.h> and defines
 three functions: gpio_get_value(), gpio_set_value(), and gpio_cansleep().
+They may also want to provide a custom value for ARCH_NR_GPIOS.
 
-It may also provide a custom value for ARCH_NR_GPIOS, so that it better
-reflects the number of GPIOs in actual use on that platform, without
-wasting static table space.  (It should count both built-in/SoC GPIOs and
-also ones on GPIO expanders.
-
-ARCH_REQUIRE_GPIOLIB means that the gpiolib code will always get compiled
+ARCH_REQUIRE_GPIOLIB means that the gpio-lib code will always get compiled
 into the kernel on that architecture.
 
-ARCH_WANT_OPTIONAL_GPIOLIB means the gpiolib code defaults to off and the user
+ARCH_WANT_OPTIONAL_GPIOLIB means the gpio-lib code defaults to off and the user
 can enable it and build it into the kernel optionally.
 
 If neither of these options are selected, the platform does not support

trunk/Documentation/hwmon/sysfs-interface

@@ -91,11 +91,12 @@ name		The chip name.
 		I2C devices get this attribute created automatically.
 		RO
 
-update_interval	The interval at which the chip will update readings.
+update_rate	The rate at which the chip will update readings.
 		Unit: millisecond
 		RW
-		Some devices have a variable update rate or interval.
-		This attribute can be used to change it to the desired value.
+		Some devices have a variable update rate. This attribute
+		can be used to change the update rate to the desired
+		frequency.
 
 
 ************

trunk/Documentation/kernel-doc-nano-HOWTO.txt

@@ -345,10 +345,5 @@ documentation, in <filename>, for the functions listed.
 section titled <section title> from <filename>.
 Spaces are allowed in <section title>; do not quote the <section title>.
 
-!C<filename> is replaced by nothing, but makes the tools check that
-all DOC: sections and documented functions, symbols, etc. are used.
-This makes sense to use when you use !F/!P only and want to verify
-that all documentation is included.
-
 Tim.
 */ <twaugh@redhat.com>

trunk/Documentation/mutex-design.txt

@@ -9,7 +9,7 @@ firstly, there's nothing wrong with semaphores. But if the simpler
 mutex semantics are sufficient for your code, then there are a couple
 of advantages of mutexes:
 
- - 'struct mutex' is smaller on most architectures: E.g. on x86,
+ - 'struct mutex' is smaller on most architectures: .e.g on x86,
    'struct semaphore' is 20 bytes, 'struct mutex' is 16 bytes.
    A smaller structure size means less RAM footprint, and better
    CPU-cache utilization.
@@ -136,4 +136,3 @@ the APIs of 'struct mutex' have been streamlined:
  void mutex_lock_nested(struct mutex *lock, unsigned int subclass);
  int  mutex_lock_interruptible_nested(struct mutex *lock,
                                       unsigned int subclass);
- int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock);

trunk/Documentation/networking/bonding.txt

@@ -765,14 +765,6 @@ xmit_hash_policy
 	does not exist, and the layer2 policy is the only policy.  The
 	layer2+3 value was added for bonding version 3.2.2.
 
-resend_igmp
-
-	Specifies the number of IGMP membership reports to be issued after
-	a failover event. One membership report is issued immediately after
-	the failover, subsequent packets are sent in each 200ms interval.
-
-	The valid range is 0 - 255; the default value is 1. This option
-	was added for bonding version 3.7.0.
 
 3. Configuring Bonding Devices
 ==============================

trunk/Documentation/networking/can.txt

@@ -22,7 +22,6 @@ This file contains
       4.1.2 RAW socket option CAN_RAW_ERR_FILTER
       4.1.3 RAW socket option CAN_RAW_LOOPBACK
       4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
-      4.1.5 RAW socket returned message flags
     4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
     4.3 connected transport protocols (SOCK_SEQPACKET)
     4.4 unconnected transport protocols (SOCK_DGRAM)
@@ -472,17 +471,6 @@ solution for a couple of reasons:
     setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
                &recv_own_msgs, sizeof(recv_own_msgs));
 
-  4.1.5 RAW socket returned message flags
-
-  When using recvmsg() call, the msg->msg_flags may contain following flags:
-
-    MSG_DONTROUTE: set when the received frame was created on the local host.
-
-    MSG_CONFIRM: set when the frame was sent via the socket it is received on.
-      This flag can be interpreted as a 'transmission confirmation' when the
-      CAN driver supports the echo of frames on driver level, see 3.2 and 6.2.
-      In order to receive such messages, CAN_RAW_RECV_OWN_MSGS must be set.
-
   4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
   4.3 connected transport protocols (SOCK_SEQPACKET)
   4.4 unconnected transport protocols (SOCK_DGRAM)