From: Greg Kroah-Hartman Date: Sat, 12 Feb 2022 09:46:52 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v4.9.302~39 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=e59ea16bce461ca690902611e799b5a15b71b525;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: acpi-iort-check-node-revision-for-pmcg-resources.patch arm-dts-fix-boot-regression-on-skomer.patch arm-dts-imx23-evk-remove-mx23_pad_ssp1_detect-from-hog-group.patch arm-socfpga-fix-missing-reset_controller.patch drm-rockchip-vop-correct-rk3399-vop-register-fields.patch nvme-tcp-fix-bogus-request-completion-when-failing-to-send-aer.patch pm-s2idle-acpi-fix-wakeup-interrupts-handling.patch riscv-fix-build-with-binutils-2.38.patch --- diff --git a/queue-5.10/acpi-iort-check-node-revision-for-pmcg-resources.patch b/queue-5.10/acpi-iort-check-node-revision-for-pmcg-resources.patch new file mode 100644 index 00000000000..9ea5430fe61 --- /dev/null +++ b/queue-5.10/acpi-iort-check-node-revision-for-pmcg-resources.patch @@ -0,0 +1,55 @@ +From da5fb9e1ad3fbf632dce735f1bdad257ca528499 Mon Sep 17 00:00:00 2001 +From: Robin Murphy +Date: Thu, 3 Feb 2022 19:31:24 +0000 +Subject: ACPI/IORT: Check node revision for PMCG resources + +From: Robin Murphy + +commit da5fb9e1ad3fbf632dce735f1bdad257ca528499 upstream. + +The original version of the IORT PMCG definition had an oversight +wherein there was no way to describe the second register page for an +implementation using the recommended RELOC_CTRS feature. Although the +spec was fixed, and the final patches merged to ACPICA and Linux written +against the new version, it seems that some old firmware based on the +original revision has survived and turned up in the wild. + +Add a check for the original PMCG definition, and avoid filling in the +second memory resource with nonsense if so. Otherwise it is likely that +something horrible will happen when the PMCG driver attempts to probe. + +Reported-by: Michael Petlan +Fixes: 24e516049360 ("ACPI/IORT: Add support for PMCG") +Cc: # 5.2.x +Signed-off-by: Robin Murphy +Acked-by: Lorenzo Pieralisi +Link: https://lore.kernel.org/r/75628ae41c257fb73588f7bf1c4459160e04be2b.1643916258.git.robin.murphy@arm.com +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/arm64/iort.c | 14 +++++++++++--- + 1 file changed, 11 insertions(+), 3 deletions(-) + +--- a/drivers/acpi/arm64/iort.c ++++ b/drivers/acpi/arm64/iort.c +@@ -1454,9 +1454,17 @@ static void __init arm_smmu_v3_pmcg_init + res[0].start = pmcg->page0_base_address; + res[0].end = pmcg->page0_base_address + SZ_4K - 1; + res[0].flags = IORESOURCE_MEM; +- res[1].start = pmcg->page1_base_address; +- res[1].end = pmcg->page1_base_address + SZ_4K - 1; +- res[1].flags = IORESOURCE_MEM; ++ /* ++ * The initial version in DEN0049C lacked a way to describe register ++ * page 1, which makes it broken for most PMCG implementations; in ++ * that case, just let the driver fail gracefully if it expects to ++ * find a second memory resource. ++ */ ++ if (node->revision > 0) { ++ res[1].start = pmcg->page1_base_address; ++ res[1].end = pmcg->page1_base_address + SZ_4K - 1; ++ res[1].flags = IORESOURCE_MEM; ++ } + + if (pmcg->overflow_gsiv) + acpi_iort_register_irq(pmcg->overflow_gsiv, "overflow", diff --git a/queue-5.10/arm-dts-fix-boot-regression-on-skomer.patch b/queue-5.10/arm-dts-fix-boot-regression-on-skomer.patch new file mode 100644 index 00000000000..7a0f2eb5691 --- /dev/null +++ b/queue-5.10/arm-dts-fix-boot-regression-on-skomer.patch @@ -0,0 +1,35 @@ +From d9058d6a0e92d8e4a00855f8fe204792f42794db Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Sun, 6 Feb 2022 00:53:12 +0100 +Subject: ARM: dts: Fix boot regression on Skomer + +From: Linus Walleij + +commit d9058d6a0e92d8e4a00855f8fe204792f42794db upstream. + +The signal routing on the Skomer board was incorrect making +it impossible to mount root from the SD card. Fix this up. + +Signed-off-by: Linus Walleij +Cc: stable@vger.kernel.org +Cc: Stefan Hansson +Link: https://lore.kernel.org/r/20220205235312.446730-1-linus.walleij@linaro.org' +Signed-off-by: Arnd Bergmann +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/boot/dts/ste-ux500-samsung-skomer.dts | 4 ---- + 1 file changed, 4 deletions(-) + +--- a/arch/arm/boot/dts/ste-ux500-samsung-skomer.dts ++++ b/arch/arm/boot/dts/ste-ux500-samsung-skomer.dts +@@ -154,10 +154,6 @@ + cap-sd-highspeed; + cap-mmc-highspeed; + /* All direction control is used */ +- st,sig-dir-cmd; +- st,sig-dir-dat0; +- st,sig-dir-dat2; +- st,sig-dir-dat31; + st,sig-pin-fbclk; + full-pwr-cycle; + vmmc-supply = <&ab8500_ldo_aux3_reg>; diff --git a/queue-5.10/arm-dts-imx23-evk-remove-mx23_pad_ssp1_detect-from-hog-group.patch b/queue-5.10/arm-dts-imx23-evk-remove-mx23_pad_ssp1_detect-from-hog-group.patch new file mode 100644 index 00000000000..3713f13a613 --- /dev/null +++ b/queue-5.10/arm-dts-imx23-evk-remove-mx23_pad_ssp1_detect-from-hog-group.patch @@ -0,0 +1,41 @@ +From 42c9b28e6862d16db82a56f5667cf4d1f6658cf6 Mon Sep 17 00:00:00 2001 +From: Fabio Estevam +Date: Mon, 27 Dec 2021 13:14:02 -0300 +Subject: ARM: dts: imx23-evk: Remove MX23_PAD_SSP1_DETECT from hog group + +From: Fabio Estevam + +commit 42c9b28e6862d16db82a56f5667cf4d1f6658cf6 upstream. + +Currently, SD card fails to mount due to the following pinctrl error: + +[ 11.170000] imx23-pinctrl 80018000.pinctrl: pin SSP1_DETECT already requested by 80018000.pinctrl; cannot claim for 80010000.spi +[ 11.180000] imx23-pinctrl 80018000.pinctrl: pin-65 (80010000.spi) status -22 +[ 11.190000] imx23-pinctrl 80018000.pinctrl: could not request pin 65 (SSP1_DETECT) from group mmc0-pins-fixup.0 on device 80018000.pinctrl +[ 11.200000] mxs-mmc 80010000.spi: Error applying setting, reverse things back + +Fix it by removing the MX23_PAD_SSP1_DETECT pin from the hog group as it +is already been used by the mmc0-pins-fixup pinctrl group. + +With this change the rootfs can be mounted and the imx23-evk board can +boot successfully. + +Cc: +Fixes: bc3875f1a61e ("ARM: dts: mxs: modify mx23/mx28 dts files to use pinctrl headers") +Signed-off-by: Fabio Estevam +Signed-off-by: Shawn Guo +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/boot/dts/imx23-evk.dts | 1 - + 1 file changed, 1 deletion(-) + +--- a/arch/arm/boot/dts/imx23-evk.dts ++++ b/arch/arm/boot/dts/imx23-evk.dts +@@ -79,7 +79,6 @@ + MX23_PAD_LCD_RESET__GPIO_1_18 + MX23_PAD_PWM3__GPIO_1_29 + MX23_PAD_PWM4__GPIO_1_30 +- MX23_PAD_SSP1_DETECT__SSP1_DETECT + >; + fsl,drive-strength = ; + fsl,voltage = ; diff --git a/queue-5.10/arm-socfpga-fix-missing-reset_controller.patch b/queue-5.10/arm-socfpga-fix-missing-reset_controller.patch new file mode 100644 index 00000000000..fcae107ff3e --- /dev/null +++ b/queue-5.10/arm-socfpga-fix-missing-reset_controller.patch @@ -0,0 +1,46 @@ +From 3037b174b1876aae6b2d1a27a878c681c78ccadc Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Mon, 7 Feb 2022 09:44:04 +0100 +Subject: ARM: socfpga: fix missing RESET_CONTROLLER + +From: Krzysztof Kozlowski + +commit 3037b174b1876aae6b2d1a27a878c681c78ccadc upstream. + +The SocFPGA machine since commit b3ca9888f35f ("reset: socfpga: add an +early reset driver for SoCFPGA") uses reset controller, so it should +select RESET_CONTROLLER explicitly. Selecting ARCH_HAS_RESET_CONTROLLER +is not enough because it affects only default choice still allowing a +non-buildable configuration: + + /usr/bin/arm-linux-gnueabi-ld: arch/arm/mach-socfpga/socfpga.o: in function `socfpga_init_irq': + arch/arm/mach-socfpga/socfpga.c:56: undefined reference to `socfpga_reset_init' + +Reported-by: kernel test robot +Cc: +Fixes: b3ca9888f35f ("reset: socfpga: add an early reset driver for SoCFPGA") +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Dinh Nguyen +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/mach-socfpga/Kconfig | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/arm/mach-socfpga/Kconfig ++++ b/arch/arm/mach-socfpga/Kconfig +@@ -2,6 +2,7 @@ + menuconfig ARCH_SOCFPGA + bool "Altera SOCFPGA family" + depends on ARCH_MULTI_V7 ++ select ARCH_HAS_RESET_CONTROLLER + select ARCH_SUPPORTS_BIG_ENDIAN + select ARM_AMBA + select ARM_GIC +@@ -18,6 +19,7 @@ menuconfig ARCH_SOCFPGA + select PL310_ERRATA_727915 + select PL310_ERRATA_753970 if PL310 + select PL310_ERRATA_769419 ++ select RESET_CONTROLLER + + if ARCH_SOCFPGA + config SOCFPGA_SUSPEND diff --git a/queue-5.10/drm-rockchip-vop-correct-rk3399-vop-register-fields.patch b/queue-5.10/drm-rockchip-vop-correct-rk3399-vop-register-fields.patch new file mode 100644 index 00000000000..a6f0bdee207 --- /dev/null +++ b/queue-5.10/drm-rockchip-vop-correct-rk3399-vop-register-fields.patch @@ -0,0 +1,73 @@ +From 9da1e9ab82c92d0e89fe44cad2cd7c2d18d64070 Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Wed, 19 Jan 2022 16:11:22 -0800 +Subject: drm/rockchip: vop: Correct RK3399 VOP register fields + +From: Brian Norris + +commit 9da1e9ab82c92d0e89fe44cad2cd7c2d18d64070 upstream. + +Commit 7707f7227f09 ("drm/rockchip: Add support for afbc") switched up +the rk3399_vop_big[] register windows, but it did so incorrectly. + +The biggest problem is in rk3288_win23_data[] vs. +rk3368_win23_data[] .format field: + + RK3288's format: VOP_REG(RK3288_WIN2_CTRL0, 0x7, 1) + RK3368's format: VOP_REG(RK3368_WIN2_CTRL0, 0x3, 5) + +Bits 5:6 (i.e., shift 5, mask 0x3) are correct for RK3399, according to +the TRM. + +There are a few other small differences between the 3288 and 3368 +definitions that were swapped in commit 7707f7227f09. I reviewed them to +the best of my ability according to the RK3399 TRM and fixed them up. + +This fixes IOMMU issues (and display errors) when testing with BG24 +color formats. + +Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc") +Cc: Andrzej Pietrasiewicz +Cc: +Signed-off-by: Brian Norris +Tested-by: Andrzej Pietrasiewicz +Signed-off-by: Heiko Stuebner +Link: https://patchwork.freedesktop.org/patch/msgid/20220119161104.1.I1d01436bef35165a8cdfe9308789c0badb5ff46a@changeid +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c ++++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c +@@ -873,6 +873,7 @@ static const struct vop_win_phy rk3399_w + .enable = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 0), + .format = VOP_REG(RK3288_WIN0_CTRL0, 0x7, 1), + .rb_swap = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 12), ++ .x_mir_en = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 21), + .y_mir_en = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 22), + .act_info = VOP_REG(RK3288_WIN0_ACT_INFO, 0x1fff1fff, 0), + .dsp_info = VOP_REG(RK3288_WIN0_DSP_INFO, 0x0fff0fff, 0), +@@ -883,6 +884,7 @@ static const struct vop_win_phy rk3399_w + .uv_vir = VOP_REG(RK3288_WIN0_VIR, 0x3fff, 16), + .src_alpha_ctl = VOP_REG(RK3288_WIN0_SRC_ALPHA_CTRL, 0xff, 0), + .dst_alpha_ctl = VOP_REG(RK3288_WIN0_DST_ALPHA_CTRL, 0xff, 0), ++ .channel = VOP_REG(RK3288_WIN0_CTRL2, 0xff, 0), + }; + + /* +@@ -893,11 +895,11 @@ static const struct vop_win_phy rk3399_w + static const struct vop_win_data rk3399_vop_win_data[] = { + { .base = 0x00, .phy = &rk3399_win01_data, + .type = DRM_PLANE_TYPE_PRIMARY }, +- { .base = 0x40, .phy = &rk3288_win01_data, ++ { .base = 0x40, .phy = &rk3368_win01_data, + .type = DRM_PLANE_TYPE_OVERLAY }, +- { .base = 0x00, .phy = &rk3288_win23_data, ++ { .base = 0x00, .phy = &rk3368_win23_data, + .type = DRM_PLANE_TYPE_OVERLAY }, +- { .base = 0x50, .phy = &rk3288_win23_data, ++ { .base = 0x50, .phy = &rk3368_win23_data, + .type = DRM_PLANE_TYPE_CURSOR }, + }; + diff --git a/queue-5.10/nvme-tcp-fix-bogus-request-completion-when-failing-to-send-aer.patch b/queue-5.10/nvme-tcp-fix-bogus-request-completion-when-failing-to-send-aer.patch new file mode 100644 index 00000000000..116d8ed607a --- /dev/null +++ b/queue-5.10/nvme-tcp-fix-bogus-request-completion-when-failing-to-send-aer.patch @@ -0,0 +1,42 @@ +From 63573807b27e0faf8065a28b1bbe1cbfb23c0130 Mon Sep 17 00:00:00 2001 +From: Sagi Grimberg +Date: Mon, 7 Feb 2022 00:40:13 +0200 +Subject: nvme-tcp: fix bogus request completion when failing to send AER + +From: Sagi Grimberg + +commit 63573807b27e0faf8065a28b1bbe1cbfb23c0130 upstream. + +AER is not backed by a real request, hence we should not incorrectly +assume that when failing to send a nvme command, it is a normal request +but rather check if this is an aer and if so complete the aer (similar +to the normal completion path). + +Cc: stable@vger.kernel.org +Signed-off-by: Sagi Grimberg +Reviewed-by: Hannes Reinecke +Signed-off-by: Christoph Hellwig +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/host/tcp.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +--- a/drivers/nvme/host/tcp.c ++++ b/drivers/nvme/host/tcp.c +@@ -904,7 +904,15 @@ static inline void nvme_tcp_done_send_re + + static void nvme_tcp_fail_request(struct nvme_tcp_request *req) + { +- nvme_tcp_end_request(blk_mq_rq_from_pdu(req), NVME_SC_HOST_PATH_ERROR); ++ if (nvme_tcp_async_req(req)) { ++ union nvme_result res = {}; ++ ++ nvme_complete_async_event(&req->queue->ctrl->ctrl, ++ cpu_to_le16(NVME_SC_HOST_PATH_ERROR), &res); ++ } else { ++ nvme_tcp_end_request(blk_mq_rq_from_pdu(req), ++ NVME_SC_HOST_PATH_ERROR); ++ } + } + + static int nvme_tcp_try_send_data(struct nvme_tcp_request *req) diff --git a/queue-5.10/pm-s2idle-acpi-fix-wakeup-interrupts-handling.patch b/queue-5.10/pm-s2idle-acpi-fix-wakeup-interrupts-handling.patch new file mode 100644 index 00000000000..d7c9cc88e19 --- /dev/null +++ b/queue-5.10/pm-s2idle-acpi-fix-wakeup-interrupts-handling.patch @@ -0,0 +1,175 @@ +From cb1f65c1e1424a4b5e4a86da8aa3b8fd8459c8ec Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Fri, 4 Feb 2022 18:35:22 +0100 +Subject: PM: s2idle: ACPI: Fix wakeup interrupts handling + +From: Rafael J. Wysocki + +commit cb1f65c1e1424a4b5e4a86da8aa3b8fd8459c8ec upstream. + +After commit e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race +related to the EC GPE") wakeup interrupts occurring immediately after +the one discarded by acpi_s2idle_wake() may be missed. Moreover, if +the SCI triggers again immediately after the rearming in +acpi_s2idle_wake(), that wakeup may be missed too. + +The problem is that pm_system_irq_wakeup() only calls pm_system_wakeup() +when pm_wakeup_irq is 0, but that's not the case any more after the +interrupt causing acpi_s2idle_wake() to run until pm_wakeup_irq is +cleared by the pm_wakeup_clear() call in s2idle_loop(). However, +there may be wakeup interrupts occurring in that time frame and if +that happens, they will be missed. + +To address that issue first move the clearing of pm_wakeup_irq to +the point at which it is known that the interrupt causing +acpi_s2idle_wake() to tun will be discarded, before rearming the SCI +for wakeup. Moreover, because that only reduces the size of the +time window in which the issue may manifest itself, allow +pm_system_irq_wakeup() to register two second wakeup interrupts in +a row and, when discarding the first one, replace it with the second +one. [Of course, this assumes that only one wakeup interrupt can be +discarded in one go, but currently that is the case and I am not +aware of any plans to change that.] + +Fixes: e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE") +Cc: 5.4+ # 5.4+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/sleep.c | 1 + + drivers/base/power/wakeup.c | 41 ++++++++++++++++++++++++++++++++++------- + include/linux/suspend.h | 4 ++-- + kernel/power/main.c | 5 ++++- + kernel/power/process.c | 2 +- + kernel/power/suspend.c | 2 -- + 6 files changed, 42 insertions(+), 13 deletions(-) + +--- a/drivers/acpi/sleep.c ++++ b/drivers/acpi/sleep.c +@@ -1040,6 +1040,7 @@ static bool acpi_s2idle_wake(void) + return true; + } + ++ pm_wakeup_clear(acpi_sci_irq); + rearm_wake_irq(acpi_sci_irq); + } + +--- a/drivers/base/power/wakeup.c ++++ b/drivers/base/power/wakeup.c +@@ -34,7 +34,8 @@ suspend_state_t pm_suspend_target_state; + bool events_check_enabled __read_mostly; + + /* First wakeup IRQ seen by the kernel in the last cycle. */ +-unsigned int pm_wakeup_irq __read_mostly; ++static unsigned int wakeup_irq[2] __read_mostly; ++static DEFINE_RAW_SPINLOCK(wakeup_irq_lock); + + /* If greater than 0 and the system is suspending, terminate the suspend. */ + static atomic_t pm_abort_suspend __read_mostly; +@@ -941,19 +942,45 @@ void pm_system_cancel_wakeup(void) + atomic_dec_if_positive(&pm_abort_suspend); + } + +-void pm_wakeup_clear(bool reset) ++void pm_wakeup_clear(unsigned int irq_number) + { +- pm_wakeup_irq = 0; +- if (reset) ++ raw_spin_lock_irq(&wakeup_irq_lock); ++ ++ if (irq_number && wakeup_irq[0] == irq_number) ++ wakeup_irq[0] = wakeup_irq[1]; ++ else ++ wakeup_irq[0] = 0; ++ ++ wakeup_irq[1] = 0; ++ ++ raw_spin_unlock_irq(&wakeup_irq_lock); ++ ++ if (!irq_number) + atomic_set(&pm_abort_suspend, 0); + } + + void pm_system_irq_wakeup(unsigned int irq_number) + { +- if (pm_wakeup_irq == 0) { +- pm_wakeup_irq = irq_number; ++ unsigned long flags; ++ ++ raw_spin_lock_irqsave(&wakeup_irq_lock, flags); ++ ++ if (wakeup_irq[0] == 0) ++ wakeup_irq[0] = irq_number; ++ else if (wakeup_irq[1] == 0) ++ wakeup_irq[1] = irq_number; ++ else ++ irq_number = 0; ++ ++ raw_spin_unlock_irqrestore(&wakeup_irq_lock, flags); ++ ++ if (irq_number) + pm_system_wakeup(); +- } ++} ++ ++unsigned int pm_wakeup_irq(void) ++{ ++ return wakeup_irq[0]; + } + + /** +--- a/include/linux/suspend.h ++++ b/include/linux/suspend.h +@@ -496,14 +496,14 @@ extern void ksys_sync_helper(void); + + /* drivers/base/power/wakeup.c */ + extern bool events_check_enabled; +-extern unsigned int pm_wakeup_irq; + extern suspend_state_t pm_suspend_target_state; + + extern bool pm_wakeup_pending(void); + extern void pm_system_wakeup(void); + extern void pm_system_cancel_wakeup(void); +-extern void pm_wakeup_clear(bool reset); ++extern void pm_wakeup_clear(unsigned int irq_number); + extern void pm_system_irq_wakeup(unsigned int irq_number); ++extern unsigned int pm_wakeup_irq(void); + extern bool pm_get_wakeup_count(unsigned int *count, bool block); + extern bool pm_save_wakeup_count(unsigned int count); + extern void pm_wakep_autosleep_enabled(bool set); +--- a/kernel/power/main.c ++++ b/kernel/power/main.c +@@ -504,7 +504,10 @@ static ssize_t pm_wakeup_irq_show(struct + struct kobj_attribute *attr, + char *buf) + { +- return pm_wakeup_irq ? sprintf(buf, "%u\n", pm_wakeup_irq) : -ENODATA; ++ if (!pm_wakeup_irq()) ++ return -ENODATA; ++ ++ return sprintf(buf, "%u\n", pm_wakeup_irq()); + } + + power_attr_ro(pm_wakeup_irq); +--- a/kernel/power/process.c ++++ b/kernel/power/process.c +@@ -134,7 +134,7 @@ int freeze_processes(void) + if (!pm_freezing) + atomic_inc(&system_freezing_cnt); + +- pm_wakeup_clear(true); ++ pm_wakeup_clear(0); + pr_info("Freezing user space processes ... "); + pm_freezing = true; + error = try_to_freeze_tasks(true); +--- a/kernel/power/suspend.c ++++ b/kernel/power/suspend.c +@@ -138,8 +138,6 @@ static void s2idle_loop(void) + break; + } + +- pm_wakeup_clear(false); +- + s2idle_enter(); + } + diff --git a/queue-5.10/riscv-fix-build-with-binutils-2.38.patch b/queue-5.10/riscv-fix-build-with-binutils-2.38.patch new file mode 100644 index 00000000000..d206d9577f0 --- /dev/null +++ b/queue-5.10/riscv-fix-build-with-binutils-2.38.patch @@ -0,0 +1,50 @@ +From 6df2a016c0c8a3d0933ef33dd192ea6606b115e3 Mon Sep 17 00:00:00 2001 +From: Aurelien Jarno +Date: Wed, 26 Jan 2022 18:14:42 +0100 +Subject: riscv: fix build with binutils 2.38 + +From: Aurelien Jarno + +commit 6df2a016c0c8a3d0933ef33dd192ea6606b115e3 upstream. + +From version 2.38, binutils default to ISA spec version 20191213. This +means that the csr read/write (csrr*/csrw*) instructions and fence.i +instruction has separated from the `I` extension, become two standalone +extensions: Zicsr and Zifencei. As the kernel uses those instruction, +this causes the following build failure: + + CC arch/riscv/kernel/vdso/vgettimeofday.o + <>/arch/riscv/include/asm/vdso/gettimeofday.h: Assembler messages: + <>/arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode `csrr a5,0xc01' + <>/arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode `csrr a5,0xc01' + <>/arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode `csrr a5,0xc01' + <>/arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode `csrr a5,0xc01' + +The fix is to specify those extensions explicitely in -march. However as +older binutils version do not support this, we first need to detect +that. + +Signed-off-by: Aurelien Jarno +Tested-by: Alexandre Ghiti +Cc: stable@vger.kernel.org +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/Makefile | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/arch/riscv/Makefile ++++ b/arch/riscv/Makefile +@@ -50,6 +50,12 @@ riscv-march-$(CONFIG_ARCH_RV32I) := rv32 + riscv-march-$(CONFIG_ARCH_RV64I) := rv64ima + riscv-march-$(CONFIG_FPU) := $(riscv-march-y)fd + riscv-march-$(CONFIG_RISCV_ISA_C) := $(riscv-march-y)c ++ ++# Newer binutils versions default to ISA spec version 20191213 which moves some ++# instructions from the I extension to the Zicsr and Zifencei extensions. ++toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(riscv-march-y)_zicsr_zifencei) ++riscv-march-$(toolchain-need-zicsr-zifencei) := $(riscv-march-y)_zicsr_zifencei ++ + KBUILD_CFLAGS += -march=$(subst fd,,$(riscv-march-y)) + KBUILD_AFLAGS += -march=$(riscv-march-y) + diff --git a/queue-5.10/series b/queue-5.10/series index 4b649eb3fad..5f38117e0f0 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -39,3 +39,11 @@ kvm-nvmx-evmcs-filter-out-vm_exit_save_vmx_preemptio.patch kvm-nvmx-also-filter-msr_ia32_vmx_true_pinbased_ctls.patch kvm-svm-don-t-kill-sev-guest-if-smap-erratum-trigger.patch kvm-vmx-set-vmcs.pending_dbg.bs-on-db-in-sti-movss-b.patch +riscv-fix-build-with-binutils-2.38.patch +arm-dts-imx23-evk-remove-mx23_pad_ssp1_detect-from-hog-group.patch +arm-dts-fix-boot-regression-on-skomer.patch +arm-socfpga-fix-missing-reset_controller.patch +nvme-tcp-fix-bogus-request-completion-when-failing-to-send-aer.patch +acpi-iort-check-node-revision-for-pmcg-resources.patch +pm-s2idle-acpi-fix-wakeup-interrupts-handling.patch +drm-rockchip-vop-correct-rk3399-vop-register-fields.patch