---

yaml
---
r: 336548
b: refs/heads/master
c: 2066306
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 259cdbee2094d28b72f0f3d77bc9203d682994ff
+refs/heads/master: 2066306099d35430d01ed1b3d81c0536d77bf390

trunk/CREDITS

@@ -1823,11 +1823,6 @@ S: Kattreinstr 38
 S: D-64295
 S: Germany
 
-N: Avi Kivity
-E: avi.kivity@gmail.com
-D: Kernel-based Virtual Machine (KVM)
-S: Ra'annana, Israel
-
 N: Andi Kleen
 E: andi@firstfloor.org
 U: http://www.halobates.de

trunk/Documentation/00-INDEX

@@ -210,8 +210,6 @@ local_ops.txt
 	- semantics and behavior of local atomic operations.
 lockdep-design.txt
 	- documentation on the runtime locking correctness validator.
-lockup-watchdogs.txt
-	- info on soft and hard lockup detectors (aka nmi_watchdog).
 logo.gif
 	- full colour GIF image of Linux logo (penguin - Tux).
 logo.txt
@@ -242,6 +240,8 @@ netlabel/
 	- directory with information on the NetLabel subsystem.
 networking/
 	- directory with info on various aspects of networking with Linux.
+nmi_watchdog.txt
+	- info on NMI watchdog for SMP systems.
 nommu-mmap.txt
 	- documentation about no-mmu memory mapping support.
 numastat.txt

trunk/Documentation/IRQ-domain.txt

@@ -7,21 +7,6 @@ systems with multiple interrupt controllers the kernel must ensure
 that each one gets assigned non-overlapping allocations of Linux
 IRQ numbers.
 
-The number of interrupt controllers registered as unique irqchips
-show a rising tendency: for example subdrivers of different kinds
-such as GPIO controllers avoid reimplementing identical callback
-mechanisms as the IRQ core system by modelling their interrupt
-handlers as irqchips, i.e. in effect cascading interrupt controllers.
-
-Here the interrupt number loose all kind of correspondence to
-hardware interrupt numbers: whereas in the past, IRQ numbers could
-be chosen so they matched the hardware IRQ line into the root
-interrupt controller (i.e. the component actually fireing the
-interrupt line to the CPU) nowadays this number is just a number.
-
-For this reason we need a mechanism to separate controller-local
-interrupt numbers, called hardware irq's, from Linux IRQ numbers.
-
 The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of
 irq numbers, but they don't provide any support for reverse mapping of
 the controller-local IRQ (hwirq) number into the Linux IRQ number
@@ -55,10 +40,6 @@ required hardware setup.
 When an interrupt is received, irq_find_mapping() function should
 be used to find the Linux IRQ number from the hwirq number.
 
-The irq_create_mapping() function must be called *atleast once*
-before any call to irq_find_mapping(), lest the descriptor will not
-be allocated.
-
 If the driver has the Linux IRQ number or the irq_data pointer, and
 needs to know the associated hwirq number (such as in the irq_chip
 callbacks) then it can be directly obtained from irq_data->hwirq.
@@ -138,17 +119,4 @@ numbers.
 
 Most users of legacy mappings should use irq_domain_add_simple() which
 will use a legacy domain only if an IRQ range is supplied by the
-system and will otherwise use a linear domain mapping. The semantics
-of this call are such that if an IRQ range is specified then
-descriptors will be allocated on-the-fly for it, and if no range is
-specified it will fall through to irq_domain_add_linear() which meand
-*no* irq descriptors will be allocated.
-
-A typical use case for simple domains is where an irqchip provider
-is supporting both dynamic and static IRQ assignments.
-
-In order to avoid ending up in a situation where a linear domain is
-used and no descriptor gets allocated it is very important to make sure
-that the driver using the simple domain call irq_create_mapping()
-before any irq_find_mapping() since the latter will actually work
-for the static IRQ assignment case.
+system and will otherwise use a linear domain mapping.

trunk/Documentation/arm64/memory.txt

@@ -27,17 +27,17 @@ Start			End			Size		Use
 -----------------------------------------------------------------------
 0000000000000000	0000007fffffffff	 512GB		user
 
-ffffff8000000000	ffffffbbfffeffff	~240GB		vmalloc
+ffffff8000000000	ffffffbbfffcffff	~240GB		vmalloc
 
-ffffffbbffff0000	ffffffbbffffffff	  64KB		[guard page]
+ffffffbbfffd0000	ffffffbcfffdffff	  64KB		[guard page]
 
-ffffffbc00000000	ffffffbdffffffff	   8GB		vmemmap
+ffffffbbfffe0000	ffffffbcfffeffff	  64KB		PCI I/O space
 
-ffffffbe00000000	ffffffbffbbfffff	  ~8GB		[guard, future vmmemap]
+ffffffbbffff0000	ffffffbcffffffff	  64KB		[guard page]
 
-ffffffbffbe00000	ffffffbffbe0ffff	  64KB		PCI I/O space
+ffffffbc00000000	ffffffbdffffffff	   8GB		vmemmap
 
-ffffffbbffff0000	ffffffbcffffffff	  ~2MB		[guard]
+ffffffbe00000000	ffffffbffbffffff	  ~8GB		[guard, future vmmemap]
 
 ffffffbffc000000	ffffffbfffffffff	  64MB		modules
 

trunk/Documentation/cgroups/memory.txt

@@ -466,10 +466,6 @@ Note:
 5.3 swappiness
 
 Similar to /proc/sys/vm/swappiness, but affecting a hierarchy of groups only.
-Please note that unlike the global swappiness, memcg knob set to 0
-really prevents from any swapping even if there is a swap storage
-available. This might lead to memcg OOM killer if there are no file
-pages to reclaim.
 
 Following cgroups' swappiness can't be changed.
 - root cgroup (uses /proc/sys/vm/swappiness).

trunk/Documentation/devicetree/bindings/arm/atmel-at91.txt

@@ -7,14 +7,8 @@ PIT Timer required properties:
 - interrupts: Should contain interrupt for the PIT which is the IRQ line
   shared across all System Controller members.
 
-System Timer (ST) required properties:
-- compatible: Should be "atmel,at91rm9200-st"
-- reg: Should contain registers location and length
-- interrupts: Should contain interrupt for the ST which is the IRQ line
-  shared across all System Controller members.
-
 TC/TCLIB Timer required properties:
-- compatible: Should be "atmel,<chip>-tcb".
+- compatible: Should be "atmel,<chip>-pit".
   <chip> can be "at91rm9200" or "at91sam9x5"
 - reg: Should contain registers location and length
 - interrupts: Should contain all interrupts for the TC block

trunk/Documentation/devicetree/bindings/arm/l2cc.txt

@@ -37,7 +37,7 @@ L2: cache-controller {
         reg = <0xfff12000 0x1000>;
         arm,data-latency = <1 1 1>;
         arm,tag-latency = <2 2 2>;
-        arm,filter-latency = <0x80000000 0x8000000>;
+        arm,filter-ranges = <0x80000000 0x8000000>;
         cache-unified;
         cache-level = <2>;
 	interrupts = <45>;

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

@@ -52,7 +52,7 @@ clocks and IDs.
 	lcdif		38
 	etm		39
 	usb		40
-	usb_phy		41
+	usb_pwr		41
 
 Examples:
 

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

@@ -73,8 +73,8 @@ clocks and IDs.
 	can1		59
 	usb0		60
 	usb1		61
-	usb0_phy	62
-	usb1_phy	63
+	usb0_pwr	62
+	usb1_pwr	63
 	enet_out	64
 
 Examples:

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

@@ -75,40 +75,4 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
 		gpio-controller;
 	};
 
-2.1) gpio-controller and pinctrl subsystem
-------------------------------------------
 
-gpio-controller on a SOC might be tightly coupled with the pinctrl
-subsystem, in the sense that the pins can be used by other functions
-together with optional gpio feature.
-
-While the pin allocation is totally managed by the pin ctrl subsystem,
-gpio (under gpiolib) is still maintained by gpio drivers. It may happen
-that different pin ranges in a SoC is managed by different gpio drivers.
-
-This makes it logical to let gpio drivers announce their pin ranges to
-the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to
-request the corresponding pin before any gpio usage.
-
-For this, the gpio controller can use a pinctrl phandle and pins to
-announce the pinrange to the pin ctrl subsystem. For example,
-
-	qe_pio_e: gpio-controller@1460 {
-		#gpio-cells = <2>;
-		compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
-		reg = <0x1460 0x18>;
-		gpio-controller;
-		gpio-ranges = <&pinctrl1 20 10>, <&pinctrl2 50 20>;
-
-    }
-
-where,
-   &pinctrl1 and &pinctrl2 is the phandle to the pinctrl DT node.
-
-   Next values specify the base pin and number of pins for the range
-   handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
-   pin 29 under pinctrl1 and pin 50 to pin 69 under pinctrl2 is handled
-   by this gpio controller.
-
-The pinctrl node must have "#gpio-range-cells" property to show number of
-arguments to pass with phandle from gpio controllers node.

trunk/Documentation/devicetree/bindings/gpio/gpio_atmel.txt

@@ -9,17 +9,12 @@ Required properties:
   unused).
 - gpio-controller: Marks the device node as a GPIO controller.
 
-optional properties:
-- #gpio-lines: Number of gpio if absent 32.
-
-
 Example:
 	pioA: gpio@fffff200 {
 		compatible = "atmel,at91rm9200-gpio";
 		reg = <0xfffff200 0x100>;
 		interrupts = <2 4>;
 		#gpio-cells = <2>;
 		gpio-controller;
-		#gpio-lines = <19>;
 	};
 

trunk/Documentation/devicetree/bindings/mmc/mmc.txt

@@ -21,12 +21,6 @@ Optional properties:
 - cd-inverted: when present, polarity on the cd gpio line is inverted
 - wp-inverted: when present, polarity on the wp gpio line is inverted
 - max-frequency: maximum operating clock frequency
-- no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
-  this system, even if the controller claims it is.
-
-Optional SDIO properties:
-- keep-power-in-suspend: Preserves card power during a suspend/resume cycle
-- enable-sdio-wakeup: Enables wake up of host system on SDIO IRQ assertion
 
 Example:
 
@@ -39,6 +33,4 @@ sdhci@ab000000 {
 	cd-inverted;
 	wp-gpios = <&gpio 70 0>;
 	max-frequency = <50000000>;
-	keep-power-in-suspend;
-	enable-sdio-wakeup;
 }

trunk/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt

@@ -12,6 +12,10 @@ is used. The Samsung's SDHCI controller bindings extends this as listed below.
 [A] The property "samsung,cd-pinmux-gpio" can be used as stated in the
     "Optional Board Specific Properties" section below.
 
+[B] If core card-detect bindings and "samsung,cd-pinmux-gpio" property
+    is not specified, it is assumed that there is no card detection
+    mechanism used.
+
 Required SoC Specific Properties:
 - compatible: should be one of the following
   - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
@@ -20,18 +24,14 @@ Required SoC Specific Properties:
     controller.
 
 Required Board Specific Properties:
-- Samsung GPIO variant (will be completely replaced by pinctrl):
-  - gpios: Should specify the gpios used for clock, command and data lines. The
-    gpio specifier format depends on the gpio controller.
-- Pinctrl variant (preferred if available):
-  - pinctrl-0: Should specify pin control groups used for this controller.
-  - pinctrl-names: Should contain only one value - "default".
+- gpios: Should specify the gpios used for clock, command and data lines. The
+  gpio specifier format depends on the gpio controller.
 
 Optional Board Specific Properties:
 - samsung,cd-pinmux-gpio: Specifies the card detect line that is routed
   through a pinmux to the card-detect pin of the card slot. This property
   should be used only if none of the mmc core card-detect properties are
-  used. Only for Samsung GPIO variant.
+  used.
 
 Example:
 	sdhci@12530000 {
@@ -40,18 +40,12 @@ Example:
 		interrupts = <0 75 0>;
 		bus-width = <4>;
 		cd-gpios = <&gpk2 2 2 3 3>;
-
-		/* Samsung GPIO variant */
 		gpios = <&gpk2 0 2 0 3>,  /* clock line */
 			<&gpk2 1 2 0 3>,  /* command line */
 			<&gpk2 3 2 3 3>,  /* data line 0 */
 			<&gpk2 4 2 3 3>,  /* data line 1 */
 			<&gpk2 5 2 3 3>,  /* data line 2 */
 			<&gpk2 6 2 3 3>;  /* data line 3 */
-
-		/* Pinctrl variant */
-		pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4>;
-		pinctrl-names = "default";
 	};
 
 	Note: This example shows both SoC specific and board specific properties

trunk/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

@@ -19,7 +19,6 @@ ti,dual-volt: boolean, supports dual voltage cards
 "supply-name" examples are "vmmc", "vmmc_aux" etc
 ti,non-removable: non-removable slot (like eMMC)
 ti,needs-special-reset: Requires a special softreset sequence
-ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed
 
 Example:
 	mmc1: mmc@0x4809c000 {

trunk/Documentation/devicetree/bindings/net/mdio-gpio.txt

@@ -8,16 +8,9 @@ gpios property as described in section VIII.1 in the following order:
 
 MDC, MDIO.
 
-Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases"
-node.
-
 Example:
 
-aliases {
-	mdio-gpio0 = <&mdio0>;
-};
-
-mdio0: mdio {
+mdio {
 	compatible = "virtual,mdio-gpio";
 	#address-cells = <1>;
 	#size-cells = <0>;