From 81203d2e5f1c0aaab76584f04d51647c6efc736d Mon Sep 17 00:00:00 2001 From: "Justin M. Forbes" Date: Thu, 23 Apr 2020 08:44:39 -0500 Subject: Linux v5.6.7 --- ...-workaround-runpm-fail-by-disabling-PCI-p.patch | 141 --------------------- ...-gr-gp107-gp108-implement-workaround-for-.patch | 68 ---------- ...MCFG-quirks-for-Tegra194-host-controllers.patch | 2 +- arm64-tegra-fix-pcie.patch | 101 --------------- drm-vc4-Fix-HDMI-mode-validation.patch | 65 ---------- kernel.spec | 15 +-- sources | 2 +- 7 files changed, 6 insertions(+), 388 deletions(-) delete mode 100644 0001-drm-nouveau-workaround-runpm-fail-by-disabling-PCI-p.patch delete mode 100644 0002-drm-nouveau-gr-gp107-gp108-implement-workaround-for-.patch delete mode 100644 arm64-tegra-fix-pcie.patch delete mode 100644 drm-vc4-Fix-HDMI-mode-validation.patch 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 -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 -Cc: Bjorn Helgaas -Cc: Lyude Paul -Cc: Rafael J. Wysocki -Cc: Mika Westerberg -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 ---- - 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 -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 -Reviewed-by: Karol Herbst ---- - .../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" -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 ---- - .../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 -X-Patchwork-Id: 358980 -Message-Id: <20200326122001.22215-1-nsaenzjulienne@suse.de> -To: Eric Anholt , - Daniel Vetter -Cc: Stefan Wahren , f.fainelli@gmail.com, - Dave Stevenson , - David Airlie , linux-kernel@vger.kernel.org, - dri-devel@lists.freedesktop.org, maxime@cerno.tech, - Nicolas Saenz Julienne , - 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 -Suggested-by: Dave Stevenson -Signed-off-by: Nicolas Saenz Julienne -Reviewed-by: Maxime Ripard ---- - 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 61407222f..981f7a1f3 100644 --- a/kernel.spec +++ b/kernel.spec @@ -92,7 +92,7 @@ Summary: The Linux kernel %if 0%{?released_kernel} # Do we have a -stable update to apply? -%define stable_update 6 +%define stable_update 7 # Set rpm version accordingly %if 0%{?stable_update} %define stablerev %{stable_update} @@ -830,8 +830,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 @@ -840,8 +838,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/ @@ -905,12 +901,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 @@ -3006,6 +2996,9 @@ fi # # %changelog +* Thu Apr 23 2020 Justin M. Forbes - 5.6.7-300 +- Linux v5.6.7 + * Tue Apr 21 2020 Justin M. Forbes - 5.6.6-300 - Linux v5.6.6 diff --git a/sources b/sources index c724f6ac8..63e07ca91 100644 --- a/sources +++ b/sources @@ -1,2 +1,2 @@ SHA512 (linux-5.6.tar.xz) = 80846fe2b4e4a7ff471d2dde28a8216ae807a3209f959e93d39ea4fc9a189ea28ec3db9d303b3fe15a28c2cb90e7446876678e93e23353c2d6f262e364a06bc9 -SHA512 (patch-5.6.6.xz) = 63edddca606957ec85114ec76c45fc33a763378ec0ccc2e05af7550ffc3578df832dd5fff8106292aad40faa9d3c0c3d1082274aca14262df23a8040c2067ba0 +SHA512 (patch-5.6.7.xz) = 1d8835bc1b90841a08eaed15202c65e27a584d036c6ea59869a87707bf71521bf3796321e0e730df2fe28b45ad0e19301d53add4d7e2f7fd7371b5061552c86f -- cgit