---

yaml
---
r: 231769
b: refs/heads/master
c: 948579c
h: refs/heads/master
i:
  231767: f768c0a
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: eee2a817df7c5a6e569f353f8be78cc1b3604bb6
+refs/heads/master: 948579cd8c6ea7c8c98c52b79f4470952e182ebd

trunk/CREDITS

@@ -2811,8 +2811,8 @@ D: CDROM driver "sonycd535" (Sony CDU-535/531)
 N: Stelian Pop
 E: stelian@popies.net
 P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0  D3F7 7185 9E7A EDBB 6147
-D: random kernel hacks
-S: Paimpont, France
+D: sonypi, meye drivers, mct_u232 usb serial hacks
+S: Paris, France
 
 N: Pete Popov
 E: pete_popov@yahoo.com

trunk/Documentation/ABI/testing/sysfs-class-led

@@ -26,12 +26,3 @@ Description:
 		scheduler is chosen. Trigger specific parameters can appear in
 		/sys/class/leds/<led> once a given trigger is selected.
 
-What:		/sys/class/leds/<led>/inverted
-Date:		January 2011
-KernelVersion:	2.6.38
-Contact:	Richard Purdie <rpurdie@rpsys.net>
-Description:
-		Invert the LED on/off state. This parameter is specific to
-		gpio and backlight triggers. In case of the backlight trigger,
-		it is usefull when driving a LED which is intended to indicate
-		a device in a standby like state.

trunk/Documentation/DocBook/80211.tmpl

@@ -268,6 +268,10 @@
 !Finclude/net/mac80211.h ieee80211_ops
 !Finclude/net/mac80211.h ieee80211_alloc_hw
 !Finclude/net/mac80211.h ieee80211_register_hw
+!Finclude/net/mac80211.h ieee80211_get_tx_led_name
+!Finclude/net/mac80211.h ieee80211_get_rx_led_name
+!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
+!Finclude/net/mac80211.h ieee80211_get_radio_led_name
 !Finclude/net/mac80211.h ieee80211_unregister_hw
 !Finclude/net/mac80211.h ieee80211_free_hw
       </chapter>
@@ -378,23 +382,6 @@
         </para>
       </partintro>
 
-      <chapter id="led-support">
-        <title>LED support</title>
-        <para>
-         Mac80211 supports various ways of blinking LEDs. Wherever possible,
-         device LEDs should be exposed as LED class devices and hooked up to
-         the appropriate trigger, which will then be triggered appropriately
-         by mac80211.
-        </para>
-!Finclude/net/mac80211.h ieee80211_get_tx_led_name
-!Finclude/net/mac80211.h ieee80211_get_rx_led_name
-!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
-!Finclude/net/mac80211.h ieee80211_get_radio_led_name
-!Finclude/net/mac80211.h ieee80211_tpt_blink
-!Finclude/net/mac80211.h ieee80211_tpt_led_trigger_flags
-!Finclude/net/mac80211.h ieee80211_create_tpt_led_trigger
-      </chapter>
-
       <chapter id="hardware-crypto-offload">
         <title>Hardware crypto acceleration</title>
 !Pinclude/net/mac80211.h Hardware crypto acceleration

trunk/Documentation/DocBook/mtdnand.tmpl

@@ -250,7 +250,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd)
 		<title>Device ready function</title>
 		<para>
 			If the hardware interface has the ready busy pin of the NAND chip connected to a
-			GPIO or other accessible I/O pin, this function is used to read back the state of the
+			GPIO or other accesible I/O pin, this function is used to read back the state of the
 			pin. The function has no arguments and should return 0, if the device is busy (R/B pin 
 			is low) and 1, if the device is ready (R/B pin is high).
 			If the hardware interface does not give access to the ready busy pin, then

trunk/Documentation/IPMI.txt

@@ -533,33 +533,6 @@ completion during sending a panic event.
 Other Pieces
 ------------
 
-Get the detailed info related with the IPMI device
---------------------------------------------------
-
-Some users need more detailed information about a device, like where
-the address came from or the raw base device for the IPMI interface.
-You can use the IPMI smi_watcher to catch the IPMI interfaces as they
-come or go, and to grab the information, you can use the function
-ipmi_get_smi_info(), which returns the following structure:
-
-struct ipmi_smi_info {
-	enum ipmi_addr_src addr_src;
-	struct device *dev;
-	union {
-		struct {
-			void *acpi_handle;
-		} acpi_info;
-	} addr_info;
-};
-
-Currently special info for only for SI_ACPI address sources is
-returned.  Others may be added as necessary.
-
-Note that the dev pointer is included in the above structure, and
-assuming ipmi_smi_get_info returns success, you must call put_device
-on the dev pointer.
-
-
 Watchdog
 --------
 

trunk/Documentation/cgroups/blkio-controller.txt

@@ -89,33 +89,6 @@ Throttling/Upper Limit policy
 
  Limits for writes can be put using blkio.write_bps_device file.
 
-Hierarchical Cgroups
-====================
-- Currently none of the IO control policy supports hierarhical groups. But
-  cgroup interface does allow creation of hierarhical cgroups and internally
-  IO policies treat them as flat hierarchy.
-
-  So this patch will allow creation of cgroup hierarhcy but at the backend
-  everything will be treated as flat. So if somebody created a hierarchy like
-  as follows.
-
-			root
-			/  \
-		     test1 test2
-			|
-		     test3
-
-  CFQ and throttling will practically treat all groups at same level.
-
-				pivot
-			     /  |   \  \
-			root  test1 test2  test3
-
-  Down the line we can implement hierarchical accounting/control support
-  and also introduce a new cgroup file "use_hierarchy" which will control
-  whether cgroup hierarchy is viewed as flat or hierarchical by the policy..
-  This is how memory controller also has implemented the things.
-
 Various user visible config options
 ===================================
 CONFIG_BLK_CGROUP

trunk/Documentation/cgroups/cgroup_event_listener.c

@@ -91,7 +91,7 @@ int main(int argc, char **argv)
 
 		if (ret == -1) {
 			perror("cgroup.event_control "
-					"is not accessible any more");
+					"is not accessable any more");
 			break;
 		}
 

trunk/Documentation/cgroups/cgroups.txt

@@ -355,13 +355,13 @@ subsystems, type:
 
 To change the set of subsystems bound to a mounted hierarchy, just
 remount with different options:
-# mount -o remount,cpuset,blkio hier1 /dev/cgroup
+# mount -o remount,cpuset,ns hier1 /dev/cgroup
 
-Now memory is removed from the hierarchy and blkio is added.
+Now memory is removed from the hierarchy and ns is added.
 
-Note this will add blkio to the hierarchy but won't remove memory or
+Note this will add ns to the hierarchy but won't remove memory or
 cpuset, because the new options are appended to the old ones:
-# mount -o remount,blkio /dev/cgroup
+# mount -o remount,ns /dev/cgroup
 
 To Specify a hierarchy's release_agent:
 # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \

trunk/Documentation/cgroups/memcg_test.txt

@@ -398,7 +398,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
 	written to move_charge_at_immigrate.
 
  9.10 Memory thresholds
-	Memory controller implements memory thresholds using cgroups notification
+	Memory controler implements memory thresholds using cgroups notification
 	API. You can use Documentation/cgroups/cgroup_event_listener.c to test
 	it.
 

trunk/Documentation/device-mapper/dm-crypt.txt

@@ -8,7 +8,7 @@ Parameters: <cipher> <key> <iv_offset> <device path> <offset>
 
 <cipher>
     Encryption cipher and an optional IV generation mode.
-    (In format cipher[:keycount]-chainmode-ivopts:ivmode).
+    (In format cipher-chainmode-ivopts:ivmode).
     Examples:
        des
        aes-cbc-essiv:sha256
@@ -20,11 +20,6 @@ Parameters: <cipher> <key> <iv_offset> <device path> <offset>
     Key used for encryption. It is encoded as a hexadecimal number.
     You can only use key sizes that are valid for the selected cipher.
 
-<keycount>
-    Multi-key compatibility mode. You can define <keycount> keys and
-    then sectors are encrypted according to their offsets (sector 0 uses key0;
-    sector 1 uses key1 etc.).  <keycount> must be a power of two.
-
 <iv_offset>
     The IV offset is a sector count that is added to the sector number
     before creating the IV.