--- /dev/null
+From 8fad87bca7ac9737e413ba5f1656f1114a8c314d Mon Sep 17 00:00:00 2001
+From: Liu Hua <sdu.liu@huawei.com>
+Date: Thu, 27 Mar 2014 06:56:18 +0100
+Subject: ARM: 8012/1: kdump: Avoid overflow when converting pfn to physaddr
+
+From: Liu Hua <sdu.liu@huawei.com>
+
+commit 8fad87bca7ac9737e413ba5f1656f1114a8c314d upstream.
+
+When we configure CONFIG_ARM_LPAE=y, pfn << PAGE_SHIFT will
+overflow if pfn >= 0x100000 in copy_oldmem_page.
+So use __pfn_to_phys for converting.
+
+Signed-off-by: Liu Hua <sdu.liu@huawei.com>
+Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/kernel/crash_dump.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/kernel/crash_dump.c
++++ b/arch/arm/kernel/crash_dump.c
+@@ -39,7 +39,7 @@ ssize_t copy_oldmem_page(unsigned long p
+ if (!csize)
+ return 0;
+
+- vaddr = ioremap(pfn << PAGE_SHIFT, PAGE_SIZE);
++ vaddr = ioremap(__pfn_to_phys(pfn), PAGE_SIZE);
+ if (!vaddr)
+ return -ENOMEM;
+
--- /dev/null
+From cf7eb979116c2568e8bc3b6a7269c7a359864ace Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Sun, 13 Apr 2014 20:44:46 +0200
+Subject: ARM: common: edma: Fix xbar mapping
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit cf7eb979116c2568e8bc3b6a7269c7a359864ace upstream.
+
+This is another great example of trainwreck engineering:
+
+commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support)
+added support for using EDMA on peripherals which have no direct EDMA
+event mapping.
+
+The code compiles and does not explode in your face, but that's it.
+
+1) Reading an u16 array from an u32 device tree array simply does not
+ work. Even if the function is named "edma_of_read_u32_to_s16_array".
+
+ It merily calls of_property_read_u16_array. So the resulting 16bit
+ array will have every other entry = 0.
+
+2) The DT entry for the xbar registers related to xbar has length 0x10
+ instead of the real length: 0xfd0 - 0xf90 = 0x40.
+
+ Not a real problem as it does not cross a page boundary, but
+ wrong nevertheless.
+
+3) But none of this matters as the mapping never happens:
+
+ After reading nonsense edma_of_read_u32_to_s16_array() invalidates
+ the first array entry pair, so nobody can ever notice the
+ braindamage by immediate explosion.
+
+Seems the QA criteria for this code was solely not to explode when
+someone adds edma-xbar-event-map entries to the DT. Goal achieved,
+congratulations!
+
+Not really helpful if someone wants to use edma on a device which
+requires a xbar mapping.
+
+Fix the issues by:
+
+- annotating the device tree entry with "/bits/ 16" as documented in
+ the of_property_read_u16_array kernel doc
+
+- make the size of the xbar register mapping correct
+
+- invalidating the end of the array and not the start
+
+This convoluted mess wants to be completely rewritten as there is no
+point to keep the xbar_chan array memory and the iomapping of the xbar
+regs around forever. Marking the xbar mapped channels as used should
+be done right there.
+
+But that's a different issue and this patch is small enough to make it
+work and allows a simple backport for stable.
+
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Sekhar Nori <nsekhar@ti.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/devicetree/bindings/dma/ti-edma.txt | 4 -
+ arch/arm/boot/dts/am33xx.dtsi | 2
+ arch/arm/common/edma.c | 48 ++++++----------------
+ 3 files changed, 18 insertions(+), 36 deletions(-)
+
+--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
++++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
+@@ -29,6 +29,6 @@ edma: edma@49000000 {
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+- ti,edma-xbar-event-map = <1 12
+- 2 13>;
++ ti,edma-xbar-event-map = /bits/ 16 <1 12
++ 2 13>;
+ };
+--- a/arch/arm/boot/dts/am33xx.dtsi
++++ b/arch/arm/boot/dts/am33xx.dtsi
+@@ -140,7 +140,7 @@
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x49000000 0x10000>,
+- <0x44e10f90 0x10>;
++ <0x44e10f90 0x40>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+--- a/arch/arm/common/edma.c
++++ b/arch/arm/common/edma.c
+@@ -1423,55 +1423,38 @@ EXPORT_SYMBOL(edma_clear_event);
+
+ #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_DMADEVICES)
+
+-static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+- const char *propname, s16 *out_values,
+- size_t sz)
++static int edma_xbar_event_map(struct device *dev, struct device_node *node,
++ struct edma_soc_info *pdata, size_t sz)
+ {
+- int ret;
+-
+- ret = of_property_read_u16_array(np, propname, out_values, sz);
+- if (ret)
+- return ret;
+-
+- /* Terminate it */
+- *out_values++ = -1;
+- *out_values++ = -1;
+-
+- return 0;
+-}
+-
+-static int edma_xbar_event_map(struct device *dev,
+- struct device_node *node,
+- struct edma_soc_info *pdata, int len)
+-{
+- int ret, i;
++ const char pname[] = "ti,edma-xbar-event-map";
+ struct resource res;
+ void __iomem *xbar;
+- const s16 (*xbar_chans)[2];
++ s16 (*xbar_chans)[2];
++ size_t nelm = sz / sizeof(s16);
+ u32 shift, offset, mux;
++ int ret, i;
+
+- xbar_chans = devm_kzalloc(dev,
+- len/sizeof(s16) + 2*sizeof(s16),
+- GFP_KERNEL);
++ xbar_chans = devm_kzalloc(dev, (nelm + 2) * sizeof(s16), GFP_KERNEL);
+ if (!xbar_chans)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 1, &res);
+ if (ret)
+- return -EIO;
++ return -ENOMEM;
+
+ xbar = devm_ioremap(dev, res.start, resource_size(&res));
+ if (!xbar)
+ return -ENOMEM;
+
+- ret = edma_of_read_u32_to_s16_array(node,
+- "ti,edma-xbar-event-map",
+- (s16 *)xbar_chans,
+- len/sizeof(u32));
++ ret = of_property_read_u16_array(node, pname, (u16 *)xbar_chans, nelm);
+ if (ret)
+ return -EIO;
+
+- for (i = 0; xbar_chans[i][0] != -1; i++) {
++ /* Invalidate last entry for the other user of this mess */
++ nelm >>= 1;
++ xbar_chans[nelm][0] = xbar_chans[nelm][1] = -1;
++
++ for (i = 0; i < nelm; i++) {
+ shift = (xbar_chans[i][1] & 0x03) << 3;
+ offset = xbar_chans[i][1] & 0xfffffffc;
+ mux = readl(xbar + offset);
+@@ -1480,8 +1463,7 @@ static int edma_xbar_event_map(struct de
+ writel(mux, (xbar + offset));
+ }
+
+- pdata->xbar_chans = xbar_chans;
+-
++ pdata->xbar_chans = (const s16 (*)[2]) xbar_chans;
+ return 0;
+ }
+
--- /dev/null
+From bfaed5abad998bfc88a66e6e71c7b08dcf82f04e Mon Sep 17 00:00:00 2001
+From: Leif Lindholm <leif.lindholm@linaro.org>
+Date: Thu, 17 Apr 2014 18:41:59 +0100
+Subject: arm: dts: Fix missing device_type="memory" for ste-ccu8540
+
+From: Leif Lindholm <leif.lindholm@linaro.org>
+
+commit bfaed5abad998bfc88a66e6e71c7b08dcf82f04e upstream.
+
+The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for
+its memory node, relying on an old ppc quirk in order to discover its
+memory. Fix the data so that all parsing code can handle it correctly.
+
+Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
+Acked-by: Lee Jones <lee.jones@linaro.org>
+Acked-by: Linus Walleij <linus.walleij@linaro.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: devicetree@vger.kernel.org
+Cc: Mark Rutland <mark.rutland@arm.com>
+Signed-off-by: Grant Likely <grant.likely@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/ste-ccu8540.dts | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm/boot/dts/ste-ccu8540.dts
++++ b/arch/arm/boot/dts/ste-ccu8540.dts
+@@ -18,6 +18,7 @@
+ compatible = "st-ericsson,ccu8540", "st-ericsson,u8540";
+
+ memory@0 {
++ device_type = "memory";
+ reg = <0x20000000 0x1f000000>, <0xc0000000 0x3f000000>;
+ };
+
--- /dev/null
+From 6d66da89bf4422c0a0693627fb3e25f74af50f92 Mon Sep 17 00:00:00 2001
+From: Sascha Hauer <s.hauer@pengutronix.de>
+Date: Tue, 6 May 2014 13:01:34 +0200
+Subject: ARM: dts: i.MX53: Fix ipu register space size
+
+From: Sascha Hauer <s.hauer@pengutronix.de>
+
+commit 6d66da89bf4422c0a0693627fb3e25f74af50f92 upstream.
+
+The IPU register space is 128MB, not 2GB.
+
+Fixes: abed9a6bf2bb 'ARM i.MX53: Add IPU support'
+Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
+Acked-by: Shawn Guo <shawn.guo@freescale.com>
+Signed-off-by: Olof Johansson <olof@lixom.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/imx53.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/imx53.dtsi
++++ b/arch/arm/boot/dts/imx53.dtsi
+@@ -87,7 +87,7 @@
+ ipu: ipu@18000000 {
+ #crtc-cells = <1>;
+ compatible = "fsl,imx53-ipu";
+- reg = <0x18000000 0x080000000>;
++ reg = <0x18000000 0x08000000>;
+ interrupts = <11 10>;
+ clocks = <&clks 59>, <&clks 110>, <&clks 61>;
+ clock-names = "bus", "di0", "di1";
--- /dev/null
+From 788296b2d19d16ec33aba0a5ad1544d50bb58601 Mon Sep 17 00:00:00 2001
+From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+Date: Wed, 30 Apr 2014 14:56:28 +0200
+Subject: ARM: dts: kirkwood: fix mislocated pcie-controller nodes
+
+From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+
+commit 788296b2d19d16ec33aba0a5ad1544d50bb58601 upstream.
+
+Commit 54397d85349f
+ ("ARM: kirkwood: Relocate PCIe device tree nodes")
+
+moved the pcie-controller nodes for the Kirkwood SoCs to the mbus
+bus node. For some reason, two boards were not properly converted
+and have their pci-controller nodes still in the ocp bus node.
+
+As the corresponding SoC pcie-controller does not exist anymore,
+it is likely that pcie is broken on those boards since above commit.
+Fix it by moving the pcie related nodes to the correct location.
+
+Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+Fixes: 54397d85349f ("ARM: kirkwood: Relocate PCIe device tree nodes")
+Acked-by: Andrew Lunn <andrew@lunn.ch>
+Link: https://lkml.kernel.org/r/1398862602-29595-2-git-send-email-sebastian.hesselbarth@gmail.com
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts | 18 ++++++++++--------
+ arch/arm/boot/dts/kirkwood-nsa310-common.dtsi | 18 ++++++++++--------
+ 2 files changed, 20 insertions(+), 16 deletions(-)
+
+--- a/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
++++ b/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
+@@ -30,6 +30,16 @@
+ bootargs = "console=ttyS0,115200n8 earlyprintk";
+ };
+
++ mbus {
++ pcie-controller {
++ status = "okay";
++
++ pcie@1,0 {
++ status = "okay";
++ };
++ };
++ };
++
+ ocp@f1000000 {
+ pinctrl@10000 {
+ pmx_usb_led: pmx-usb-led {
+@@ -73,14 +83,6 @@
+ ehci@50000 {
+ status = "okay";
+ };
+-
+- pcie-controller {
+- status = "okay";
+-
+- pcie@1,0 {
+- status = "okay";
+- };
+- };
+ };
+
+ gpio-leds {
+--- a/arch/arm/boot/dts/kirkwood-nsa310-common.dtsi
++++ b/arch/arm/boot/dts/kirkwood-nsa310-common.dtsi
+@@ -4,6 +4,16 @@
+ / {
+ model = "ZyXEL NSA310";
+
++ mbus {
++ pcie-controller {
++ status = "okay";
++
++ pcie@1,0 {
++ status = "okay";
++ };
++ };
++ };
++
+ ocp@f1000000 {
+ pinctrl: pinctrl@10000 {
+
+@@ -26,14 +36,6 @@
+ status = "okay";
+ nr-ports = <2>;
+ };
+-
+- pcie-controller {
+- status = "okay";
+-
+- pcie@1,0 {
+- status = "okay";
+- };
+- };
+ };
+
+ gpio_poweroff {
--- /dev/null
+From f3aec8f3f05025e7b450102dae0759375346706e Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Mon, 14 Apr 2014 17:29:20 +0200
+Subject: ARM: mvebu: fix NOR bus-width in Armada XP DB Device Tree
+
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+commit f3aec8f3f05025e7b450102dae0759375346706e upstream.
+
+The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
+width declared in the Device Tree being considered as a 16 bits bus
+width when configuring the hardware.
+
+This bug in mvebu-devbus driver was compensated by a symetric mistake
+in the Armada XP DB Device Tree: a 8 bits bus width was declared, even
+though the hardware actually has a 16 bits bus width connection with
+the NOR flash.
+
+Now that we have fixed the mvebu-devbus driver to behave according to
+its Device Tree binding, this commit fixes the problematic Device Tree
+files as well.
+
+This bug was introduced in commit
+b484ff42df475c5087d614c4d477273e1906bcb9 ('ARM: mvebu: Add support for
+NOR flash device on Armada XP-DB board') which was merged in v3.11.
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Link: https://lkml.kernel.org/r/1397489361-5833-4-git-send-email-thomas.petazzoni@free-electrons.com
+Fixes: b484ff42df47 ('ARM: mvebu: Add support for NOR flash device on Armada XP-DB board')
+Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
+Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/armada-xp-db.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/armada-xp-db.dts
++++ b/arch/arm/boot/dts/armada-xp-db.dts
+@@ -40,7 +40,7 @@
+ /* Device Bus parameters are required */
+
+ /* Read parameters */
+- devbus,bus-width = <8>;
++ devbus,bus-width = <16>;
+ devbus,turn-off-ps = <60000>;
+ devbus,badr-skew-ps = <0>;
+ devbus,acc-first-ps = <124000>;
--- /dev/null
+From 1a88f809ccb5db1509a7514b187c00b3a995fc82 Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Mon, 14 Apr 2014 17:29:19 +0200
+Subject: ARM: mvebu: fix NOR bus-width in Armada XP GP Device Tree
+
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+commit 1a88f809ccb5db1509a7514b187c00b3a995fc82 upstream.
+
+The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
+width declared in the Device Tree being considered as a 16 bits bus
+width when configuring the hardware.
+
+This bug in mvebu-devbus driver was compensated by a symetric mistake
+in the Armada XP GP Device Tree: a 8 bits bus width was declared, even
+though the hardware actually has a 16 bits bus width connection with
+the NOR flash.
+
+Now that we have fixed the mvebu-devbus driver to behave according to
+its Device Tree binding, this commit fixes the problematic Device Tree
+files as well.
+
+This bug was introduced in commit
+da8d1b38356853c37116f9afa29f15648d7fb159 ('ARM: mvebu: Add support for
+NOR flash device on Armada XP-GP board') which was merged in v3.10.
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Link: https://lkml.kernel.org/r/1397489361-5833-3-git-send-email-thomas.petazzoni@free-electrons.com
+Fixes: da8d1b383568 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board')
+Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
+Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/armada-xp-gp.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/armada-xp-gp.dts
++++ b/arch/arm/boot/dts/armada-xp-gp.dts
+@@ -49,7 +49,7 @@
+ /* Device Bus parameters are required */
+
+ /* Read parameters */
+- devbus,bus-width = <8>;
++ devbus,bus-width = <16>;
+ devbus,turn-off-ps = <60000>;
+ devbus,badr-skew-ps = <0>;
+ devbus,acc-first-ps = <124000>;
--- /dev/null
+From 6e20bae8a39c40d4e03698e4160bad2d2629062b Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Mon, 14 Apr 2014 17:29:21 +0200
+Subject: ARM: mvebu: fix NOR bus-width in Armada XP OpenBlocks AX3 Device Tree
+
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+commit 6e20bae8a39c40d4e03698e4160bad2d2629062b upstream.
+
+The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
+width declared in the Device Tree being considered as a 16 bits bus
+width when configuring the hardware.
+
+This bug in mvebu-devbus driver was compensated by a symetric mistake
+in the Armada XP OpenBlocks AX3 Device Tree: a 8 bits bus width was
+declared, even though the hardware actually has a 16 bits bus width
+connection with the NOR flash.
+
+Now that we have fixed the mvebu-devbus driver to behave according to
+its Device Tree binding, this commit fixes the problematic Device Tree
+files as well.
+
+This bug was introduced in commit
+a7d4f81821f7eec3175f8e23dd6949c71ab2da43 ('ARM: mvebu: Add support for
+NOR flash device on Openblocks AX3 board') which was merged in v3.10.
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Link: https://lkml.kernel.org/r/1397489361-5833-5-git-send-email-thomas.petazzoni@free-electrons.com
+Fixes: a7d4f81821f7 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board')
+Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
+Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
++++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+@@ -37,7 +37,7 @@
+ /* Device Bus parameters are required */
+
+ /* Read parameters */
+- devbus,bus-width = <8>;
++ devbus,bus-width = <16>;
+ devbus,turn-off-ps = <60000>;
+ devbus,badr-skew-ps = <0>;
+ devbus,acc-first-ps = <124000>;
--- /dev/null
+From 1cc9d48145b81e307fab94a5cf6ee66ec2f0de60 Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Sun, 13 Apr 2014 16:39:38 +0200
+Subject: ARM: orion5x: fix target ID for crypto SRAM window
+
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+commit 1cc9d48145b81e307fab94a5cf6ee66ec2f0de60 upstream.
+
+In commit 4ca2c04085a1caa903e92a5fc0da25362150aac2 ('ARM: orion5x:
+Move to ID based window creation'), the mach-orion5x code was changed
+to use the new mvebu-mbus API. However, in the process, a mistake was
+made on the crypto SRAM window target ID: it should have been 0x9
+(verified in the datasheet) and not 0x0.
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+Link: https://lkml.kernel.org/r/1397400006-4315-2-git-send-email-thomas.petazzoni@free-electrons.com
+Fixes: 4ca2c04085a1 ('ARM: orion5x: Move to ID based window creation')
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-orion5x/common.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/mach-orion5x/common.h
++++ b/arch/arm/mach-orion5x/common.h
+@@ -21,7 +21,7 @@ struct mv_sata_platform_data;
+ #define ORION_MBUS_DEVBUS_BOOT_ATTR 0x0f
+ #define ORION_MBUS_DEVBUS_TARGET(cs) 0x01
+ #define ORION_MBUS_DEVBUS_ATTR(cs) (~(1 << cs))
+-#define ORION_MBUS_SRAM_TARGET 0x00
++#define ORION_MBUS_SRAM_TARGET 0x09
+ #define ORION_MBUS_SRAM_ATTR 0x00
+
+ /*
--- /dev/null
+From 1fb4e09a7e780b915dbd172592ae7e2a4c071065 Mon Sep 17 00:00:00 2001
+From: Mohammed Habibulla <moch@chromium.org>
+Date: Thu, 17 Apr 2014 11:37:13 -0700
+Subject: Bluetooth: Add support for Lite-on [04ca:3007]
+
+From: Mohammed Habibulla <moch@chromium.org>
+
+commit 1fb4e09a7e780b915dbd172592ae7e2a4c071065 upstream.
+
+Add support for the AR9462 chip
+
+T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 3 Spd=12 MxCh= 0
+D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
+P: Vendor=04ca ProdID=3007 Rev= 0.01
+C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
+I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
+E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+
+Signed-off-by: Mohammed Habibulla <moch@chromium.org>
+Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/ath3k.c | 2 ++
+ drivers/bluetooth/btusb.c | 1 +
+ 2 files changed, 3 insertions(+)
+
+--- a/drivers/bluetooth/ath3k.c
++++ b/drivers/bluetooth/ath3k.c
+@@ -82,6 +82,7 @@ static const struct usb_device_id ath3k_
+ { USB_DEVICE(0x04CA, 0x3004) },
+ { USB_DEVICE(0x04CA, 0x3005) },
+ { USB_DEVICE(0x04CA, 0x3006) },
++ { USB_DEVICE(0x04CA, 0x3007) },
+ { USB_DEVICE(0x04CA, 0x3008) },
+ { USB_DEVICE(0x04CA, 0x300b) },
+ { USB_DEVICE(0x13d3, 0x3362) },
+@@ -127,6 +128,7 @@ static const struct usb_device_id ath3k_
+ { USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
++ { USB_DEVICE(0x04ca, 0x3007), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x300b), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -149,6 +149,7 @@ static const struct usb_device_id blackl
+ { USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
++ { USB_DEVICE(0x04ca, 0x3007), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x300b), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
--- /dev/null
+From 09da1f3463eb81d59685df723b1c5950b7570340 Mon Sep 17 00:00:00 2001
+From: Johan Hedberg <johan.hedberg@intel.com>
+Date: Fri, 11 Apr 2014 12:02:32 -0700
+Subject: Bluetooth: Fix redundant encryption request for reauthentication
+
+From: Johan Hedberg <johan.hedberg@intel.com>
+
+commit 09da1f3463eb81d59685df723b1c5950b7570340 upstream.
+
+When we're performing reauthentication (in order to elevate the
+security level from an unauthenticated key to an authenticated one) we
+do not need to issue any encryption command once authentication
+completes. Since the trigger for the encryption HCI command is the
+ENCRYPT_PEND flag this flag should not be set in this scenario.
+Instead, the REAUTH_PEND flag takes care of all necessary steps for
+reauthentication.
+
+Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/bluetooth/hci_conn.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/net/bluetooth/hci_conn.c
++++ b/net/bluetooth/hci_conn.c
+@@ -752,14 +752,17 @@ static int hci_conn_auth(struct hci_conn
+ if (!test_and_set_bit(HCI_CONN_AUTH_PEND, &conn->flags)) {
+ struct hci_cp_auth_requested cp;
+
+- /* encrypt must be pending if auth is also pending */
+- set_bit(HCI_CONN_ENCRYPT_PEND, &conn->flags);
+-
+ cp.handle = cpu_to_le16(conn->handle);
+ hci_send_cmd(conn->hdev, HCI_OP_AUTH_REQUESTED,
+ sizeof(cp), &cp);
++
++ /* If we're already encrypted set the REAUTH_PEND flag,
++ * otherwise set the ENCRYPT_PEND.
++ */
+ if (conn->key_type != 0xff)
+ set_bit(HCI_CONN_REAUTH_PEND, &conn->flags);
++ else
++ set_bit(HCI_CONN_ENCRYPT_PEND, &conn->flags);
+ }
+
+ return 0;
--- /dev/null
+From 9eb1fbfa0a737fd4d3a6d12d71c5ea9af622b887 Mon Sep 17 00:00:00 2001
+From: Johan Hedberg <johan.hedberg@intel.com>
+Date: Fri, 11 Apr 2014 12:02:31 -0700
+Subject: Bluetooth: Fix triggering BR/EDR L2CAP Connect too early
+
+From: Johan Hedberg <johan.hedberg@intel.com>
+
+commit 9eb1fbfa0a737fd4d3a6d12d71c5ea9af622b887 upstream.
+
+Commit 1c2e004183178 introduced an event handler for the encryption key
+refresh complete event with the intent of fixing some LE/SMP cases.
+However, this event is shared with BR/EDR and there we actually want to
+act only on the auth_complete event (which comes after the key refresh).
+
+If we do not do this we may trigger an L2CAP Connect Request too early
+and cause the remote side to return a security block error.
+
+Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/bluetooth/hci_event.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -3006,6 +3006,12 @@ static void hci_key_refresh_complete_evt
+ if (!conn)
+ goto unlock;
+
++ /* For BR/EDR the necessary steps are taken through the
++ * auth_complete event.
++ */
++ if (conn->type != LE_LINK)
++ goto unlock;
++
+ if (!ev->status)
+ conn->sec_level = conn->pending_sec_level;
+
--- /dev/null
+From d353efd02357a74753cd45f367a2d3d357fd6904 Mon Sep 17 00:00:00 2001
+From: Fabian Frederick <fabf@skynet.be>
+Date: Tue, 6 May 2014 12:50:11 -0700
+Subject: fs/affs/super.c: bugfix / double free
+
+From: Fabian Frederick <fabf@skynet.be>
+
+commit d353efd02357a74753cd45f367a2d3d357fd6904 upstream.
+
+Commit 842a859db26b ("affs: use ->kill_sb() to simplify ->put_super()
+and failure exits of ->mount()") adds .kill_sb which frees sbi but
+doesn't remove sbi free in case of parse_options error causing double
+free+random crash.
+
+Signed-off-by: Fabian Frederick <fabf@skynet.be>
+Cc: Alexander Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/affs/super.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/fs/affs/super.c
++++ b/fs/affs/super.c
+@@ -336,8 +336,6 @@ static int affs_fill_super(struct super_
+ &blocksize,&sbi->s_prefix,
+ sbi->s_volume, &mount_flags)) {
+ printk(KERN_ERR "AFFS: Error parsing options\n");
+- kfree(sbi->s_prefix);
+- kfree(sbi);
+ return -EINVAL;
+ }
+ /* N.B. after this point s_prefix must be released */
--- /dev/null
+From 49e068f0b73dd042c186ffa9b420a9943e90389a Mon Sep 17 00:00:00 2001
+From: Vlastimil Babka <vbabka@suse.cz>
+Date: Tue, 6 May 2014 12:50:03 -0700
+Subject: mm/compaction: make isolate_freepages start at pageblock boundary
+
+From: Vlastimil Babka <vbabka@suse.cz>
+
+commit 49e068f0b73dd042c186ffa9b420a9943e90389a upstream.
+
+The compaction freepage scanner implementation in isolate_freepages()
+starts by taking the current cc->free_pfn value as the first pfn. In a
+for loop, it scans from this first pfn to the end of the pageblock, and
+then subtracts pageblock_nr_pages from the first pfn to obtain the first
+pfn for the next for loop iteration.
+
+This means that when cc->free_pfn starts at offset X rather than being
+aligned on pageblock boundary, the scanner will start at offset X in all
+scanned pageblock, ignoring potentially many free pages. Currently this
+can happen when
+
+ a) zone's end pfn is not pageblock aligned, or
+
+ b) through zone->compact_cached_free_pfn with CONFIG_HOLES_IN_ZONE
+ enabled and a hole spanning the beginning of a pageblock
+
+This patch fixes the problem by aligning the initial pfn in
+isolate_freepages() to pageblock boundary. This also permits replacing
+the end-of-pageblock alignment within the for loop with a simple
+pageblock_nr_pages increment.
+
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Reported-by: Heesub Shin <heesub.shin@samsung.com>
+Acked-by: Minchan Kim <minchan@kernel.org>
+Cc: Mel Gorman <mgorman@suse.de>
+Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Cc: Michal Nazarewicz <mina86@mina86.com>
+Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Cc: Christoph Lameter <cl@linux.com>
+Acked-by: Rik van Riel <riel@redhat.com>
+Cc: Dongjun Shin <d.j.shin@samsung.com>
+Cc: Sunghwan Yun <sunghwan.yun@samsung.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/compaction.c | 22 ++++++++++++----------
+ 1 file changed, 12 insertions(+), 10 deletions(-)
+
+--- a/mm/compaction.c
++++ b/mm/compaction.c
+@@ -666,16 +666,20 @@ static void isolate_freepages(struct zon
+ struct compact_control *cc)
+ {
+ struct page *page;
+- unsigned long high_pfn, low_pfn, pfn, z_end_pfn, end_pfn;
++ unsigned long high_pfn, low_pfn, pfn, z_end_pfn;
+ int nr_freepages = cc->nr_freepages;
+ struct list_head *freelist = &cc->freepages;
+
+ /*
+ * Initialise the free scanner. The starting point is where we last
+- * scanned from (or the end of the zone if starting). The low point
+- * is the end of the pageblock the migration scanner is using.
++ * successfully isolated from, zone-cached value, or the end of the
++ * zone when isolating for the first time. We need this aligned to
++ * the pageblock boundary, because we do pfn -= pageblock_nr_pages
++ * in the for loop.
++ * The low boundary is the end of the pageblock the migration scanner
++ * is using.
+ */
+- pfn = cc->free_pfn;
++ pfn = cc->free_pfn & ~(pageblock_nr_pages-1);
+ low_pfn = ALIGN(cc->migrate_pfn + 1, pageblock_nr_pages);
+
+ /*
+@@ -695,6 +699,7 @@ static void isolate_freepages(struct zon
+ for (; pfn >= low_pfn && cc->nr_migratepages > nr_freepages;
+ pfn -= pageblock_nr_pages) {
+ unsigned long isolated;
++ unsigned long end_pfn;
+
+ /*
+ * This can iterate a massively long zone without finding any
+@@ -729,13 +734,10 @@ static void isolate_freepages(struct zon
+ isolated = 0;
+
+ /*
+- * As pfn may not start aligned, pfn+pageblock_nr_page
+- * may cross a MAX_ORDER_NR_PAGES boundary and miss
+- * a pfn_valid check. Ensure isolate_freepages_block()
+- * only scans within a pageblock
++ * Take care when isolating in last pageblock of a zone which
++ * ends in the middle of a pageblock.
+ */
+- end_pfn = ALIGN(pfn + 1, pageblock_nr_pages);
+- end_pfn = min(end_pfn, z_end_pfn);
++ end_pfn = min(pfn + pageblock_nr_pages, z_end_pfn);
+ isolated = isolate_freepages_block(cc, pfn, end_pfn,
+ freelist, false);
+ nr_freepages += isolated;
--- /dev/null
+From d5c9fde3dae750889168807038243ff36431d276 Mon Sep 17 00:00:00 2001
+From: Rik van Riel <riel@redhat.com>
+Date: Tue, 6 May 2014 12:50:01 -0700
+Subject: mm/page-writeback.c: fix divide by zero in pos_ratio_polynom
+
+From: Rik van Riel <riel@redhat.com>
+
+commit d5c9fde3dae750889168807038243ff36431d276 upstream.
+
+It is possible for "limit - setpoint + 1" to equal zero, after getting
+truncated to a 32 bit variable, and resulting in a divide by zero error.
+
+Using the fully 64 bit divide functions avoids this problem. It also
+will cause pos_ratio_polynom() to return the correct value when
+(setpoint - limit) exceeds 2^32.
+
+Also uninline pos_ratio_polynom, at Andrew's request.
+
+Signed-off-by: Rik van Riel <riel@redhat.com>
+Reviewed-by: Michal Hocko <mhocko@suse.cz>
+Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
+Cc: Mel Gorman <mgorman@suse.de>
+Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
+Cc: Luiz Capitulino <lcapitulino@redhat.com>
+Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/page-writeback.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/mm/page-writeback.c
++++ b/mm/page-writeback.c
+@@ -593,14 +593,14 @@ unsigned long bdi_dirty_limit(struct bac
+ * (5) the closer to setpoint, the smaller |df/dx| (and the reverse)
+ * => fast response on large errors; small oscillation near setpoint
+ */
+-static inline long long pos_ratio_polynom(unsigned long setpoint,
++static long long pos_ratio_polynom(unsigned long setpoint,
+ unsigned long dirty,
+ unsigned long limit)
+ {
+ long long pos_ratio;
+ long x;
+
+- x = div_s64(((s64)setpoint - (s64)dirty) << RATELIMIT_CALC_SHIFT,
++ x = div64_s64(((s64)setpoint - (s64)dirty) << RATELIMIT_CALC_SHIFT,
+ limit - setpoint + 1);
+ pos_ratio = x;
+ pos_ratio = pos_ratio * x >> RATELIMIT_CALC_SHIFT;
+@@ -842,7 +842,7 @@ static unsigned long bdi_position_ratio(
+ x_intercept = bdi_setpoint + span;
+
+ if (bdi_dirty < x_intercept - span / 4) {
+- pos_ratio = div_u64(pos_ratio * (x_intercept - bdi_dirty),
++ pos_ratio = div64_u64(pos_ratio * (x_intercept - bdi_dirty),
+ x_intercept - bdi_setpoint + 1);
+ } else
+ pos_ratio /= 4;
--- /dev/null
+From 50c6e282bdf5e8dabf8d7cf7b162545a55645fd9 Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig <hch@lst.de>
+Date: Sun, 4 May 2014 13:03:32 +0200
+Subject: posix_acl: handle NULL ACL in posix_acl_equiv_mode
+
+From: Christoph Hellwig <hch@lst.de>
+
+commit 50c6e282bdf5e8dabf8d7cf7b162545a55645fd9 upstream.
+
+Various filesystems don't bother checking for a NULL ACL in
+posix_acl_equiv_mode, and thus can dereference a NULL pointer when it
+gets passed one. This usually happens from the NFS server, as the ACL tools
+never pass a NULL ACL, but instead of one representing the mode bits.
+
+Instead of adding boilerplat to all filesystems put this check into one place,
+which will allow us to remove the check from other filesystems as well later
+on.
+
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Reported-by: Ben Greear <greearb@candelatech.com>
+Reported-by: Marco Munderloh <munderl@tnt.uni-hannover.de>,
+Cc: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/posix_acl.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/fs/posix_acl.c
++++ b/fs/posix_acl.c
+@@ -246,6 +246,12 @@ posix_acl_equiv_mode(const struct posix_
+ umode_t mode = 0;
+ int not_equiv = 0;
+
++ /*
++ * A null ACL can always be presented as mode bits.
++ */
++ if (!acl)
++ return 0;
++
+ FOREACH_ACL_ENTRY(pa, acl, pe) {
+ switch (pa->e_tag) {
+ case ACL_USER_OBJ:
--- /dev/null
+From 3c49aa852e00978ba2f1a4d1e4598a0c669a5347 Mon Sep 17 00:00:00 2001
+From: Marcel Holtmann <marcel@holtmann.org>
+Date: Tue, 22 Apr 2014 14:04:16 -0700
+Subject: Revert "Bluetooth: Enable autosuspend for Intel Bluetooth device"
+
+From: Marcel Holtmann <marcel@holtmann.org>
+
+commit 3c49aa852e00978ba2f1a4d1e4598a0c669a5347 upstream.
+
+This reverts commit d2bee8fb6e18f6116aada39851918473761f7ab1.
+
+Enabling autosuspend for Intel Bluetooth devices has been shown to not
+work reliable. It does work for some people with certain combinations
+of USB host controllers, but for others it puts the device to sleep and
+it will not wake up for any event.
+
+These events can be important ones like HCI Inquiry Complete or HCI
+Connection Request. The events will arrive as soon as you poke the
+device with a new command, but that is not something we can do in
+these cases.
+
+Initially there were patches to the xHCI USB controller that fixed
+this for some people, but not for all. This could be well a problem
+somewhere in the USB subsystem or in the USB host controllers or
+just plain a hardware issue somewhere. At this moment we just do
+not know and the only safe action is to revert this patch.
+
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Cc: Tedd Ho-Jeong An <tedd.an@intel.com>
+Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/btusb.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -1479,10 +1479,8 @@ static int btusb_probe(struct usb_interf
+ if (id->driver_info & BTUSB_BCM92035)
+ hdev->setup = btusb_setup_bcm92035;
+
+- if (id->driver_info & BTUSB_INTEL) {
+- usb_enable_autosuspend(data->udev);
++ if (id->driver_info & BTUSB_INTEL)
+ hdev->setup = btusb_setup_intel;
+- }
+
+ /* Interface numbers are hardcoded in the specification */
+ data->isoc = usb_ifnum_to_if(data->udev, 1);
--- /dev/null
+From 623762517e2370be3b3f95f4fe08d6c063a49b06 Mon Sep 17 00:00:00 2001
+From: Johannes Weiner <hannes@cmpxchg.org>
+Date: Tue, 6 May 2014 12:50:07 -0700
+Subject: revert "mm: vmscan: do not swap anon pages just because free+file is low"
+
+From: Johannes Weiner <hannes@cmpxchg.org>
+
+commit 623762517e2370be3b3f95f4fe08d6c063a49b06 upstream.
+
+This reverts commit 0bf1457f0cfc ("mm: vmscan: do not swap anon pages
+just because free+file is low") because it introduced a regression in
+mostly-anonymous workloads, where reclaim would become ineffective and
+trap every allocating task in direct reclaim.
+
+The problem is that there is a runaway feedback loop in the scan balance
+between file and anon, where the balance tips heavily towards a tiny
+thrashing file LRU and anonymous pages are no longer being looked at.
+The commit in question removed the safe guard that would detect such
+situations and respond with forced anonymous reclaim.
+
+This commit was part of a series to fix premature swapping in loads with
+relatively little cache, and while it made a small difference, the cure
+is obviously worse than the disease. Revert it.
+
+Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
+Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Acked-by: Rafael Aquini <aquini@redhat.com>
+Cc: Rik van Riel <riel@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/vmscan.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+--- a/mm/vmscan.c
++++ b/mm/vmscan.c
+@@ -1916,6 +1916,24 @@ static void get_scan_count(struct lruvec
+ }
+
+ /*
++ * Prevent the reclaimer from falling into the cache trap: as
++ * cache pages start out inactive, every cache fault will tip
++ * the scan balance towards the file LRU. And as the file LRU
++ * shrinks, so does the window for rotation from references.
++ * This means we have a runaway feedback loop where a tiny
++ * thrashing file LRU becomes infinitely more attractive than
++ * anon pages. Try to detect this based on file LRU size.
++ */
++ if (global_reclaim(sc)) {
++ unsigned long free = zone_page_state(zone, NR_FREE_PAGES);
++
++ if (unlikely(file + free <= high_wmark_pages(zone))) {
++ scan_balance = SCAN_ANON;
++ goto out;
++ }
++ }
++
++ /*
+ * There is enough inactive page cache, do not reclaim
+ * anything from the anonymous working set right now.
+ */
usb-nokia-5300-should-be-treated-as-unusual-dev.patch
rt2x00-fix-beaconing-on-usb.patch
alsa-usb-audio-work-around-corrupted-teac-ud-h01-feedback-data.patch
+bluetooth-fix-triggering-br-edr-l2cap-connect-too-early.patch
+bluetooth-fix-redundant-encryption-request-for-reauthentication.patch
+bluetooth-add-support-for-lite-on.patch
+revert-bluetooth-enable-autosuspend-for-intel-bluetooth-device.patch
+posix_acl-handle-null-acl-in-posix_acl_equiv_mode.patch
+fs-affs-super.c-bugfix-double-free.patch
+mm-page-writeback.c-fix-divide-by-zero-in-pos_ratio_polynom.patch
+mm-compaction-make-isolate_freepages-start-at-pageblock-boundary.patch
+revert-mm-vmscan-do-not-swap-anon-pages-just-because-free-file-is-low.patch
+arm-orion5x-fix-target-id-for-crypto-sram-window.patch
+arm-dts-kirkwood-fix-mislocated-pcie-controller-nodes.patch
+arm-dts-i.mx53-fix-ipu-register-space-size.patch
+arm-common-edma-fix-xbar-mapping.patch
+arm-mvebu-fix-nor-bus-width-in-armada-xp-gp-device-tree.patch
+arm-mvebu-fix-nor-bus-width-in-armada-xp-db-device-tree.patch
+arm-mvebu-fix-nor-bus-width-in-armada-xp-openblocks-ax3-device-tree.patch
+arm-dts-fix-missing-device_type-memory-for-ste-ccu8540.patch
+arm-8012-1-kdump-avoid-overflow-when-converting-pfn-to-physaddr.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
