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

6 files changed, 4 insertions, 386 deletions

diff --git a/0001-drm-nouveau-workaround-runpm-fail-by-disabling-PCI-p.patch b/0001-drm-nouveau-workaround-runpm-fail-by-disabling-PCI-p.patch
deleted file mode 100644
index 1511e4a7a..000000000
--- a/0001-drm-nouveau-workaround-runpm-fail-by-disabling-PCI-p.patch
+++ /dev/null
@@ -1,141 +0,0 @@
-From 7a7662fe09eb2ccd2eb93ce7261aa47c86111b4d Mon Sep 17 00:00:00 2001
-From: Karol Herbst <kherbst@redhat.com>
-Date: Tue, 24 Mar 2020 21:29:23 +0100
-Subject: [PATCH 1/2] drm/nouveau: workaround runpm fail by disabling PCI power
- management on certain intel bridges
-
-Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
-Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
-
-Depending on the used kernel there might be messages like those in demsg:
-
-"nouveau 0000:01:00.0: Refused to change power state, currently in D3"
-"nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config
-space inaccessible)"
-followed by backtraces of kernel crashes or timeouts within nouveau.
-
-It's still unkown why this issue exists, but this is a reliable workaround
-and solves a very annoying issue for user having to choose between a
-crashing kernel or higher power consumption of their Laptops.
-
-Signed-off-by: Karol Herbst <kherbst@redhat.com>
-Cc: Bjorn Helgaas <bhelgaas@google.com>
-Cc: Lyude Paul <lyude@redhat.com>
-Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
-Cc: Mika Westerberg <mika.westerberg@intel.com>
-Cc: linux-pci@vger.kernel.org
-Cc: linux-pm@vger.kernel.org
-Cc: dri-devel@lists.freedesktop.org
-Cc: nouveau@lists.freedesktop.org
-Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
-Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
----
- drivers/gpu/drm/nouveau/nouveau_drm.c | 63 +++++++++++++++++++++++++++
- drivers/gpu/drm/nouveau/nouveau_drv.h |  2 +
- 2 files changed, 65 insertions(+)
-
-diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
-index 6b1629c14dd7..ca4087f5a15b 100644
---- a/drivers/gpu/drm/nouveau/nouveau_drm.c
-+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
-@@ -618,6 +618,64 @@ nouveau_drm_device_fini(struct drm_device *dev)
- 	kfree(drm);
- }
- 
-+/*
-+ * On some Intel PCIe bridge controllers doing a
-+ * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
-+ * Skipping the intermediate D3hot step seems to make it work again. This is
-+ * probably caused by not meeting the expectation the involved AML code has
-+ * when the GPU is put into D3hot state before invoking it.
-+ *
-+ * This leads to various manifestations of this issue:
-+ *  - AML code execution to power on the GPU hits an infinite loop (as the
-+ *    code waits on device memory to change).
-+ *  - kernel crashes, as all PCI reads return -1, which most code isn't able
-+ *    to handle well enough.
-+ *
-+ * In all cases dmesg will contain at least one line like this:
-+ * 'nouveau 0000:01:00.0: Refused to change power state, currently in D3'
-+ * followed by a lot of nouveau timeouts.
-+ *
-+ * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not
-+ * documented PCI config space register 0x248 of the Intel PCIe bridge
-+ * controller (0x1901) in order to change the state of the PCIe link between
-+ * the PCIe port and the GPU. There are alternative code paths using other
-+ * registers, which seem to work fine (executed pre Windows 8):
-+ *  - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
-+ *  - 0xb0 bit 0x10 (link disable)
-+ * Changing the conditions inside the firmware by poking into the relevant
-+ * addresses does resolve the issue, but it seemed to be ACPI private memory
-+ * and not any device accessible memory at all, so there is no portable way of
-+ * changing the conditions.
-+ * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
-+ *
-+ * The only systems where this behavior can be seen are hybrid graphics laptops
-+ * with a secondary Nvidia Maxwell, Pascal or Turing GPU. It's unclear whether
-+ * this issue only occurs in combination with listed Intel PCIe bridge
-+ * controllers and the mentioned GPUs or other devices as well.
-+ *
-+ * documentation on the PCIe bridge controller can be found in the
-+ * "7th Generation Intel® Processor Families for H Platforms Datasheet Volume 2"
-+ * Section "12 PCI Express* Controller (x16) Registers"
-+ */
-+
-+static void quirk_broken_nv_runpm(struct pci_dev *pdev)
-+{
-+	struct drm_device *dev = pci_get_drvdata(pdev);
-+	struct nouveau_drm *drm = nouveau_drm(dev);
-+	struct pci_dev *bridge = pci_upstream_bridge(pdev);
-+
-+	if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
-+		return;
-+
-+	switch (bridge->device) {
-+	case 0x1901:
-+		drm->old_pm_cap = pdev->pm_cap;
-+		pdev->pm_cap = 0;
-+		NV_INFO(drm, "Disabling PCI power management to avoid bug\n");
-+		break;
-+	}
-+}
-+
- static int nouveau_drm_probe(struct pci_dev *pdev,
- 			     const struct pci_device_id *pent)
- {
-@@ -699,6 +757,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
- 	if (ret)
- 		goto fail_drm_dev_init;
- 
-+	quirk_broken_nv_runpm(pdev);
- 	return 0;
- 
- fail_drm_dev_init:
-@@ -734,7 +793,11 @@ static void
- nouveau_drm_remove(struct pci_dev *pdev)
- {
- 	struct drm_device *dev = pci_get_drvdata(pdev);
-+	struct nouveau_drm *drm = nouveau_drm(dev);
- 
-+	/* revert our workaround */
-+	if (drm->old_pm_cap)
-+		pdev->pm_cap = drm->old_pm_cap;
- 	nouveau_drm_device_remove(dev);
- 	pci_disable_device(pdev);
- }
-diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h
-index c2c332fbde97..2a6519737800 100644
---- a/drivers/gpu/drm/nouveau/nouveau_drv.h
-+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
-@@ -140,6 +140,8 @@ struct nouveau_drm {
- 
- 	struct list_head clients;
- 
-+	u8 old_pm_cap;
-+
- 	struct {
- 		struct agp_bridge_data *bridge;
- 		u32 base;
--- 
-2.25.1
-
diff --git a/0002-drm-nouveau-gr-gp107-gp108-implement-workaround-for-.patch b/0002-drm-nouveau-gr-gp107-gp108-implement-workaround-for-.patch
deleted file mode 100644
index 554800010..000000000
--- a/0002-drm-nouveau-gr-gp107-gp108-implement-workaround-for-.patch
+++ /dev/null
@@ -1,68 +0,0 @@
-From 37b556606d1217b4367e622d88cef11c65764386 Mon Sep 17 00:00:00 2001
-From: Ben Skeggs <bskeggs@redhat.com>
-Date: Tue, 31 Mar 2020 16:08:44 +1000
-Subject: [PATCH 2/2] drm/nouveau/gr/gp107,gp108: implement workaround for HW
- hanging during init
-
-Certain boards with GP107/GP108 chipsets hang (often, but randomly) for
-unknown reasons during GR initialisation.
-
-The first tell-tale symptom of this issue is:
-
-nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 409800 [ TIMEOUT ]
-
-appearing in dmesg, likely followed by many other failures being logged.
-
-Karol found this WAR for the issue a while back, but efforts to isolate
-the root cause and proper fix have not yielded success so far.  I've
-modified the original patch to include a few more details, limit it to
-GP107/GP108 by default, and added a config option to override this choice.
-
-Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-Reviewed-by: Karol Herbst <kherbst@redhat.com>
----
- .../gpu/drm/nouveau/nvkm/engine/gr/gf100.c    | 26 +++++++++++++++++++
- 1 file changed, 26 insertions(+)
-
-diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
-index dd8f85b8b3a7..f2f5636efac4 100644
---- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
-+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
-@@ -1981,8 +1981,34 @@ gf100_gr_init_(struct nvkm_gr *base)
- {
- 	struct gf100_gr *gr = gf100_gr(base);
- 	struct nvkm_subdev *subdev = &base->engine.subdev;
-+	struct nvkm_device *device = subdev->device;
-+	bool reset = device->chipset == 0x137 || device->chipset == 0x138;
- 	u32 ret;
- 
-+	/* On certain GP107/GP108 boards, we trigger a weird issue where
-+	 * GR will stop responding to PRI accesses after we've asked the
-+	 * SEC2 RTOS to boot the GR falcons.  This happens with far more
-+	 * frequency when cold-booting a board (ie. returning from D3).
-+	 *
-+	 * The root cause for this is not known and has proven difficult
-+	 * to isolate, with many avenues being dead-ends.
-+	 *
-+	 * A workaround was discovered by Karol, whereby putting GR into
-+	 * reset for an extended period right before initialisation
-+	 * prevents the problem from occuring.
-+	 *
-+	 * XXX: As RM does not require any such workaround, this is more
-+	 *      of a hack than a true fix.
-+	 */
-+	reset = nvkm_boolopt(device->cfgopt, "NvGrResetWar", reset);
-+	if (reset) {
-+		nvkm_mask(device, 0x000200, 0x00001000, 0x00000000);
-+		nvkm_rd32(device, 0x000200);
-+		msleep(50);
-+		nvkm_mask(device, 0x000200, 0x00001000, 0x00001000);
-+		nvkm_rd32(device, 0x000200);
-+	}
-+
- 	nvkm_pmu_pgob(gr->base.engine.subdev.device->pmu, false);
- 
- 	ret = nvkm_falcon_get(&gr->fecs.falcon, subdev);
--- 
-2.25.1
-
diff --git a/PCI-Add-MCFG-quirks-for-Tegra194-host-controllers.patch b/PCI-Add-MCFG-quirks-for-Tegra194-host-controllers.patch
index 6b1090083..1d859bb57 100644
--- a/PCI-Add-MCFG-quirks-for-Tegra194-host-controllers.patch
+++ b/PCI-Add-MCFG-quirks-for-Tegra194-host-controllers.patch
@@ -177,7 +177,7 @@ index ccac43be12ac..5d790ec5bdef 100644
 +			  0x81000000 0x00 0x00000000 0x1f 0xffff0000 0x0 0x00010000>; /* downstream I/O (64KB) */
  	};
  
- 	sysram@40000000 {
+ 	pcie_ep@14160000 {
 
 From patchwork Fri Jan 10 19:15:00 2020
 Content-Type: text/plain; charset="utf-8"
diff --git a/arm64-tegra-fix-pcie.patch b/arm64-tegra-fix-pcie.patch
deleted file mode 100644
index 3e93a913c..000000000
--- a/arm64-tegra-fix-pcie.patch
+++ /dev/null
@@ -1,101 +0,0 @@
-From 5fc5158c547fc3a2b46cbc6f73b926d8b78cd6e2 Mon Sep 17 00:00:00 2001
-From: "Signed-off-by: Jon Hunter" <jonathanh@nvidia.com>
-Date: Fri, 14 Feb 2020 13:53:53 +0000
-Subject: [PATCH] ARM64: tegra: Fix Tegra194 PCIe compatible string
-
-If the kernel configuration option CONFIG_PCIE_DW_PLAT_HOST is enabled
-then this can cause the kernel to incorrectly probe the generic
-designware PCIe platform driver instead of the Tegra194 designware PCIe
-driver. This causes a boot failure on Tegra194 because the necessary
-configuration to access the hardware is not performed.
-
-The order in which the compatible strings are populated in Device-Tree
-is not relevant in this case, because the kernel will attempt to probe
-the device as soon as a driver is loaded and if the generic designware
-PCIe driver is loaded first, then this driver will be probed first.
-Therefore, to fix this problem, remove the "snps,dw-pcie" string from
-the compatible string as we never want this driver to be probe on
-Tegra194.
-
-Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT")
-
-Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
----
- .../devicetree/bindings/pci/nvidia,tegra194-pcie.txt |  2 +-
- arch/arm64/boot/dts/nvidia/tegra194.dtsi             | 12 ++++++------
- 2 files changed, 7 insertions(+), 7 deletions(-)
-
-diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
-index b739f92da58e..1f90eb39870b 100644
---- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
-+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
-@@ -118,7 +118,7 @@ Tegra194:
- --------
- 
- 	pcie@14180000 {
--		compatible = "nvidia,tegra194-pcie", "snps,dw-pcie";
-+		compatible = "nvidia,tegra194-pcie";
- 		power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8B>;
- 		reg = <0x00 0x14180000 0x0 0x00020000   /* appl registers (128K)      */
- 		       0x00 0x38000000 0x0 0x00040000   /* configuration space (256K) */
-diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
-index ccac43be12ac..4c58cb10fb9c 100644
---- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
-+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
-@@ -1208,7 +1208,7 @@ sor3: sor@15bc0000 {
- 	};
- 
- 	pcie@14100000 {
--		compatible = "nvidia,tegra194-pcie", "snps,dw-pcie";
-+		compatible = "nvidia,tegra194-pcie";
- 		power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX1A>;
- 		reg = <0x00 0x14100000 0x0 0x00020000   /* appl registers (128K)      */
- 		       0x00 0x30000000 0x0 0x00040000   /* configuration space (256K) */
-@@ -1253,7 +1253,7 @@ pcie@14100000 {
- 	};
- 
- 	pcie@14120000 {
--		compatible = "nvidia,tegra194-pcie", "snps,dw-pcie";
-+		compatible = "nvidia,tegra194-pcie";
- 		power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX1A>;
- 		reg = <0x00 0x14120000 0x0 0x00020000   /* appl registers (128K)      */
- 		       0x00 0x32000000 0x0 0x00040000   /* configuration space (256K) */
-@@ -1298,7 +1298,7 @@ pcie@14120000 {
- 	};
- 
- 	pcie@14140000 {
--		compatible = "nvidia,tegra194-pcie", "snps,dw-pcie";
-+		compatible = "nvidia,tegra194-pcie";
- 		power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX1A>;
- 		reg = <0x00 0x14140000 0x0 0x00020000   /* appl registers (128K)      */
- 		       0x00 0x34000000 0x0 0x00040000   /* configuration space (256K) */
-@@ -1343,7 +1343,7 @@ pcie@14140000 {
- 	};
- 
- 	pcie@14160000 {
--		compatible = "nvidia,tegra194-pcie", "snps,dw-pcie";
-+		compatible = "nvidia,tegra194-pcie";
- 		power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX4A>;
- 		reg = <0x00 0x14160000 0x0 0x00020000   /* appl registers (128K)      */
- 		       0x00 0x36000000 0x0 0x00040000   /* configuration space (256K) */
-@@ -1388,7 +1388,7 @@ pcie@14160000 {
- 	};
- 
- 	pcie@14180000 {
--		compatible = "nvidia,tegra194-pcie", "snps,dw-pcie";
-+		compatible = "nvidia,tegra194-pcie";
- 		power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8B>;
- 		reg = <0x00 0x14180000 0x0 0x00020000   /* appl registers (128K)      */
- 		       0x00 0x38000000 0x0 0x00040000   /* configuration space (256K) */
-@@ -1433,7 +1433,7 @@ pcie@14180000 {
- 	};
- 
- 	pcie@141a0000 {
--		compatible = "nvidia,tegra194-pcie", "snps,dw-pcie";
-+		compatible = "nvidia,tegra194-pcie";
- 		power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8A>;
- 		reg = <0x00 0x141a0000 0x0 0x00020000   /* appl registers (128K)      */
- 		       0x00 0x3a000000 0x0 0x00040000   /* configuration space (256K) */
--- 
-2.24.1
-
diff --git a/drm-vc4-Fix-HDMI-mode-validation.patch b/drm-vc4-Fix-HDMI-mode-validation.patch
deleted file mode 100644
index 224c8fa27..000000000
--- a/drm-vc4-Fix-HDMI-mode-validation.patch
+++ /dev/null
@@ -1,65 +0,0 @@
-From patchwork Thu Mar 26 12:20:01 2020
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: drm/vc4: Fix HDMI mode validation
-From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
-X-Patchwork-Id: 358980
-Message-Id: <20200326122001.22215-1-nsaenzjulienne@suse.de>
-To: Eric Anholt <eric@anholt.net>,
-	Daniel Vetter <daniel.vetter@ffwll.ch>
-Cc: Stefan Wahren <stefan.wahren@i2se.com>, f.fainelli@gmail.com,
- Dave Stevenson <dave.stevenson@raspberrypi.com>,
- David Airlie <airlied@linux.ie>, linux-kernel@vger.kernel.org,
- dri-devel@lists.freedesktop.org, maxime@cerno.tech,
- Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
- linux-rpi-kernel@lists.infradead.org
-Date: Thu, 26 Mar 2020 13:20:01 +0100
-
-Current mode validation impedes setting up some video modes which should
-be supported otherwise. Namely 1920x1200@60Hz.
-
-Fix this by lowering the minimum HDMI state machine clock to pixel clock
-ratio allowed.
-
-Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks")
-Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
-Suggested-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
-Reviewed-by: Maxime Ripard <mripard@kernel.org>
----
- drivers/gpu/drm/vc4/vc4_hdmi.c | 20 ++++++++++++++++----
- 1 file changed, 16 insertions(+), 4 deletions(-)
-
-diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
-index cea18dc15f77..340719238753 100644
---- a/drivers/gpu/drm/vc4/vc4_hdmi.c
-+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
-@@ -681,11 +681,23 @@ static enum drm_mode_status
- vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
- 			    const struct drm_display_mode *mode)
- {
--	/* HSM clock must be 108% of the pixel clock.  Additionally,
--	 * the AXI clock needs to be at least 25% of pixel clock, but
--	 * HSM ends up being the limiting factor.
-+	/*
-+	 * As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
-+	 * be faster than pixel clock, infinitesimally faster, tested in
-+	 * simulation. Otherwise, exact value is unimportant for HDMI
-+	 * operation." This conflicts with bcm2835's vc4 documentation, which
-+	 * states HSM's clock has to be at least 108% of the pixel clock.
-+	 *
-+	 * Real life tests reveal that vc4's firmware statement holds up, and
-+	 * users are able to use pixel clocks closer to HSM's, namely for
-+	 * 1920x1200@60Hz. So it was decided to have leave a 1% margin between
-+	 * both clocks. Which, for RPi0-3 implies a maximum pixel clock of
-+	 * 162MHz.
-+	 *
-+	 * Additionally, the AXI clock needs to be at least 25% of
-+	 * pixel clock, but HSM ends up being the limiting factor.
- 	 */
--	if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100))
-+	if (mode->clock > HSM_CLOCK_FREQ / (1000 * 101 / 100))
- 		return MODE_CLOCK_HIGH;
- 
- 	return MODE_OK;
diff --git a/kernel.spec b/kernel.spec
index df390684c..75c59e34e 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -849,8 +849,6 @@ Patch312: bcm2835-irqchip-Quiesce-IRQs-left-enabled-by-bootloader.patch
 Patch313: ARM-dts-bcm2711-Move-emmc2-into-its-own-bus.patch
 # Upstream commit f87391eec2c5 thread: https://www.spinics.net/lists/linux-mmc/msg58036.html
 Patch314: arm-bcm2711-mmc-sdhci-iproc-Add-custom-set_power-callback.patch
-# https://patchwork.freedesktop.org/patch/358980/
-Patch315: drm-vc4-Fix-HDMI-mode-validation.patch
 # Upstream commit 57b76faf1d78
 Patch316: arm-bcm2835-serial-8250_early-support-aux-uart.patch
 
@@ -859,8 +857,6 @@ Patch316: arm-bcm2835-serial-8250_early-support-aux-uart.patch
 Patch320: ARM64-Tegra-fixes.patch
 # http://patchwork.ozlabs.org/patch/1230891/
 Patch321: arm64-serial-8250_tegra-Create-Tegra-specific-8250-driver.patch
-# https://lkml.org/lkml/2020/2/14/401
-Patch323: arm64-tegra-fix-pcie.patch
 # http://patchwork.ozlabs.org/patch/1243162/
 Patch324: regulator-pwm-Don-t-warn-on-probe-deferral.patch
 # http://patchwork.ozlabs.org/patch/1243112/
@@ -924,12 +920,6 @@ Patch509: drm-i915-backports.patch
 # https://patchwork.ozlabs.org/patch/1260523/
 Patch511: e1000e-bump-up-timeout-to-wait-when-ME-un-configure-ULP-mode.patch
 
-# nouveau runpm and secboot fixes
-# Accepted nouveau upstream https://github.com/skeggsb/nouveau/commit/f5755e7069d4acbcce1a93692421f358241ead7b
-Patch513: 0001-drm-nouveau-workaround-runpm-fail-by-disabling-PCI-p.patch
-# Accepted nouveau upstream https://github.com/skeggsb/nouveau/commit/41c6a13e8143af71928749ea9895d2ebc2fb4ffd
-Patch514: 0002-drm-nouveau-gr-gp107-gp108-implement-workaround-for-.patch
-
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -3028,6 +3018,9 @@ fi
 #
 #
 %changelog
+* Thu Apr 23 2020 Justin M. Forbes <jforbes@fedoraproject.org> - 5.6.7-300
+- Linux v5.6.7
+
 * Tue Apr 21 2020 Justin M. Forbes <jforbes@fedoraproject.org> - 5.6.6-300
 - Linux v5.6.6