Merge remote-tracking branch 'origin/f26' into f26-user-thl-vanilla-fedora

28 files changed, 821 insertions, 159 deletions

diff --git a/HID-rmi-Make-sure-the-HID-device-is-opened-on-resume.patch b/HID-rmi-Make-sure-the-HID-device-is-opened-on-resume.patch
deleted file mode 100644
index d7d626972..000000000
--- a/HID-rmi-Make-sure-the-HID-device-is-opened-on-resume.patch
+++ /dev/null
@@ -1,74 +0,0 @@
-From patchwork Sun Jul 23 01:15:09 2017
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: HID: rmi: Make sure the HID device is opened on resume
-From: Lyude <lyude@redhat.com>
-X-Patchwork-Id: 9858267
-Message-Id: <20170723011509.23651-1-lyude@redhat.com>
-To: linux-input@vger.kernel.org
-Cc: Lyude <lyude@redhat.com>, Andrew Duggan <aduggan@synaptics.com>,
- stable@vger.kernel.org, Jiri Kosina <jikos@kernel.org>,
- Benjamin Tissoires <benjamin.tissoires@redhat.com>,
- linux-kernel@vger.kernel.org
-Date: Sat, 22 Jul 2017 21:15:09 -0400
-
-So it looks like that suspend/resume has actually always been broken on
-hid-rmi. The fact it worked was a rather silly coincidence that was
-relying on the HID device to already be opened upon resume. This means
-that so long as anything was reading the /dev/input/eventX node for for
-an RMI device, it would suspend and resume correctly. As well, if
-nothing happened to be keeping the HID device away it would shut off,
-then the RMI driver would get confused on resume when it stopped
-responding and explode.
-
-So, call hid_hw_open() in rmi_post_resume() so we make sure that the
-device is alive before we try talking to it.
-
-This fixes RMI device suspend/resume over HID.
-
-Signed-off-by: Lyude <lyude@redhat.com>
-Cc: Andrew Duggan <aduggan@synaptics.com>
-Cc: stable@vger.kernel.org
----
- drivers/hid/hid-rmi.c | 15 +++++++++++----
- 1 file changed, 11 insertions(+), 4 deletions(-)
-
-diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
-index 5b40c2614599..e7d124f9a27f 100644
---- a/drivers/hid/hid-rmi.c
-+++ b/drivers/hid/hid-rmi.c
-@@ -431,22 +431,29 @@ static int rmi_post_resume(struct hid_device *hdev)
- {
- 	struct rmi_data *data = hid_get_drvdata(hdev);
- 	struct rmi_device *rmi_dev = data->xport.rmi_dev;
--	int ret;
-+	int ret = 0;
- 
- 	if (!(data->device_flags & RMI_DEVICE))
- 		return 0;
- 
--	ret = rmi_reset_attn_mode(hdev);
-+	/* Make sure the HID device is ready to receive events */
-+	ret = hid_hw_open(hdev);
- 	if (ret)
- 		return ret;
- 
-+	ret = rmi_reset_attn_mode(hdev);
-+	if (ret)
-+		goto out;
-+
- 	ret = rmi_driver_resume(rmi_dev, false);
- 	if (ret) {
- 		hid_warn(hdev, "Failed to resume device: %d\n", ret);
--		return ret;
-+		goto out;
- 	}
- 
--	return 0;
-+out:
-+	hid_hw_close(hdev);
-+	return ret;
- }
- #endif /* CONFIG_PM */
- 
diff --git a/arm64-cavium-fixes.patch b/arm64-cavium-fixes.patch
new file mode 100644
index 000000000..a898bb779
--- /dev/null
+++ b/arm64-cavium-fixes.patch
@@ -0,0 +1,455 @@
+From c03847b4a603846903ee72a5e1baab03e0591423 Mon Sep 17 00:00:00 2001
+From: Ashok Kumar Sekar <asekar@redhat.com>
+Date: Fri, 23 Sep 2016 04:16:19 -0700
+Subject: [PATCH 1/8] PCI: Vulcan: AHCI PCI bar fix for Broadcom Vulcan early
+ silicon
+
+PCI BAR 5 is not setup correctly for the on-board AHCI
+controller on Broadcom's Vulcan processor. Added a quirk to fix BAR 5
+by using BAR 4's resources which are populated correctly but NOT used
+by the AHCI controller actually.
+
+Signed-off-by: Ashok Kumar Sekar <asekar@redhat.com>
+Signed-off-by: Jayachandran C <jchandra@broadcom.com>
+Signed-off-by: Robert Richter <rrichter@cavium.com>
+---
+ drivers/pci/quirks.c | 24 ++++++++++++++++++++++++
+ 1 file changed, 24 insertions(+)
+
+diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
+index dc624fb34e72..94b7bdf63b19 100644
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -3994,6 +3994,30 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_BROADCOM, 0x9084,
+ 				quirk_bridge_cavm_thrx2_pcie_root);
+ 
+ /*
++ * PCI BAR 5 is not setup correctly for the on-board AHCI controller
++ * on Broadcom's Vulcan processor. Added a quirk to fix BAR 5 by
++ * using BAR 4's resources which are populated correctly and NOT
++ * actually used by the AHCI controller.
++ */
++static void quirk_fix_vulcan_ahci_bars(struct pci_dev *dev)
++{
++	struct resource *r =  &dev->resource[4];
++
++	if (!(r->flags & IORESOURCE_MEM) || (r->start == 0))
++		return;
++
++	/* Set BAR5 resource to BAR4 */
++	dev->resource[5] = *r;
++
++	/* Update BAR5 in pci config space */
++	pci_write_config_dword(dev, PCI_BASE_ADDRESS_5, r->start);
++
++	/* Clear BAR4's resource */
++	memset(r, 0, sizeof(*r));
++}
++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_BROADCOM, 0x9027, quirk_fix_vulcan_ahci_bars);
++
++/*
+  * Intersil/Techwell TW686[4589]-based video capture cards have an empty (zero)
+  * class code.  Fix it.
+  */
+-- 
+2.11.0
+
+From c84892e4b6b671fda7e499a0bb0787bd026de015 Mon Sep 17 00:00:00 2001
+From: Jayachandran C <jnair@caviumnetworks.com>
+Date: Fri, 10 Mar 2017 10:04:52 +0000
+Subject: [PATCH 2/8] ahci: thunderx2: Fix for errata that affects stop engine
+
+Apply workaround for this errata:
+  Synopsis: Resetting PxCMD.ST may hang the SATA device
+
+  Description: An internal ping-pong buffer state is not reset
+  correctly for an PxCMD.ST=0 command for a SATA channel. This
+  may cause the SATA interface to hang when a PxCMD.ST=0 command
+  is received.
+
+  Workaround: A SATA_BIU_CORE_ENABLE.sw_init_bsi must be asserted
+  by the driver whenever the PxCMD.ST needs to be de-asserted. This
+  will reset both the ports. So, it may not always work in a 2
+  channel SATA system.
+
+  Resolution: Fix in B0.
+
+Add the code to ahci_stop_engine() to do this. It is not easy to
+stop the other "port" since it is associated with a different AHCI
+interface. Please note that with this fix, SATA reset does not
+hang any more, but it can cause failures on the other interface
+if that is in active use.
+
+Unfortunately, we have nothing other the the CPU ID to check if the
+SATA block has this issue.
+
+Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
+[added check to restict to pci devs on the soc only]
+Signed-off-by: Robert Richter <rrichter@cavium.com>
+---
+ drivers/ata/libahci.c | 17 +++++++++++++++++
+ 1 file changed, 17 insertions(+)
+
+diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
+index 3e286d86ab42..9116bba1b07d 100644
+--- a/drivers/ata/libahci.c
++++ b/drivers/ata/libahci.c
+@@ -669,6 +669,23 @@ int ahci_stop_engine(struct ata_port *ap)
+ 	tmp &= ~PORT_CMD_START;
+ 	writel(tmp, port_mmio + PORT_CMD);
+ 
++#ifdef CONFIG_ARM64
++	/* Rev Ax of Cavium CN99XX needs a hack for port stop */
++	if (dev_is_pci(ap->host->dev) &&
++	    to_pci_dev(ap->host->dev)->vendor == 0x14e4 &&
++	    to_pci_dev(ap->host->dev)->device == 0x9027 &&
++	    MIDR_IS_CPU_MODEL_RANGE(read_cpuid_id(),
++			MIDR_CPU_MODEL(ARM_CPU_IMP_BRCM, BRCM_CPU_PART_VULCAN),
++			MIDR_CPU_VAR_REV(0, 0),
++			MIDR_CPU_VAR_REV(0, MIDR_REVISION_MASK))) {
++		tmp = readl(hpriv->mmio + 0x8000);
++		writel(tmp | (1 << 26), hpriv->mmio + 0x8000);
++		udelay(1);
++		writel(tmp & ~(1 << 26), hpriv->mmio + 0x8000);
++		dev_warn(ap->host->dev, "CN99XX stop engine fix applied!\n");
++	}
++#endif
++
+ 	/* wait for engine to stop. This could be as long as 500 msec */
+ 	tmp = ata_wait_register(ap, port_mmio + PORT_CMD,
+ 				PORT_CMD_LIST_ON, PORT_CMD_LIST_ON, 1, 500);
+-- 
+2.11.0
+
+From 98a39621952f6a13c5198e79f1c080ea6fc1d092 Mon Sep 17 00:00:00 2001
+From: Jayachandran C <jnair@caviumnetworks.com>
+Date: Sun, 22 Feb 1998 18:42:42 -0800
+Subject: [PATCH 3/8] ahci: thunderx2: stop engine fix update
+
+The current reset fix fails during continuous reboot test. The failure
+happens when both the on-board SATA slots are used and when one of the
+controllers are reset.
+
+The latest ThunderX2 firmware (3.1) enables hardware error interrupts and
+when the reset fix fails, we get a hang with the print:
+[   14.839308] sd 1:0:0:0: [sdb] 468862128 512-byte logical blocks: (240 GB/224 GiB)
+[   14.846796] sd 1:0:0:0: [sdb] 4096-byte physical blocks
+[   14.852036] sd 1:0:0:0: [sdb] Write Protect is off
+[   14.856843] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+[   14.866022] ata2.00: Enabling discard_zeroes_data
+
+        *** NBU BAR Error 0x1e25c ***
+         AddrLo 0x1d80180 AddrHi 0x0
+
+To fix this issue, update the SATA reset fix to increase the delays between register writes.
+
+Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
+Signed-off-by: Robert Richter <rrichter@cavium.com>
+---
+ drivers/ata/libahci.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
+index 9116bba1b07d..1d3e614bad2b 100644
+--- a/drivers/ata/libahci.c
++++ b/drivers/ata/libahci.c
+@@ -679,10 +679,11 @@ int ahci_stop_engine(struct ata_port *ap)
+ 			MIDR_CPU_VAR_REV(0, 0),
+ 			MIDR_CPU_VAR_REV(0, MIDR_REVISION_MASK))) {
+ 		tmp = readl(hpriv->mmio + 0x8000);
++		udelay(100);
+ 		writel(tmp | (1 << 26), hpriv->mmio + 0x8000);
+-		udelay(1);
++		udelay(100);
+ 		writel(tmp & ~(1 << 26), hpriv->mmio + 0x8000);
+-		dev_warn(ap->host->dev, "CN99XX stop engine fix applied!\n");
++		dev_warn(ap->host->dev, "CN99XX SATA reset workaround applied\n");
+ 	}
+ #endif
+ 
+-- 
+2.11.0
+
+From 33c107d2a2b570cd5246262108ad07cc102e9fcd Mon Sep 17 00:00:00 2001
+From: Robert Richter <rrichter@cavium.com>
+Date: Thu, 16 Mar 2017 18:01:59 +0100
+Subject: [PATCH 4/8] iommu/arm-smmu, ACPI: Enable Cavium SMMU-v2
+
+In next IORT spec release there will be a definition of a Cavium
+specific model. Until then, enable the Cavium SMMU using cpu id
+registers. All versions of Cavium's SMMUv2 implementation must be
+enabled.
+
+Signed-off-by: Robert Richter <rrichter@cavium.com>
+---
+ drivers/iommu/arm-smmu.c | 22 +++++++++++++++++++++-
+ 1 file changed, 21 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
+index d42cad5a3d52..37aee96ccc0e 100644
+--- a/drivers/iommu/arm-smmu.c
++++ b/drivers/iommu/arm-smmu.c
+@@ -53,6 +53,8 @@
+ 
+ #include <linux/amba/bus.h>
+ 
++#include <asm/cputype.h>
++
+ #include "io-pgtable.h"
+ #include "arm-smmu-regs.h"
+ 
+@@ -1871,6 +1873,24 @@ static const struct of_device_id arm_smmu_of_match[] = {
+ MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
+ 
+ #ifdef CONFIG_ACPI
++
++static int acpi_smmu_enable_cavium(struct arm_smmu_device *smmu, int ret)
++{
++	u32 cpu_model;
++
++	if (!IS_ENABLED(CONFIG_ARM64))
++		return ret;
++
++	cpu_model = read_cpuid_id() & MIDR_CPU_MODEL_MASK;
++	if (cpu_model != MIDR_THUNDERX)
++		return ret;
++
++	smmu->version = ARM_SMMU_V2;
++	smmu->model = CAVIUM_SMMUV2;
++
++	return 0;
++}
++
+ static int acpi_smmu_get_data(u32 model, struct arm_smmu_device *smmu)
+ {
+ 	int ret = 0;
+@@ -1901,7 +1921,7 @@ static int acpi_smmu_get_data(u32 model, struct arm_smmu_device *smmu)
+ 		ret = -ENODEV;
+ 	}
+ 
+-	return ret;
++	return acpi_smmu_enable_cavium(smmu, ret);
+ }
+ 
+ static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
+-- 
+2.11.0
+
+From 5523edb06c95d7ac9e81d94366e71d929c08ebd4 Mon Sep 17 00:00:00 2001
+From: Robert Richter <rrichter@cavium.com>
+Date: Wed, 12 Apr 2017 15:06:03 +0200
+Subject: [PATCH 5/8] iommu: Print a message with the default domain type
+ created
+
+There are several ways the bypass mode can be enabled. With commit
+
+ fccb4e3b8ab0 iommu: Allow default domain type to be set on the kernel command line
+
+there is the option to switch into bypass mode. And, depending on
+devicetree options, bypass mode can be also enabled. This makes it
+hard to determine if direct mapping is enabled. Print message with the
+default domain type case.
+
+Signed-off-by: Robert Richter <rrichter@cavium.com>
+---
+ drivers/iommu/iommu.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
+index 3f6ea160afed..7aaafaca6baf 100644
+--- a/drivers/iommu/iommu.c
++++ b/drivers/iommu/iommu.c
+@@ -599,7 +599,9 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev)
+ 
+ 	trace_add_device_to_group(group->id, dev);
+ 
+-	pr_info("Adding device %s to group %d\n", dev_name(dev), group->id);
++	pr_info("Adding device %s to group %d, default domain type %d\n",
++		dev_name(dev), group->id,
++		group->default_domain ? group->default_domain->type : -1);
+ 
+ 	return 0;
+ 
+-- 
+2.11.0
+
+From 71e0ad5ab606077c24a96d69f4bfed58d7ef16c7 Mon Sep 17 00:00:00 2001
+From: Robert Richter <rrichter@cavium.com>
+Date: Thu, 4 May 2017 17:48:48 +0200
+Subject: [PATCH 6/8] iommu, aarch64: Set bypass mode per default
+
+We see a performance degradation if smmu is enabled in non-bypass mode.
+This is a problem in the kernel's implememntation. Until that is solved,
+enable smmu in bypass mode per default.
+
+We have tested that SMMU passthrough mode doesn't effect VFIO on both
+CN88xx and CN99xx and haven't found any issues.
+
+Signed-off-by: Robert Richter <rrichter@cavium.com>
+---
+ drivers/iommu/iommu.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
+index 7aaafaca6baf..24de0b934221 100644
+--- a/drivers/iommu/iommu.c
++++ b/drivers/iommu/iommu.c
+@@ -36,7 +36,12 @@
+ 
+ static struct kset *iommu_group_kset;
+ static DEFINE_IDA(iommu_group_ida);
++
++#ifdef CONFIG_ARM64
++static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_IDENTITY;
++#else
+ static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_DMA;
++#endif
+ 
+ struct iommu_callback_data {
+ 	const struct iommu_ops *ops;
+-- 
+2.11.0
+
+From 27f103963f926d6a7a8adaad1ee227fd3b51f591 Mon Sep 17 00:00:00 2001
+From: Robert Richter <rrichter@cavium.com>
+Date: Wed, 12 Apr 2017 10:31:15 +0200
+Subject: [PATCH 7/8] iommu/arm-smmu, ACPI: Enable Cavium SMMU-v3
+
+In next IORT spec release there will be a definition of a Cavium
+specific model. Until then, enable the Cavium SMMU using cpu id
+registers. Early silicon versions (A1) of Cavium's CN99xx SMMUv3
+implementation must be enabled. For later silicon versions (B0) the
+iort change will be in place.
+
+Signed-off-by: Robert Richter <rrichter@cavium.com>
+---
+ drivers/acpi/arm64/iort.c   | 16 ++++++++++++++--
+ drivers/iommu/arm-smmu-v3.c | 19 +++++++++++++++++++
+ 2 files changed, 33 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
+index a3215ee671c1..b603af92eec2 100644
+--- a/drivers/acpi/arm64/iort.c
++++ b/drivers/acpi/arm64/iort.c
+@@ -26,6 +26,8 @@
+ #include <linux/platform_device.h>
+ #include <linux/slab.h>
+ 
++#include <asm/cputype.h>
++
+ #define IORT_TYPE_MASK(type)	(1 << (type))
+ #define IORT_MSI_TYPE		(1 << ACPI_IORT_NODE_ITS_GROUP)
+ #define IORT_IOMMU_TYPE		((1 << ACPI_IORT_NODE_SMMU) |	\
+@@ -824,13 +826,22 @@ static int __init arm_smmu_v3_count_resources(struct acpi_iort_node *node)
+ 	return num_res;
+ }
+ 
++static bool is_cavium_cn99xx_smmu_v3(void)
++{
++	u32 cpu_model = read_cpuid_id() & MIDR_CPU_MODEL_MASK;
++
++	return cpu_model == MIDR_CPU_MODEL(ARM_CPU_IMP_BRCM,
++					   BRCM_CPU_PART_VULCAN);
++}
++
+ static bool arm_smmu_v3_is_combined_irq(struct acpi_iort_smmu_v3 *smmu)
+ {
+ 	/*
+ 	 * Cavium ThunderX2 implementation doesn't not support unique
+ 	 * irq line. Use single irq line for all the SMMUv3 interrupts.
+ 	 */
+-	if (smmu->model != ACPI_IORT_SMMU_V3_CAVIUM_CN99XX)
++	if (smmu->model != ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
++	    && !is_cavium_cn99xx_smmu_v3())
+ 		return false;
+ 
+ 	/*
+@@ -848,7 +859,8 @@ static unsigned long arm_smmu_v3_resource_size(struct acpi_iort_smmu_v3 *smmu)
+ 	 * Override the size, for Cavium ThunderX2 implementation
+ 	 * which doesn't support the page 1 SMMU register space.
+ 	 */
+-	if (smmu->model == ACPI_IORT_SMMU_V3_CAVIUM_CN99XX)
++	if (smmu->model == ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
++	    || is_cavium_cn99xx_smmu_v3())
+ 		return SZ_64K;
+ 
+ 	return SZ_128K;
+diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
+index 568c400eeaed..d147cb5c7309 100644
+--- a/drivers/iommu/arm-smmu-v3.c
++++ b/drivers/iommu/arm-smmu-v3.c
+@@ -39,6 +39,8 @@
+ 
+ #include <linux/amba/bus.h>
+ 
++#include <asm/cputype.h>
++
+ #include "io-pgtable.h"
+ 
+ /* MMIO registers */
+@@ -2659,6 +2661,21 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
+ }
+ 
+ #ifdef CONFIG_ACPI
++
++static void acpi_smmu_enable_cavium(struct arm_smmu_device *smmu)
++{
++	u32 cpu_model;
++
++	if (!IS_ENABLED(CONFIG_ARM64))
++		return;
++
++	cpu_model = read_cpuid_id() & MIDR_CPU_MODEL_MASK;
++	if (cpu_model != MIDR_CPU_MODEL(ARM_CPU_IMP_BRCM, BRCM_CPU_PART_VULCAN))
++		return;
++
++	smmu->options |= ARM_SMMU_OPT_PAGE0_REGS_ONLY;
++}
++
+ static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu)
+ {
+ 	switch (model) {
+@@ -2670,6 +2687,8 @@ static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu)
+ 		break;
+ 	}
+ 
++	acpi_smmu_enable_cavium(smmu);
++
+ 	dev_notice(smmu->dev, "option mask 0x%x\n", smmu->options);
+ }
+ 
+-- 
+2.11.0
+
+From ff677cc625b52b93351dd73d7881251067f0e976 Mon Sep 17 00:00:00 2001
+From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
+Date: Wed, 20 Aug 2014 15:10:58 -0700
+Subject: [PATCH 8/8] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for
+ Cavium ThunderX
+
+In case of ARCH_THUNDER, there is a need to allocate the GICv3 ITS table
+which is bigger than the allowed max order. So we are forcing it only in
+case of 4KB page size.
+
+Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
+[rric: use ARM64_4K_PAGES since we have now ARM64_16K_PAGES, change order]
+Signed-off-by: Robert Richter <rrichter@cavium.com>
+---
+ arch/arm64/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
+index 2c3e2d693d76..023867378f45 100644
+--- a/arch/arm64/Kconfig
++++ b/arch/arm64/Kconfig
+@@ -784,6 +784,7 @@ config FORCE_MAX_ZONEORDER
+ 	default "14" if (ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE)
+ 	default "13" if (ARCH_THUNDER && !ARM64_64K_PAGES)
+ 	default "12" if (ARM64_16K_PAGES && TRANSPARENT_HUGEPAGE)
++	default "13" if (ARM64_4K_PAGES && ARCH_THUNDER)
+ 	default "11"
+ 	help
+ 	  The kernel memory allocator divides physically contiguous memory
+-- 
+2.11.0
+
diff --git a/baseconfig/CONFIG_HW_RANDOM_OMAP b/baseconfig/arm/CONFIG_HW_RANDOM_OMAP
index cf37a6e35..cf37a6e35 100644
--- a/baseconfig/CONFIG_HW_RANDOM_OMAP
+++ b/baseconfig/arm/CONFIG_HW_RANDOM_OMAP
diff --git a/baseconfig/arm/armv7/CONFIG_SUN8I_A83T_CCU b/baseconfig/arm/armv7/CONFIG_SUN8I_A83T_CCU
new file mode 100644
index 000000000..a4e88a43c
--- /dev/null
+++ b/baseconfig/arm/armv7/CONFIG_SUN8I_A83T_CCU
@@ -0,0 +1 @@
+CONFIG_SUN8I_A83T_CCU=y
diff --git a/baseconfig/arm/armv7/CONFIG_SUN8I_DE2_CCU b/baseconfig/arm/armv7/CONFIG_SUN8I_DE2_CCU
new file mode 100644
index 000000000..1729d1f68
--- /dev/null
+++ b/baseconfig/arm/armv7/CONFIG_SUN8I_DE2_CCU
@@ -0,0 +1 @@
+CONFIG_SUN8I_DE2_CCU=y
diff --git a/drm-cma-reduce-dmesg-logs.patch b/drm-cma-reduce-dmesg-logs.patch
new file mode 100644
index 000000000..2e39d6e70
--- /dev/null
+++ b/drm-cma-reduce-dmesg-logs.patch
@@ -0,0 +1,96 @@
+From patchwork Thu Oct  5 11:29:17 2017
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: [v2] drm/gem-cma-helper: Change the level of the allocation failure
+ message
+From: Boris Brezillon <boris.brezillon@free-electrons.com>
+X-Patchwork-Id: 180737
+Message-Id: <20171005112917.15949-1-boris.brezillon@free-electrons.com>
+To: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
+ dri-devel@lists.freedesktop.org
+Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
+Date: Thu,  5 Oct 2017 13:29:17 +0200
+
+drm_gem_cma_create() prints an error message when dma_alloc_wc() fails to
+allocate the amount of memory we requested. This can lead to annoying
+error messages when CMA is only one possible source of memory for the BO
+allocation. Turn this error message into a debug one.
+
+Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
+Reviewed-by: Eric Anholt <eric@anholt.net>
+---
+Changes in v2:
+- Remove __must_check attribute
+---
+ drivers/gpu/drm/drm_gem_cma_helper.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c
+index 373e33f22be4..020e7668dfab 100644
+--- a/drivers/gpu/drm/drm_gem_cma_helper.c
++++ b/drivers/gpu/drm/drm_gem_cma_helper.c
+@@ -112,7 +112,7 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
+ 	cma_obj->vaddr = dma_alloc_wc(drm->dev, size, &cma_obj->paddr,
+ 				      GFP_KERNEL | __GFP_NOWARN);
+ 	if (!cma_obj->vaddr) {
+-		dev_err(drm->dev, "failed to allocate buffer with size %zu\n",
++		dev_dbg(drm->dev, "failed to allocate buffer with size %zu\n",
+ 			size);
+ 		ret = -ENOMEM;
+ 		goto error;
+From patchwork Wed Oct  4 12:54:47 2017
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: cma: Take __GFP_NOWARN into account in cma_alloc()
+From: Boris Brezillon <boris.brezillon@free-electrons.com>
+X-Patchwork-Id: 180554
+Message-Id: <20171004125447.15195-1-boris.brezillon@free-electrons.com>
+To: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
+ Laura Abbott <labbott@redhat.com>
+Cc: Boris Brezillon <boris.brezillon@free-electrons.com>,
+ Jaewon Kim <jaewon31.kim@samsung.com>, dri-devel@lists.freedesktop.org
+Date: Wed,  4 Oct 2017 14:54:47 +0200
+
+cma_alloc() unconditionally prints an INFO message when the CMA
+allocation fails. Make this message conditional on the non-presence of
+__GFP_NOWARN in gfp_mask.
+
+Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
+Acked-by: Laura Abbott <labbott@redhat.com>
+---
+Hello,
+
+This patch aims at removing INFO messages that are displayed when the
+VC4 driver tries to allocate buffer objects. From the driver perspective
+an allocation failure is acceptable, and the driver can possibly do
+something to make following allocation succeed (like flushing the VC4
+internal cache).
+
+Also, I don't understand why this message is only an INFO message, and
+not a WARN (pr_warn()). Please let me know if you have good reasons to
+keep it as an unconditional pr_info().
+
+Thanks,
+
+Boris
+---
+ mm/cma.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mm/cma.c b/mm/cma.c
+index c0da318c020e..022e52bd8370 100644
+--- a/mm/cma.c
++++ b/mm/cma.c
+@@ -460,7 +460,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
+ 
+ 	trace_cma_alloc(pfn, page, count, align);
+ 
+-	if (ret) {
++	if (ret && !(gfp_mask & __GFP_NOWARN)) {
+ 		pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
+ 			__func__, count, ret);
+ 		cma_debug_show_areas(cma);
diff --git a/drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch b/drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch
new file mode 100644
index 000000000..0bd0e7cef
--- /dev/null
+++ b/drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch
@@ -0,0 +1,238 @@
+From 333e2a813cdfb86ff286ece6f13bec371aa03d7b Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Thu, 17 Aug 2017 13:37:06 +0100
+Subject: [PATCH] drm/i915: Boost GPU clocks if we miss the pageflip's vblank
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+If we miss the current vblank because the gpu was busy, that may cause a
+jitter as the frame rate temporarily drops. We try to limit the impact
+of this by then boosting the GPU clock to deliver the frame as quickly
+as possible. Originally done in commit 6ad790c0f5ac ("drm/i915: Boost GPU
+frequency if we detect outstanding pageflips") but was never forward
+ported to atomic and finally dropped in commit fd3a40242e87 ("drm/i915:
+Rip out legacy page_flip completion/irq handling").
+
+One of the most typical use-cases for this is a mostly idle desktop.
+Rendering one frame of the desktop's frontbuffer can easily be
+accomplished by the GPU running at low frequency, but often exceeds
+the time budget of the desktop compositor. The result is that animations
+such as opening the menu, doing a fullscreen switch, or even just trying
+to move a window around are slow and jerky. We need to respond within a
+frame to give the best impression of a smooth UX, as a compromise we
+instead respond if that first frame misses its goal. The result should
+be a near-imperceivable initial delay and a smooth animation even
+starting from idle. The cost, as ever, is that we spend more power than
+is strictly necessary as we overestimate the required GPU frequency and
+then try to ramp down.
+
+This of course is reactionary, too little, too late; nevertheless it is
+surprisingly effective.
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102199
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Cc: Daniel Vetter <daniel.vetter@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20170817123706.6777-1-chris@chris-wilson.co.uk
+Tested-by: Lyude Paul <lyude@redhat.com>
+Reviewed-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
+---
+ drivers/gpu/drm/i915/i915_gem.c      | 10 +++---
+ drivers/gpu/drm/i915/intel_display.c | 63 ++++++++++++++++++++++++++++++++++++
+ drivers/gpu/drm/i915/intel_pm.c      | 14 ++++----
+ 3 files changed, 77 insertions(+), 10 deletions(-)
+
+diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
+index 969bac8404f1..7d409b29d75a 100644
+--- a/drivers/gpu/drm/i915/i915_gem.c
++++ b/drivers/gpu/drm/i915/i915_gem.c
+@@ -355,6 +355,7 @@ i915_gem_object_wait_fence(struct dma_fence *fence,
+ 			   long timeout,
+ 			   struct intel_rps_client *rps)
+ {
++	unsigned long irq_flags;
+ 	struct drm_i915_gem_request *rq;
+ 
+ 	BUILD_BUG_ON(I915_WAIT_INTERRUPTIBLE != 0x1);
+@@ -410,9 +411,9 @@ i915_gem_object_wait_fence(struct dma_fence *fence,
+ 		 * Compensate by giving the synchronous client credit for
+ 		 * a waitboost next time.
+ 		 */
+-		spin_lock(&rq->i915->rps.client_lock);
++		spin_lock_irqsave(&rq->i915->rps.client_lock, irq_flags);
+ 		list_del_init(&rps->link);
+-		spin_unlock(&rq->i915->rps.client_lock);
++		spin_unlock_irqrestore(&rq->i915->rps.client_lock, irq_flags);
+ 	}
+ 
+ 	return timeout;
+@@ -5029,6 +5030,7 @@ void i915_gem_release(struct drm_device *dev, struct drm_file *file)
+ {
+ 	struct drm_i915_file_private *file_priv = file->driver_priv;
+ 	struct drm_i915_gem_request *request;
++	unsigned long flags;
+ 
+ 	/* Clean up our request list when the client is going away, so that
+ 	 * later retire_requests won't dereference our soon-to-be-gone
+@@ -5040,9 +5042,9 @@ void i915_gem_release(struct drm_device *dev, struct drm_file *file)
+ 	spin_unlock(&file_priv->mm.lock);
+ 
+ 	if (!list_empty(&file_priv->rps.link)) {
+-		spin_lock(&to_i915(dev)->rps.client_lock);
++		spin_lock_irqsave(&to_i915(dev)->rps.client_lock, flags);
+ 		list_del(&file_priv->rps.link);
+-		spin_unlock(&to_i915(dev)->rps.client_lock);
++		spin_unlock_irqrestore(&to_i915(dev)->rps.client_lock, flags);
+ 	}
+ }
+ 
+diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
+index 022125082649..875eb7aec2f1 100644
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -13301,6 +13301,58 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
+ 	.set_crc_source = intel_crtc_set_crc_source,
+ };
+ 
++struct wait_rps_boost {
++	struct wait_queue_entry wait;
++
++	struct drm_crtc *crtc;
++	struct drm_i915_gem_request *request;
++};
++
++static int do_rps_boost(struct wait_queue_entry *_wait,
++			unsigned mode, int sync, void *key)
++{
++	struct wait_rps_boost *wait = container_of(_wait, typeof(*wait), wait);
++	struct drm_i915_gem_request *rq = wait->request;
++
++	gen6_rps_boost(rq->i915, NULL, rq->emitted_jiffies);
++	i915_gem_request_put(rq);
++
++	drm_crtc_vblank_put(wait->crtc);
++
++	list_del(&wait->wait.entry);
++	kfree(wait);
++	return 1;
++}
++
++static void add_rps_boost_after_vblank(struct drm_crtc *crtc,
++				       struct dma_fence *fence)
++{
++	struct wait_rps_boost *wait;
++
++	if (!dma_fence_is_i915(fence))
++		return;
++
++	if (INTEL_GEN(to_i915(crtc->dev)) < 6)
++		return;
++
++	if (drm_crtc_vblank_get(crtc))
++		return;
++
++	wait = kmalloc(sizeof(*wait), GFP_KERNEL);
++	if (!wait) {
++		drm_crtc_vblank_put(crtc);
++		return;
++	}
++
++	wait->request = to_request(dma_fence_get(fence));
++	wait->crtc = crtc;
++
++	wait->wait.func = do_rps_boost;
++	wait->wait.flags = 0;
++
++	add_wait_queue(drm_crtc_vblank_waitqueue(crtc), &wait->wait);
++}
++
+ /**
+  * intel_prepare_plane_fb - Prepare fb for usage on plane
+  * @plane: drm plane to prepare for
+@@ -13392,6 +13444,8 @@ intel_prepare_plane_fb(struct drm_plane *plane,
+ 		return 0;
+ 
+ 	if (!new_state->fence) { /* implicit fencing */
++		struct dma_fence *fence;
++
+ 		ret = i915_sw_fence_await_reservation(&intel_state->commit_ready,
+ 						      obj->resv, NULL,
+ 						      false, I915_FENCE_TIMEOUT,
+@@ -13399,7 +13453,16 @@ intel_prepare_plane_fb(struct drm_plane *plane,
+ 		if (ret < 0)
+ 			return ret;
+ 
++		fence = reservation_object_get_excl_rcu(obj->resv);
++		if (fence) {
++			add_rps_boost_after_vblank(new_state->crtc, fence);
++			dma_fence_put(fence);
++		}
++
+ 		i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
++
++	} else {
++		add_rps_boost_after_vblank(new_state->crtc, new_state->fence);
+ 	}
+ 
+ 	return 0;
+diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
+index 40b224b44d1b..b0ee9c4d33f4 100644
+--- a/drivers/gpu/drm/i915/intel_pm.c
++++ b/drivers/gpu/drm/i915/intel_pm.c
+@@ -6108,6 +6108,7 @@ void gen6_rps_busy(struct drm_i915_private *dev_priv)
+ 
+ void gen6_rps_idle(struct drm_i915_private *dev_priv)
+ {
++	unsigned long flags;
+ 	/* Flush our bottom-half so that it does not race with us
+ 	 * setting the idle frequency and so that it is bounded by
+ 	 * our rpm wakeref. And then disable the interrupts to stop any
+@@ -6127,16 +6128,17 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv)
+ 	}
+ 	mutex_unlock(&dev_priv->rps.hw_lock);
+ 
+-	spin_lock(&dev_priv->rps.client_lock);
++	spin_lock_irqsave(&dev_priv->rps.client_lock, flags);
+ 	while (!list_empty(&dev_priv->rps.clients))
+ 		list_del_init(dev_priv->rps.clients.next);
+-	spin_unlock(&dev_priv->rps.client_lock);
++	spin_unlock_irqrestore(&dev_priv->rps.client_lock, flags);
+ }
+ 
+ void gen6_rps_boost(struct drm_i915_private *dev_priv,
+ 		    struct intel_rps_client *rps,
+ 		    unsigned long submitted)
+ {
++	unsigned long flags;
+ 	/* This is intentionally racy! We peek at the state here, then
+ 	 * validate inside the RPS worker.
+ 	 */
+@@ -6151,14 +6153,14 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv,
+ 	if (rps && time_after(jiffies, submitted + DRM_I915_THROTTLE_JIFFIES))
+ 		rps = NULL;
+ 
+-	spin_lock(&dev_priv->rps.client_lock);
++	spin_lock_irqsave(&dev_priv->rps.client_lock, flags);
+ 	if (rps == NULL || list_empty(&rps->link)) {
+-		spin_lock_irq(&dev_priv->irq_lock);
++		spin_lock(&dev_priv->irq_lock);
+ 		if (dev_priv->rps.interrupts_enabled) {
+ 			dev_priv->rps.client_boost = true;
+ 			schedule_work(&dev_priv->rps.work);
+ 		}
+-		spin_unlock_irq(&dev_priv->irq_lock);
++		spin_unlock(&dev_priv->irq_lock);
+ 
+ 		if (rps != NULL) {
+ 			list_add(&rps->link, &dev_priv->rps.clients);
+@@ -6166,7 +6168,7 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv,
+ 		} else
+ 			dev_priv->rps.boosts++;
+ 	}
+-	spin_unlock(&dev_priv->rps.client_lock);
++	spin_unlock_irqrestore(&dev_priv->rps.client_lock, flags);
+ }
+ 
+ int intel_set_rps(struct drm_i915_private *dev_priv, u8 val)
diff --git a/kernel-armv7hl-debug.config b/kernel-armv7hl-debug.config
index fca8a9142..620432104 100644
--- a/kernel-armv7hl-debug.config
+++ b/kernel-armv7hl-debug.config
@@ -5942,8 +5942,8 @@ CONFIG_SUN5I_CCU=y
 CONFIG_SUN6I_A31_CCU=y
 CONFIG_SUN8I_A23_CCU=y
 CONFIG_SUN8I_A33_CCU=y
-# CONFIG_SUN8I_A83T_CCU is not set
-# CONFIG_SUN8I_DE2_CCU is not set
+CONFIG_SUN8I_A83T_CCU=y
+CONFIG_SUN8I_DE2_CCU=y
 CONFIG_SUN8I_H3_CCU=y
 CONFIG_SUN8I_R_CCU=y
 CONFIG_SUN8I_V3S_CCU=y
diff --git a/kernel-armv7hl-lpae-debug.config b/kernel-armv7hl-lpae-debug.config
index a863280bd..93b26839c 100644
--- a/kernel-armv7hl-lpae-debug.config
+++ b/kernel-armv7hl-lpae-debug.config
@@ -5546,8 +5546,8 @@ CONFIG_SUN5I_CCU=y
 CONFIG_SUN6I_A31_CCU=y
 CONFIG_SUN8I_A23_CCU=y
 CONFIG_SUN8I_A33_CCU=y
-# CONFIG_SUN8I_A83T_CCU is not set
-# CONFIG_SUN8I_DE2_CCU is not set
+CONFIG_SUN8I_A83T_CCU=y
+CONFIG_SUN8I_DE2_CCU=y
 CONFIG_SUN8I_H3_CCU=y
 CONFIG_SUN8I_R_CCU=y
 CONFIG_SUN8I_V3S_CCU=y
diff --git a/kernel-armv7hl-lpae.config b/kernel-armv7hl-lpae.config
index ea09c1575..0cf75cc33 100644
--- a/kernel-armv7hl-lpae.config
+++ b/kernel-armv7hl-lpae.config
@@ -5523,8 +5523,8 @@ CONFIG_SUN5I_CCU=y
 CONFIG_SUN6I_A31_CCU=y
 CONFIG_SUN8I_A23_CCU=y
 CONFIG_SUN8I_A33_CCU=y
-# CONFIG_SUN8I_A83T_CCU is not set
-# CONFIG_SUN8I_DE2_CCU is not set
+CONFIG_SUN8I_A83T_CCU=y
+CONFIG_SUN8I_DE2_CCU=y
 CONFIG_SUN8I_H3_CCU=y
 CONFIG_SUN8I_R_CCU=y
 CONFIG_SUN8I_V3S_CCU=y
diff --git a/kernel-armv7hl.config b/kernel-armv7hl.config
index b4f75a2c6..a6a891740 100644
--- a/kernel-armv7hl.config
+++ b/kernel-armv7hl.config
@@ -5919,8 +5919,8 @@ CONFIG_SUN5I_CCU=y
 CONFIG_SUN6I_A31_CCU=y
 CONFIG_SUN8I_A23_CCU=y
 CONFIG_SUN8I_A33_CCU=y
-# CONFIG_SUN8I_A83T_CCU is not set
-# CONFIG_SUN8I_DE2_CCU is not set
+CONFIG_SUN8I_A83T_CCU=y
+CONFIG_SUN8I_DE2_CCU=y
 CONFIG_SUN8I_H3_CCU=y
 CONFIG_SUN8I_R_CCU=y
 CONFIG_SUN8I_V3S_CCU=y
diff --git a/kernel-i686-PAE.config b/kernel-i686-PAE.config
index 1e463a6c0..0d2290e9f 100644
--- a/kernel-i686-PAE.config
+++ b/kernel-i686-PAE.config
@@ -1847,7 +1847,6 @@ CONFIG_HWPOISON_INJECT=m
 CONFIG_HW_RANDOM_AMD=m
 CONFIG_HW_RANDOM_GEODE=m
 CONFIG_HW_RANDOM_INTEL=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
 CONFIG_HW_RANDOM_TPM=m
 CONFIG_HW_RANDOM_VIA=m
diff --git a/kernel-i686-PAEdebug.config b/kernel-i686-PAEdebug.config
index d46d9489e..4ea71a324 100644
--- a/kernel-i686-PAEdebug.config
+++ b/kernel-i686-PAEdebug.config
@@ -1865,7 +1865,6 @@ CONFIG_HWPOISON_INJECT=m
 CONFIG_HW_RANDOM_AMD=m
 CONFIG_HW_RANDOM_GEODE=m
 CONFIG_HW_RANDOM_INTEL=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
 CONFIG_HW_RANDOM_TPM=m
 CONFIG_HW_RANDOM_VIA=m
diff --git a/kernel-i686-debug.config b/kernel-i686-debug.config
index aeca7e425..02e0d60f1 100644
--- a/kernel-i686-debug.config
+++ b/kernel-i686-debug.config
@@ -1865,7 +1865,6 @@ CONFIG_HWPOISON_INJECT=m
 CONFIG_HW_RANDOM_AMD=m
 CONFIG_HW_RANDOM_GEODE=m
 CONFIG_HW_RANDOM_INTEL=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
 CONFIG_HW_RANDOM_TPM=m
 CONFIG_HW_RANDOM_VIA=m
diff --git a/kernel-i686.config b/kernel-i686.config
index 45359f1fe..fb8131b00 100644
--- a/kernel-i686.config
+++ b/kernel-i686.config
@@ -1847,7 +1847,6 @@ CONFIG_HWPOISON_INJECT=m
 CONFIG_HW_RANDOM_AMD=m
 CONFIG_HW_RANDOM_GEODE=m
 CONFIG_HW_RANDOM_INTEL=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
 CONFIG_HW_RANDOM_TPM=m
 CONFIG_HW_RANDOM_VIA=m
diff --git a/kernel-ppc64-debug.config b/kernel-ppc64-debug.config
index 2afb322e3..b990f6a42 100644
--- a/kernel-ppc64-debug.config
+++ b/kernel-ppc64-debug.config
@@ -1763,7 +1763,6 @@ CONFIG_HWLAT_TRACER=y
 CONFIG_HWMON=y
 CONFIG_HWPOISON_INJECT=m
 CONFIG_HW_RANDOM_AMD=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_POWERNV=m
 CONFIG_HW_RANDOM_PSERIES=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
diff --git a/kernel-ppc64.config b/kernel-ppc64.config
index 1d1992524..72751d1fb 100644
--- a/kernel-ppc64.config
+++ b/kernel-ppc64.config
@@ -1745,7 +1745,6 @@ CONFIG_HWLAT_TRACER=y
 CONFIG_HWMON=y
 CONFIG_HWPOISON_INJECT=m
 CONFIG_HW_RANDOM_AMD=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_POWERNV=m
 CONFIG_HW_RANDOM_PSERIES=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
diff --git a/kernel-ppc64le-debug.config b/kernel-ppc64le-debug.config
index 3d1de0b29..26c76c0eb 100644
--- a/kernel-ppc64le-debug.config
+++ b/kernel-ppc64le-debug.config
@@ -1715,7 +1715,6 @@ CONFIG_HWLAT_TRACER=y
 # CONFIG_HWMON_DEBUG_CHIP is not set
 CONFIG_HWMON=y
 CONFIG_HWPOISON_INJECT=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_POWERNV=m
 CONFIG_HW_RANDOM_PSERIES=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
diff --git a/kernel-ppc64le.config b/kernel-ppc64le.config
index ad24e4081..7a2fe0372 100644
--- a/kernel-ppc64le.config
+++ b/kernel-ppc64le.config
@@ -1697,7 +1697,6 @@ CONFIG_HWLAT_TRACER=y
 # CONFIG_HWMON_DEBUG_CHIP is not set
 CONFIG_HWMON=y
 CONFIG_HWPOISON_INJECT=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_POWERNV=m
 CONFIG_HW_RANDOM_PSERIES=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
diff --git a/kernel-ppc64p7-debug.config b/kernel-ppc64p7-debug.config
index 1d3cdd364..01c175992 100644
--- a/kernel-ppc64p7-debug.config
+++ b/kernel-ppc64p7-debug.config
@@ -1714,7 +1714,6 @@ CONFIG_HWLAT_TRACER=y
 # CONFIG_HWMON_DEBUG_CHIP is not set
 CONFIG_HWMON=y
 CONFIG_HWPOISON_INJECT=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_POWERNV=m
 CONFIG_HW_RANDOM_PSERIES=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
diff --git a/kernel-ppc64p7.config b/kernel-ppc64p7.config
index 340f308f9..a3fa9593e 100644
--- a/kernel-ppc64p7.config
+++ b/kernel-ppc64p7.config
@@ -1696,7 +1696,6 @@ CONFIG_HWLAT_TRACER=y
 # CONFIG_HWMON_DEBUG_CHIP is not set
 CONFIG_HWMON=y
 CONFIG_HWPOISON_INJECT=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_POWERNV=m
 CONFIG_HW_RANDOM_PSERIES=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
diff --git a/kernel-s390x-debug.config b/kernel-s390x-debug.config
index 087404e3f..09b51abf8 100644
--- a/kernel-s390x-debug.config
+++ b/kernel-s390x-debug.config
@@ -1673,7 +1673,6 @@ CONFIG_HWLAT_TRACER=y
 # CONFIG_HWMON_DEBUG_CHIP is not set
 # CONFIG_HWMON is not set
 CONFIG_HWPOISON_INJECT=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_S390=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
 CONFIG_HW_RANDOM_TPM=m
diff --git a/kernel-s390x.config b/kernel-s390x.config
index be8c6aae8..dd75124a8 100644
--- a/kernel-s390x.config
+++ b/kernel-s390x.config
@@ -1655,7 +1655,6 @@ CONFIG_HWLAT_TRACER=y
 # CONFIG_HWMON_DEBUG_CHIP is not set
 # CONFIG_HWMON is not set
 CONFIG_HWPOISON_INJECT=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_S390=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
 CONFIG_HW_RANDOM_TPM=m
diff --git a/kernel-x86_64-debug.config b/kernel-x86_64-debug.config
index 890d25cfd..ee49e5b2b 100644
--- a/kernel-x86_64-debug.config
+++ b/kernel-x86_64-debug.config
@@ -1901,7 +1901,6 @@ CONFIG_HWMON=y
 CONFIG_HWPOISON_INJECT=m
 CONFIG_HW_RANDOM_AMD=m
 CONFIG_HW_RANDOM_INTEL=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
 CONFIG_HW_RANDOM_TPM=m
 CONFIG_HW_RANDOM_VIA=m
diff --git a/kernel-x86_64.config b/kernel-x86_64.config
index 71708573e..1977baa4a 100644
--- a/kernel-x86_64.config
+++ b/kernel-x86_64.config
@@ -1883,7 +1883,6 @@ CONFIG_HWMON=y
 CONFIG_HWPOISON_INJECT=m
 CONFIG_HW_RANDOM_AMD=m
 CONFIG_HW_RANDOM_INTEL=m
-CONFIG_HW_RANDOM_OMAP=m
 CONFIG_HW_RANDOM_TIMERIOMEM=m
 CONFIG_HW_RANDOM_TPM=m
 CONFIG_HW_RANDOM_VIA=m
diff --git a/kernel.spec b/kernel.spec
index bedc72ac6..ad001d1c7 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -586,8 +586,13 @@ Patch211: drm-i915-hush-check-crtc-state.patch
 
 # 300 - ARM patches
 
-# a tempory patch for QCOM hardware enablement. Will be gone by F-26 GA
-Patch301: qcom-QDF2432-tmp-errata.patch
+# Reduces a number of primarily info logs to dmesg
+# https://patchwork.freedesktop.org/patch/180737/
+# https://patchwork.freedesktop.org/patch/180554/
+Patch300: drm-cma-reduce-dmesg-logs.patch
+
+# https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c0d8832e78cbfd4a64b7112e34920af4b0b0e60e
+# https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae2e972dae3cea795e9f8f94eb1601213c2d49f0
 
 # http://www.spinics.net/lists/linux-tegra/msg26029.html
 Patch302: usb-phy-tegra-Add-38.4MHz-clock-table-entry.patch
@@ -643,6 +648,9 @@ Patch324: arm-of-restrict-dma-configuration.patch
 # Upstream ACPI fix
 Patch331: arm64-xgene-acpi-fix.patch
 
+# ThunderX fixes
+Patch332: arm64-cavium-fixes.patch
+
 # 400 - IBM (ppc/s390x) patches
 
 # 500 - Temp fixes/CVEs etc
@@ -667,7 +675,6 @@ Patch613: 0013-iio-accel-bmc150-Add-support-for-BOSC0200-ACPI-devic.patch
 Patch615: 0015-i2c-cht-wc-Add-Intel-Cherry-Trail-Whiskey-Cove-SMBUS.patch
 
 # rhbz 1431375
-Patch703: HID-rmi-Make-sure-the-HID-device-is-opened-on-resume.patch
 Patch704: input-rmi4-remove-the-need-for-artifical-IRQ.patch
 
 # rhbz 1476467
@@ -702,6 +709,9 @@ Patch629: 0001-platform-x86-peaq-wmi-Add-DMI-check-before-binding-t.patch
 # rhbz 1482648
 Patch630: Input-synaptics---Disable-kernel-tracking-on-SMBus-devices.patch
 
+# Headed upstream
+Patch631: drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch
+
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -2279,6 +2289,14 @@ fi
 #
 #
 %changelog
+* Thu Oct 12 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.13.6-200
+- Linux v4.13.6
+- Fixes CVE-2017-1000255 (rhbz 1498067 1500335)
+
+* Thu Oct 12 2017 Peter Robinson <pbrobinson@fedoraproject.org>
+- Some minor ARM fixes and cleanups
+- Fixes for Cavium ThunderX plaforms
+
 * Wed Oct 11 2017 Jeremy Cline <jeremy@jcline.org>
 - Fix incorrect updates of uninstantiated keys crash the kernel (rhbz 1498016 1498017)
 
diff --git a/qcom-QDF2432-tmp-errata.patch b/qcom-QDF2432-tmp-errata.patch
deleted file mode 100644
index f7ace4787..000000000
--- a/qcom-QDF2432-tmp-errata.patch
+++ /dev/null
@@ -1,59 +0,0 @@
-From edc7986d4d405daebaf2f66269b353da579fce5f Mon Sep 17 00:00:00 2001
-From: Christopher Covington <cov@codeaurora.org>
-Date: Tue, 31 May 2016 16:19:02 -0400
-Subject: arm64: Workaround for QDF2432 ID_AA64 SR accesses
-
-The ARMv8.0 architecture reserves several system register encodings for
-future use. These encodings should behave as read-only and always return
-zero on a read. As described in Errata 94, the CPU cores in the QDF2432
-errantly cause an instruction abort if an AArch64 MRS instruction attempts
-to read any of the following system register encodings:
-
-	Op0, Op1, CRn, CRm,        Op2
-	3,   0,   C0,  [C4-C7],    [2-3, 6-7]
-	3,   0,   C0,  C3,         [3-7]
-	3,   0,   C0,  [C4,C6,C7], [4-5]
-	3,   0,   C0,  C2,         [6-7]
-
-Naively projecting ARMv8.0 names, this space includes:
-
-	ID_AA64PFR[2-7]_EL1
-	ID_AA64DFR[2-3]_EL1
-	ID_AA64AFR[2-3]_EL1
-	ID_AA64ISAR[2-7]_EL1
-	ID_AA64MMFR[2-7]_EL1
-
-As of v4.8-rc2, Linux only attempts to query one register in this space,
-ID_AA64MMFR2_EL1. As simple workaround, skip that access when the affected
-MIDR is detected.
-
-Signed-off-by: Christopher Covington <cov@codeaurora.org>
----
- arch/arm64/kernel/cpuinfo.c | 4 +++-
- 1 file changed, 3 insertions(+), 1 deletion(-)
-
-diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
-index ed1b84f..790de6b 100644
---- a/arch/arm64/kernel/cpuinfo.c
-+++ b/arch/arm64/kernel/cpuinfo.c
-@@ -325,6 +325,8 @@ static void cpuinfo_detect_icache_policy(struct cpuinfo_arm64 *info)
- 
- static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
- {
-+	bool qdf2432_cpu = read_cpuid_id() == 0x510f2811;
-+
- 	info->reg_cntfrq = arch_timer_get_cntfrq();
- 	info->reg_ctr = read_cpuid_cachetype();
- 	info->reg_dczid = read_cpuid(DCZID_EL0);
-@@ -337,7 +339,7 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
- 	info->reg_id_aa64isar1 = read_cpuid(ID_AA64ISAR1_EL1);
- 	info->reg_id_aa64mmfr0 = read_cpuid(ID_AA64MMFR0_EL1);
- 	info->reg_id_aa64mmfr1 = read_cpuid(ID_AA64MMFR1_EL1);
--	info->reg_id_aa64mmfr2 = read_cpuid(ID_AA64MMFR2_EL1);
-+	info->reg_id_aa64mmfr2 = qdf2432_cpu ? 0 : read_cpuid(ID_AA64MMFR2_EL1);
- 	info->reg_id_aa64pfr0 = read_cpuid(ID_AA64PFR0_EL1);
- 	info->reg_id_aa64pfr1 = read_cpuid(ID_AA64PFR1_EL1);
- 
--- 
-cgit v0.12
-
diff --git a/sources b/sources
index fedd63a3b..b44855500 100644
--- a/sources
+++ b/sources
@@ -1,3 +1,3 @@
 SHA512 (linux-4.13.tar.xz) = a557c2f0303ae618910b7106ff63d9978afddf470f03cb72aa748213e099a0ecd5f3119aea6cbd7b61df30ca6ef3ec57044d524b7babbaabddf8b08b8bafa7d2
 SHA512 (perf-man-4.13.tar.gz) = 9bcc2cd8e56ec583ed2d8e0b0c88e7a94035a1915e40b3177bb02d6c0f10ddd4df9b097b1f5af59efc624226b613e240ddba8ddc2156f3682f992d5455fc5c03
-SHA512 (patch-4.13.5.xz) = de55b07e52e88e3bc5af54c619933a81f535393f20712f38000bffa77ded22c7a16e70e43c28daf576bcc6cd3ad39387b8e1f430e3d22222f572113d2345df48
+SHA512 (patch-4.13.6.xz) = 40e111f3969b622f982bfb75f8c35aa59d9989a627a4511d8e0090b0c7bbcafcc90567434f5166ef2d17831f0beddb52762107e523414523e1877f67f66ca3f7