From: Sasha Levin Date: Sun, 13 Dec 2020 23:22:39 +0000 (-0500) Subject: Fixes for 5.4 X-Git-Tag: v5.10.1~24 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=c1a74c668695d1e25d5044b293425f84fa79f78a;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.4 Signed-off-by: Sasha Levin --- diff --git a/queue-5.4/arc-stack-unwinding-don-t-assume-non-current-task-is.patch b/queue-5.4/arc-stack-unwinding-don-t-assume-non-current-task-is.patch new file mode 100644 index 00000000000..fb36d6f9943 --- /dev/null +++ b/queue-5.4/arc-stack-unwinding-don-t-assume-non-current-task-is.patch @@ -0,0 +1,96 @@ +From b684c6b60dd90d6ef802f4094b4c3f2c13c1c99a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Nov 2020 16:59:27 -0800 +Subject: ARC: stack unwinding: don't assume non-current task is sleeping + +From: Vineet Gupta + +[ Upstream commit e42404fa10fd11fe72d0a0e149a321d10e577715 ] + +To start stack unwinding (SP, PC and BLINK) are needed. When the +explicit execution context (pt_regs etc) is not available, unwinder +assumes the task is sleeping (in __switch_to()) and fetches SP and BLINK +from kernel mode stack. + +But this assumption is not true, specially in a SMP system, when top +runs on 1 core, there may be active running processes on all cores. + +So when unwinding non courrent tasks, ensure they are NOT running. + +And while at it, handle the self unwinding case explicitly. + +This came out of investigation of a customer reported hang with +rcutorture+top + +Link: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/31 +Signed-off-by: Vineet Gupta +Signed-off-by: Sasha Levin +--- + arch/arc/kernel/stacktrace.c | 23 +++++++++++++++-------- + 1 file changed, 15 insertions(+), 8 deletions(-) + +diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c +index fc65d2921e3bd..fc3054c34db19 100644 +--- a/arch/arc/kernel/stacktrace.c ++++ b/arch/arc/kernel/stacktrace.c +@@ -38,15 +38,15 @@ + + #ifdef CONFIG_ARC_DW2_UNWIND + +-static void seed_unwind_frame_info(struct task_struct *tsk, +- struct pt_regs *regs, +- struct unwind_frame_info *frame_info) ++static int ++seed_unwind_frame_info(struct task_struct *tsk, struct pt_regs *regs, ++ struct unwind_frame_info *frame_info) + { + /* + * synchronous unwinding (e.g. dump_stack) + * - uses current values of SP and friends + */ +- if (tsk == NULL && regs == NULL) { ++ if (regs == NULL && (tsk == NULL || tsk == current)) { + unsigned long fp, sp, blink, ret; + frame_info->task = current; + +@@ -65,11 +65,15 @@ static void seed_unwind_frame_info(struct task_struct *tsk, + frame_info->call_frame = 0; + } else if (regs == NULL) { + /* +- * Asynchronous unwinding of sleeping task +- * - Gets SP etc from task's pt_regs (saved bottom of kernel +- * mode stack of task) ++ * Asynchronous unwinding of a likely sleeping task ++ * - first ensure it is actually sleeping ++ * - if so, it will be in __switch_to, kernel mode SP of task ++ * is safe-kept and BLINK at a well known location in there + */ + ++ if (tsk->state == TASK_RUNNING) ++ return -1; ++ + frame_info->task = tsk; + + frame_info->regs.r27 = TSK_K_FP(tsk); +@@ -103,6 +107,8 @@ static void seed_unwind_frame_info(struct task_struct *tsk, + frame_info->regs.r63 = regs->ret; + frame_info->call_frame = 0; + } ++ ++ return 0; + } + + #endif +@@ -116,7 +122,8 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs *regs, + unsigned int address; + struct unwind_frame_info frame_info; + +- seed_unwind_frame_info(tsk, regs, &frame_info); ++ if (seed_unwind_frame_info(tsk, regs, &frame_info)) ++ return 0; + + while (1) { + address = UNW_PC(&frame_info); +-- +2.27.0 + diff --git a/queue-5.4/arm64-dts-broadcom-clear-the-warnings-caused-by-empt.patch b/queue-5.4/arm64-dts-broadcom-clear-the-warnings-caused-by-empt.patch new file mode 100644 index 00000000000..79f93b5871b --- /dev/null +++ b/queue-5.4/arm64-dts-broadcom-clear-the-warnings-caused-by-empt.patch @@ -0,0 +1,111 @@ +From a947b35b4fa65d90d1ab02416d7afd8e5ba5c757 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 16 Oct 2020 17:08:32 +0800 +Subject: arm64: dts: broadcom: clear the warnings caused by empty dma-ranges + +From: Zhen Lei + +[ Upstream commit 2013a4b684b6eb614ee5c9a3c07b0ae6f5ca96d9 ] + +The scripts/dtc/checks.c requires that the node have empty "dma-ranges" +property must have the same "#address-cells" and "#size-cells" values as +the parent node. Otherwise, the following warnings is reported: + +arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \ +(dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \ +its #address-cells (1) differs from / (2) +arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \ +(dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \ +its #size-cells (1) differs from / (2) + +Arnd Bergmann figured out why it's necessary: +Also note that the #address-cells=<1> means that any device under +this bus is assumed to only support 32-bit addressing, and DMA will +have to go through a slow swiotlb in the absence of an IOMMU. + +Suggested-by: Arnd Bergmann +Signed-off-by: Zhen Lei +Link: https://lore.kernel.org/r/20201016090833.1892-2-thunder.leizhen@huawei.com' +Acked-by: Florian Fainelli +Signed-off-by: Arnd Bergmann +Signed-off-by: Sasha Levin +--- + .../dts/broadcom/stingray/stingray-usb.dtsi | 20 +++++++++---------- + 1 file changed, 10 insertions(+), 10 deletions(-) + +diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi +index 55259f973b5a9..aef8f2b00778d 100644 +--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi ++++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi +@@ -5,20 +5,20 @@ + usb { + compatible = "simple-bus"; + dma-ranges; +- #address-cells = <1>; +- #size-cells = <1>; +- ranges = <0x0 0x0 0x68500000 0x00400000>; ++ #address-cells = <2>; ++ #size-cells = <2>; ++ ranges = <0x0 0x0 0x0 0x68500000 0x0 0x00400000>; + + usbphy0: usb-phy@0 { + compatible = "brcm,sr-usb-combo-phy"; +- reg = <0x00000000 0x100>; ++ reg = <0x0 0x00000000 0x0 0x100>; + #phy-cells = <1>; + status = "disabled"; + }; + + xhci0: usb@1000 { + compatible = "generic-xhci"; +- reg = <0x00001000 0x1000>; ++ reg = <0x0 0x00001000 0x0 0x1000>; + interrupts = ; + phys = <&usbphy0 1>, <&usbphy0 0>; + phy-names = "phy0", "phy1"; +@@ -28,7 +28,7 @@ + + bdc0: usb@2000 { + compatible = "brcm,bdc-v0.16"; +- reg = <0x00002000 0x1000>; ++ reg = <0x0 0x00002000 0x0 0x1000>; + interrupts = ; + phys = <&usbphy0 0>, <&usbphy0 1>; + phy-names = "phy0", "phy1"; +@@ -38,21 +38,21 @@ + + usbphy1: usb-phy@10000 { + compatible = "brcm,sr-usb-combo-phy"; +- reg = <0x00010000 0x100>; ++ reg = <0x0 0x00010000 0x0 0x100>; + #phy-cells = <1>; + status = "disabled"; + }; + + usbphy2: usb-phy@20000 { + compatible = "brcm,sr-usb-hs-phy"; +- reg = <0x00020000 0x100>; ++ reg = <0x0 0x00020000 0x0 0x100>; + #phy-cells = <0>; + status = "disabled"; + }; + + xhci1: usb@11000 { + compatible = "generic-xhci"; +- reg = <0x00011000 0x1000>; ++ reg = <0x0 0x00011000 0x0 0x1000>; + interrupts = ; + phys = <&usbphy1 1>, <&usbphy2>, <&usbphy1 0>; + phy-names = "phy0", "phy1", "phy2"; +@@ -62,7 +62,7 @@ + + bdc1: usb@21000 { + compatible = "brcm,bdc-v0.16"; +- reg = <0x00021000 0x1000>; ++ reg = <0x0 0x00021000 0x0 0x1000>; + interrupts = ; + phys = <&usbphy2>; + phy-names = "phy0"; +-- +2.27.0 + diff --git a/queue-5.4/arm64-dts-rockchip-assign-a-fixed-index-to-mmc-devic.patch b/queue-5.4/arm64-dts-rockchip-assign-a-fixed-index-to-mmc-devic.patch new file mode 100644 index 00000000000..62156fd9dd8 --- /dev/null +++ b/queue-5.4/arm64-dts-rockchip-assign-a-fixed-index-to-mmc-devic.patch @@ -0,0 +1,43 @@ +From 60e80d47b5577e0cfd40b135242fbde47709f81e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 4 Nov 2020 17:23:55 +0100 +Subject: arm64: dts: rockchip: Assign a fixed index to mmc devices on rk3399 + boards. + +From: Markus Reichl + +[ Upstream commit 0011c6d182774fc781fb9e115ebe8baa356029ae ] + +Recently introduced async probe on mmc devices can shuffle block IDs. +Pin them to fixed values to ease booting in environments where UUIDs +are not practical. Use newly introduced aliases for mmcblk devices from [1]. + +[1] +https://patchwork.kernel.org/patch/11747669/ + +Signed-off-by: Markus Reichl +Reviewed-by: Douglas Anderson +Link: https://lore.kernel.org/r/20201104162356.1251-1-m.reichl@fivetechno.de +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/rockchip/rk3399.dtsi | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi +index c5d8d1c582913..bb7d0aac6b9db 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi ++++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi +@@ -29,6 +29,9 @@ + i2c6 = &i2c6; + i2c7 = &i2c7; + i2c8 = &i2c8; ++ mmc0 = &sdio0; ++ mmc1 = &sdmmc; ++ mmc2 = &sdhci; + serial0 = &uart0; + serial1 = &uart1; + serial2 = &uart2; +-- +2.27.0 + diff --git a/queue-5.4/arm64-tegra-disable-the-aconnect-for-jetson-tx2.patch b/queue-5.4/arm64-tegra-disable-the-aconnect-for-jetson-tx2.patch new file mode 100644 index 00000000000..aa587d8eeaf --- /dev/null +++ b/queue-5.4/arm64-tegra-disable-the-aconnect-for-jetson-tx2.patch @@ -0,0 +1,56 @@ +From edf5e05ab40a888c28bfa176eb46cc540db1e2e7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 16 Nov 2020 16:20:26 +0000 +Subject: arm64: tegra: Disable the ACONNECT for Jetson TX2 + +From: Jon Hunter + +[ Upstream commit fb319496935b7475a863a00c76895e8bb3216704 ] + +Commit ff4c371d2bc0 ("arm64: defconfig: Build ADMA and ACONNECT driver") +enable the Tegra ADMA and ACONNECT drivers and this is causing resume +from system suspend to fail on Jetson TX2. Resume is failing because the +ACONNECT driver is being resumed before the BPMP driver, and the ACONNECT +driver is attempting to power on a power-domain that is provided by the +BPMP. While a proper fix for the resume sequencing problem is identified, +disable the ACONNECT for Jetson TX2 temporarily to avoid breaking system +suspend. + +Please note that ACONNECT driver is used by the Audio Processing Engine +(APE) on Tegra, but because there is no mainline support for APE on +Jetson TX2 currently, disabling the ACONNECT does not disable any useful +feature at the moment. + +Signed-off-by: Jon Hunter +Signed-off-by: Thierry Reding +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts | 12 ------------ + 1 file changed, 12 deletions(-) + +diff --git a/arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts b/arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts +index bdace01561bab..9df4782c90f35 100644 +--- a/arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts ++++ b/arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts +@@ -10,18 +10,6 @@ + model = "NVIDIA Jetson TX2 Developer Kit"; + compatible = "nvidia,p2771-0000", "nvidia,tegra186"; + +- aconnect { +- status = "okay"; +- +- dma-controller@2930000 { +- status = "okay"; +- }; +- +- interrupt-controller@2a40000 { +- status = "okay"; +- }; +- }; +- + i2c@3160000 { + power-monitor@42 { + compatible = "ti,ina3221"; +-- +2.27.0 + diff --git a/queue-5.4/can-m_can-m_can_dev_setup-add-support-for-bosch-mcan.patch b/queue-5.4/can-m_can-m_can_dev_setup-add-support-for-bosch-mcan.patch new file mode 100644 index 00000000000..f80fc30b3ca --- /dev/null +++ b/queue-5.4/can-m_can-m_can_dev_setup-add-support-for-bosch-mcan.patch @@ -0,0 +1,38 @@ +From 1abf65a0aa4f629ae3821ecf095738f32f52370b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Nov 2020 10:21:42 +0530 +Subject: can: m_can: m_can_dev_setup(): add support for bosch mcan version + 3.3.0 + +From: Pankaj Sharma + +[ Upstream commit 5c7d55bded77da6db7c5d249610e3a2eed730b3c ] + +Add support for mcan bit timing and control mode according to bosch mcan IP +version 3.3.0. The mcan version read from the Core Release field of CREL +register would be 33. Accordingly the properties are to be set for mcan v3.3.0 + +Signed-off-by: Pankaj Sharma +Link: https://lore.kernel.org/r/1606366302-5520-1-git-send-email-pankj.sharma@samsung.com +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + drivers/net/can/m_can/m_can.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c +index f9a2a9ecbac9e..c84114b44ee07 100644 +--- a/drivers/net/can/m_can/m_can.c ++++ b/drivers/net/can/m_can/m_can.c +@@ -1337,6 +1337,8 @@ static int m_can_dev_setup(struct m_can_classdev *m_can_dev) + &m_can_data_bittiming_const_31X; + break; + case 32: ++ case 33: ++ /* Support both MCAN version v3.2.x and v3.3.0 */ + m_can_dev->can.bittiming_const = m_can_dev->bit_timing ? + m_can_dev->bit_timing : &m_can_bittiming_const_31X; + +-- +2.27.0 + diff --git a/queue-5.4/ibmvnic-skip-tx-timeout-reset-while-in-resetting.patch b/queue-5.4/ibmvnic-skip-tx-timeout-reset-while-in-resetting.patch new file mode 100644 index 00000000000..9b7197386bd --- /dev/null +++ b/queue-5.4/ibmvnic-skip-tx-timeout-reset-while-in-resetting.patch @@ -0,0 +1,42 @@ +From f852961c29d1fa34e5a59007b7b075a46b8d2d23 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 20 Nov 2020 16:40:13 -0600 +Subject: ibmvnic: skip tx timeout reset while in resetting + +From: Lijun Pan + +[ Upstream commit 855a631a4c11458a9cef1ab79c1530436aa95fae ] + +Sometimes it takes longer than 5 seconds (watchdog timeout) to complete +failover, migration, and other resets. In stead of scheduling another +timeout reset, we wait for the current one to complete. + +Suggested-by: Brian King +Signed-off-by: Lijun Pan +Reviewed-by: Dany Madden +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/ibm/ibmvnic.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c +index 7056419461e7b..47b8ce7822c09 100644 +--- a/drivers/net/ethernet/ibm/ibmvnic.c ++++ b/drivers/net/ethernet/ibm/ibmvnic.c +@@ -2266,6 +2266,12 @@ static void ibmvnic_tx_timeout(struct net_device *dev) + { + struct ibmvnic_adapter *adapter = netdev_priv(dev); + ++ if (test_bit(0, &adapter->resetting)) { ++ netdev_err(adapter->netdev, ++ "Adapter is resetting, skip timeout reset\n"); ++ return; ++ } ++ + ibmvnic_reset(adapter, VNIC_RESET_TIMEOUT); + } + +-- +2.27.0 + diff --git a/queue-5.4/interconnect-qcom-qcs404-remove-gpu-and-display-rpm-.patch b/queue-5.4/interconnect-qcom-qcs404-remove-gpu-and-display-rpm-.patch new file mode 100644 index 00000000000..93227bbb75e --- /dev/null +++ b/queue-5.4/interconnect-qcom-qcs404-remove-gpu-and-display-rpm-.patch @@ -0,0 +1,45 @@ +From 58bd6f7a2b756484e3a09868fb97c2b3a3dd9058 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 18 Nov 2020 13:10:44 +0200 +Subject: interconnect: qcom: qcs404: Remove GPU and display RPM IDs + +From: Georgi Djakov + +[ Upstream commit 7ab1e9117607485df977bb6e271be5c5ad649a4c ] + +The following errors are noticed during boot on a QCS404 board: +[ 2.926647] qcom_icc_rpm_smd_send mas 6 error -6 +[ 2.934573] qcom_icc_rpm_smd_send mas 8 error -6 + +These errors show when we try to configure the GPU and display nodes. +Since these particular nodes aren't supported on RPM and are purely +local, we should just change their mas_rpm_id to -1 to avoid any +requests being sent for these master IDs. + +Reviewed-by: Mike Tipton +Reviewed-by: Bjorn Andersson +Link: https://lore.kernel.org/r/20201118111044.26056-1-georgi.djakov@linaro.org +Signed-off-by: Georgi Djakov +Signed-off-by: Sasha Levin +--- + drivers/interconnect/qcom/qcs404.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/interconnect/qcom/qcs404.c b/drivers/interconnect/qcom/qcs404.c +index 8e0735a870400..3a3ce6ea65ff2 100644 +--- a/drivers/interconnect/qcom/qcs404.c ++++ b/drivers/interconnect/qcom/qcs404.c +@@ -157,8 +157,8 @@ struct qcom_icc_desc { + } + + DEFINE_QNODE(mas_apps_proc, QCS404_MASTER_AMPSS_M0, 8, 0, -1, QCS404_SLAVE_EBI_CH0, QCS404_BIMC_SNOC_SLV); +-DEFINE_QNODE(mas_oxili, QCS404_MASTER_GRAPHICS_3D, 8, 6, -1, QCS404_SLAVE_EBI_CH0, QCS404_BIMC_SNOC_SLV); +-DEFINE_QNODE(mas_mdp, QCS404_MASTER_MDP_PORT0, 8, 8, -1, QCS404_SLAVE_EBI_CH0, QCS404_BIMC_SNOC_SLV); ++DEFINE_QNODE(mas_oxili, QCS404_MASTER_GRAPHICS_3D, 8, -1, -1, QCS404_SLAVE_EBI_CH0, QCS404_BIMC_SNOC_SLV); ++DEFINE_QNODE(mas_mdp, QCS404_MASTER_MDP_PORT0, 8, -1, -1, QCS404_SLAVE_EBI_CH0, QCS404_BIMC_SNOC_SLV); + DEFINE_QNODE(mas_snoc_bimc_1, QCS404_SNOC_BIMC_1_MAS, 8, 76, -1, QCS404_SLAVE_EBI_CH0); + DEFINE_QNODE(mas_tcu_0, QCS404_MASTER_TCU_0, 8, -1, -1, QCS404_SLAVE_EBI_CH0, QCS404_BIMC_SNOC_SLV); + DEFINE_QNODE(mas_spdm, QCS404_MASTER_SPDM, 4, -1, -1, QCS404_PNOC_INT_3); +-- +2.27.0 + diff --git a/queue-5.4/irqchip-gic-v3-its-unconditionally-save-restore-the-.patch b/queue-5.4/irqchip-gic-v3-its-unconditionally-save-restore-the-.patch new file mode 100644 index 00000000000..2ee9b768da0 --- /dev/null +++ b/queue-5.4/irqchip-gic-v3-its-unconditionally-save-restore-the-.patch @@ -0,0 +1,99 @@ +From 21029570c43aa0cea89c01c40d7afaf593b1caa8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 7 Nov 2020 10:42:26 +0000 +Subject: irqchip/gic-v3-its: Unconditionally save/restore the ITS state on + suspend + +From: Xu Qiang + +[ Upstream commit 74cde1a53368aed4f2b4b54bf7030437f64a534b ] + +On systems without HW-based collections (i.e. anything except GIC-500), +we rely on firmware to perform the ITS save/restore. This doesn't +really work, as although FW can properly save everything, it cannot +fully restore the state of the command queue (the read-side is reset +to the head of the queue). This results in the ITS consuming previously +processed commands, potentially corrupting the state. + +Instead, let's always save the ITS state on suspend, disabling it in the +process, and restore the full state on resume. This saves us from broken +FW as long as it doesn't enable the ITS by itself (for which we can't do +anything). + +This amounts to simply dropping the ITS_FLAGS_SAVE_SUSPEND_STATE. + +Signed-off-by: Xu Qiang +[maz: added warning on resume, rewrote commit message] +Signed-off-by: Marc Zyngier +Link: https://lore.kernel.org/r/20201107104226.14282-1-xuqiang36@huawei.com +Signed-off-by: Sasha Levin +--- + drivers/irqchip/irq-gic-v3-its.c | 16 +++------------- + 1 file changed, 3 insertions(+), 13 deletions(-) + +diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c +index 7966b19ceba79..f298313b87ac7 100644 +--- a/drivers/irqchip/irq-gic-v3-its.c ++++ b/drivers/irqchip/irq-gic-v3-its.c +@@ -40,7 +40,6 @@ + #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0) + #define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1) + #define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2) +-#define ITS_FLAGS_SAVE_SUSPEND_STATE (1ULL << 3) + + #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0) + #define RDIST_FLAGS_RD_TABLES_PREALLOCATED (1 << 1) +@@ -3367,9 +3366,6 @@ static int its_save_disable(void) + list_for_each_entry(its, &its_nodes, entry) { + void __iomem *base; + +- if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE)) +- continue; +- + base = its->base; + its->ctlr_save = readl_relaxed(base + GITS_CTLR); + err = its_force_quiescent(base); +@@ -3388,9 +3384,6 @@ err: + list_for_each_entry_continue_reverse(its, &its_nodes, entry) { + void __iomem *base; + +- if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE)) +- continue; +- + base = its->base; + writel_relaxed(its->ctlr_save, base + GITS_CTLR); + } +@@ -3410,9 +3403,6 @@ static void its_restore_enable(void) + void __iomem *base; + int i; + +- if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE)) +- continue; +- + base = its->base; + + /* +@@ -3420,7 +3410,10 @@ static void its_restore_enable(void) + * don't restore it since writing to CBASER or BASER + * registers is undefined according to the GIC v3 ITS + * Specification. ++ * ++ * Firmware resuming with the ITS enabled is terminally broken. + */ ++ WARN_ON(readl_relaxed(base + GITS_CTLR) & GITS_CTLR_ENABLE); + ret = its_force_quiescent(base); + if (ret) { + pr_err("ITS@%pa: failed to quiesce on resume: %d\n", +@@ -3687,9 +3680,6 @@ static int __init its_probe_one(struct resource *res, + ctlr |= GITS_CTLR_ImDe; + writel_relaxed(ctlr, its->base + GITS_CTLR); + +- if (GITS_TYPER_HCC(typer)) +- its->flags |= ITS_FLAGS_SAVE_SUSPEND_STATE; +- + err = its_init_domain(handle, its); + if (err) + goto out_free_tables; +-- +2.27.0 + diff --git a/queue-5.4/iwlwifi-mvm-fix-kernel-panic-in-case-of-assert-durin.patch b/queue-5.4/iwlwifi-mvm-fix-kernel-panic-in-case-of-assert-durin.patch new file mode 100644 index 00000000000..81a79bd88f1 --- /dev/null +++ b/queue-5.4/iwlwifi-mvm-fix-kernel-panic-in-case-of-assert-durin.patch @@ -0,0 +1,42 @@ +From 2c4d27a45c37d1ae2e2488ac660a35970715f114 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 7 Nov 2020 10:50:11 +0200 +Subject: iwlwifi: mvm: fix kernel panic in case of assert during CSA + +From: Sara Sharon + +[ Upstream commit fe56d05ee6c87f6a1a8c7267affd92c9438249cc ] + +During CSA, we briefly nullify the phy context, in __iwl_mvm_unassign_vif_chanctx. +In case we have a FW assert right after it, it remains NULL though. +We end up running into endless loop due to mac80211 trying repeatedly to +move us to ASSOC state, and we keep returning -EINVAL. Later down the road +we hit a kernel panic. + +Detect and avoid this endless loop. + +Signed-off-by: Sara Sharon +Signed-off-by: Luca Coelho +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/iwlwifi.20201107104557.d64de2c17bff.Iedd0d2afa20a2aacba5259a5cae31cb3a119a4eb@changeid +Signed-off-by: Sasha Levin +--- + drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c +index 73b8bf0fbf16f..daae86cd61140 100644 +--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c +@@ -3022,7 +3022,7 @@ static int iwl_mvm_mac_sta_state(struct ieee80211_hw *hw, + + /* this would be a mac80211 bug ... but don't crash */ + if (WARN_ON_ONCE(!mvmvif->phy_ctxt)) +- return -EINVAL; ++ return test_bit(IWL_MVM_STATUS_HW_RESTART_REQUESTED, &mvm->status) ? 0 : -EINVAL; + + /* + * If we are in a STA removal flow and in DQA mode: +-- +2.27.0 + diff --git a/queue-5.4/iwlwifi-pcie-limit-memory-read-spin-time.patch b/queue-5.4/iwlwifi-pcie-limit-memory-read-spin-time.patch new file mode 100644 index 00000000000..771b1675b3a --- /dev/null +++ b/queue-5.4/iwlwifi-pcie-limit-memory-read-spin-time.patch @@ -0,0 +1,94 @@ +From 7e1e08069d324f2784d8f0836264b4abeee2953a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 22 Oct 2020 16:51:03 +0300 +Subject: iwlwifi: pcie: limit memory read spin time + +From: Johannes Berg + +[ Upstream commit 04516706bb99889986ddfa3a769ed50d2dc7ac13 ] + +When we read device memory, we lock a spinlock, write the address we +want to read from the device and then spin in a loop reading the data +in 32-bit quantities from another register. + +As the description makes clear, this is rather inefficient, incurring +a PCIe bus transaction for every read. In a typical device today, we +want to read 786k SMEM if it crashes, leading to 192k register reads. +Occasionally, we've seen the whole loop take over 20 seconds and then +triggering the soft lockup detector. + +Clearly, it is unreasonable to spin here for such extended periods of +time. + +To fix this, break the loop down into an outer and an inner loop, and +break out of the inner loop if more than half a second elapsed. To +avoid too much overhead, check for that only every 128 reads, though +there's no particular reason for that number. Then, unlock and relock +to obtain NIC access again, reprogram the start address and continue. + +This will keep (interrupt) latencies on the CPU down to a reasonable +time. + +Signed-off-by: Johannes Berg +Signed-off-by: Mordechay Goodstein +Signed-off-by: Luca Coelho +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/iwlwifi.20201022165103.45878a7e49aa.I3b9b9c5a10002915072312ce75b68ed5b3dc6e14@changeid +Signed-off-by: Sasha Levin +--- + .../net/wireless/intel/iwlwifi/pcie/trans.c | 36 ++++++++++++++----- + 1 file changed, 27 insertions(+), 9 deletions(-) + +diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c +index c76d26708e659..ef5a8ecabc60a 100644 +--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c ++++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c +@@ -2178,18 +2178,36 @@ static int iwl_trans_pcie_read_mem(struct iwl_trans *trans, u32 addr, + void *buf, int dwords) + { + unsigned long flags; +- int offs, ret = 0; ++ int offs = 0; + u32 *vals = buf; + +- if (iwl_trans_grab_nic_access(trans, &flags)) { +- iwl_write32(trans, HBUS_TARG_MEM_RADDR, addr); +- for (offs = 0; offs < dwords; offs++) +- vals[offs] = iwl_read32(trans, HBUS_TARG_MEM_RDAT); +- iwl_trans_release_nic_access(trans, &flags); +- } else { +- ret = -EBUSY; ++ while (offs < dwords) { ++ /* limit the time we spin here under lock to 1/2s */ ++ ktime_t timeout = ktime_add_us(ktime_get(), 500 * USEC_PER_MSEC); ++ ++ if (iwl_trans_grab_nic_access(trans, &flags)) { ++ iwl_write32(trans, HBUS_TARG_MEM_RADDR, ++ addr + 4 * offs); ++ ++ while (offs < dwords) { ++ vals[offs] = iwl_read32(trans, ++ HBUS_TARG_MEM_RDAT); ++ offs++; ++ ++ /* calling ktime_get is expensive so ++ * do it once in 128 reads ++ */ ++ if (offs % 128 == 0 && ktime_after(ktime_get(), ++ timeout)) ++ break; ++ } ++ iwl_trans_release_nic_access(trans, &flags); ++ } else { ++ return -EBUSY; ++ } + } +- return ret; ++ ++ return 0; + } + + static int iwl_trans_pcie_write_mem(struct iwl_trans *trans, u32 addr, +-- +2.27.0 + diff --git a/queue-5.4/iwlwifi-pcie-set-ltr-to-avoid-completion-timeout.patch b/queue-5.4/iwlwifi-pcie-set-ltr-to-avoid-completion-timeout.patch new file mode 100644 index 00000000000..4bb04bc85ee --- /dev/null +++ b/queue-5.4/iwlwifi-pcie-set-ltr-to-avoid-completion-timeout.patch @@ -0,0 +1,79 @@ +From e6ff5ab2d9febbc546bbcb31f620eaff3908ca60 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 7 Nov 2020 10:50:10 +0200 +Subject: iwlwifi: pcie: set LTR to avoid completion timeout + +From: Johannes Berg + +[ Upstream commit edb625208d84aef179e3f16590c1c582fc5fdae6 ] + +On some platforms, the preset values aren't correct and then we may +get a completion timeout in the firmware. Change the LTR configuration +to avoid that. The firmware will do some more complex reinit of this +later, but for the boot process we use ~250usec. + +Signed-off-by: Johannes Berg +Signed-off-by: Luca Coelho +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/iwlwifi.20201107104557.d83d591c05ba.I42885c9fb500bc08b9a4c07c4ff3d436cc7a3c84@changeid +Signed-off-by: Sasha Levin +--- + drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 10 ++++++++++ + .../intel/iwlwifi/pcie/ctxt-info-gen3.c | 20 +++++++++++++++++++ + 2 files changed, 30 insertions(+) + +diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-csr.h b/drivers/net/wireless/intel/iwlwifi/iwl-csr.h +index 695bbaa86273d..12ef3a0420515 100644 +--- a/drivers/net/wireless/intel/iwlwifi/iwl-csr.h ++++ b/drivers/net/wireless/intel/iwlwifi/iwl-csr.h +@@ -147,6 +147,16 @@ + #define CSR_MAC_SHADOW_REG_CTL2 (CSR_BASE + 0x0AC) + #define CSR_MAC_SHADOW_REG_CTL2_RX_WAKE 0xFFFF + ++/* LTR control (since IWL_DEVICE_FAMILY_22000) */ ++#define CSR_LTR_LONG_VAL_AD (CSR_BASE + 0x0D4) ++#define CSR_LTR_LONG_VAL_AD_NO_SNOOP_REQ 0x80000000 ++#define CSR_LTR_LONG_VAL_AD_NO_SNOOP_SCALE 0x1c000000 ++#define CSR_LTR_LONG_VAL_AD_NO_SNOOP_VAL 0x03ff0000 ++#define CSR_LTR_LONG_VAL_AD_SNOOP_REQ 0x00008000 ++#define CSR_LTR_LONG_VAL_AD_SNOOP_SCALE 0x00001c00 ++#define CSR_LTR_LONG_VAL_AD_SNOOP_VAL 0x000003ff ++#define CSR_LTR_LONG_VAL_AD_SCALE_USEC 2 ++ + /* GIO Chicken Bits (PCI Express bus link power management) */ + #define CSR_GIO_CHICKEN_BITS (CSR_BASE+0x100) + +diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c b/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c +index 74980382e64c8..7a5b024a6d384 100644 +--- a/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c ++++ b/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c +@@ -180,6 +180,26 @@ int iwl_pcie_ctxt_info_gen3_init(struct iwl_trans *trans, + + iwl_set_bit(trans, CSR_CTXT_INFO_BOOT_CTRL, + CSR_AUTO_FUNC_BOOT_ENA); ++ ++ if (trans->trans_cfg->device_family == IWL_DEVICE_FAMILY_AX210) { ++ /* ++ * The firmware initializes this again later (to a smaller ++ * value), but for the boot process initialize the LTR to ++ * ~250 usec. ++ */ ++ u32 val = CSR_LTR_LONG_VAL_AD_NO_SNOOP_REQ | ++ u32_encode_bits(CSR_LTR_LONG_VAL_AD_SCALE_USEC, ++ CSR_LTR_LONG_VAL_AD_NO_SNOOP_SCALE) | ++ u32_encode_bits(250, ++ CSR_LTR_LONG_VAL_AD_NO_SNOOP_VAL) | ++ CSR_LTR_LONG_VAL_AD_SNOOP_REQ | ++ u32_encode_bits(CSR_LTR_LONG_VAL_AD_SCALE_USEC, ++ CSR_LTR_LONG_VAL_AD_SNOOP_SCALE) | ++ u32_encode_bits(250, CSR_LTR_LONG_VAL_AD_SNOOP_VAL); ++ ++ iwl_write32(trans, CSR_LTR_LONG_VAL_AD, val); ++ } ++ + if (trans->trans_cfg->device_family >= IWL_DEVICE_FAMILY_AX210) + iwl_write_umac_prph(trans, UREG_CPU_INIT_RUN, 1); + else +-- +2.27.0 + diff --git a/queue-5.4/platform-x86-acer-wmi-add-automatic-keyboard-backgro.patch b/queue-5.4/platform-x86-acer-wmi-add-automatic-keyboard-backgro.patch new file mode 100644 index 00000000000..41cb77bd3d6 --- /dev/null +++ b/queue-5.4/platform-x86-acer-wmi-add-automatic-keyboard-backgro.patch @@ -0,0 +1,38 @@ +From 7bc9ea0dec3c4196867bce459c265281bd63cc7a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 4 Aug 2020 02:14:23 +0200 +Subject: platform/x86: acer-wmi: add automatic keyboard background light + toggle key as KEY_LIGHTS_TOGGLE + +From: Timo Witte + +[ Upstream commit 9e7a005ad56aa7d6ea5830c5ffcc60bf35de380b ] + +Got a dmesg message on my AMD Renoir based Acer laptop: +"acer_wmi: Unknown key number - 0x84" when toggling keyboard +background light + +Signed-off-by: Timo Witte +Reviewed-by: "Lee, Chun-Yi" +Link: https://lore.kernel.org/r/20200804001423.36778-1-timo.witte@gmail.com +Signed-off-by: Hans de Goede +Signed-off-by: Sasha Levin +--- + drivers/platform/x86/acer-wmi.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c +index 60c18f21588dd..7fa27e7536917 100644 +--- a/drivers/platform/x86/acer-wmi.c ++++ b/drivers/platform/x86/acer-wmi.c +@@ -111,6 +111,7 @@ static const struct key_entry acer_wmi_keymap[] __initconst = { + {KE_KEY, 0x64, {KEY_SWITCHVIDEOMODE} }, /* Display Switch */ + {KE_IGNORE, 0x81, {KEY_SLEEP} }, + {KE_KEY, 0x82, {KEY_TOUCHPAD_TOGGLE} }, /* Touch Pad Toggle */ ++ {KE_IGNORE, 0x84, {KEY_KBDILLUMTOGGLE} }, /* Automatic Keyboard background light toggle */ + {KE_KEY, KEY_TOUCHPAD_ON, {KEY_TOUCHPAD_ON} }, + {KE_KEY, KEY_TOUCHPAD_OFF, {KEY_TOUCHPAD_OFF} }, + {KE_IGNORE, 0x83, {KEY_TOUCHPAD_TOGGLE} }, +-- +2.27.0 + diff --git a/queue-5.4/platform-x86-intel-vbtn-support-for-tablet-mode-on-h.patch b/queue-5.4/platform-x86-intel-vbtn-support-for-tablet-mode-on-h.patch new file mode 100644 index 00000000000..98319dc284a --- /dev/null +++ b/queue-5.4/platform-x86-intel-vbtn-support-for-tablet-mode-on-h.patch @@ -0,0 +1,42 @@ +From 23a7fc98a9c5b7081399767f573424ae31a76518 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 24 Nov 2020 15:16:52 +0200 +Subject: platform/x86: intel-vbtn: Support for tablet mode on HP Pavilion 13 + x360 PC + +From: Max Verevkin + +[ Upstream commit 8b205d3e1bf52ab31cdd5c55f87c87a227793d84 ] + +The Pavilion 13 x360 PC has a chassis-type which does not indicate it is +a convertible, while it is actually a convertible. Add it to the +dmi_switches_allow_list. + +Signed-off-by: Max Verevkin +Link: https://lore.kernel.org/r/20201124131652.11165-1-me@maxverevkin.tk +Signed-off-by: Hans de Goede +Signed-off-by: Sasha Levin +--- + drivers/platform/x86/intel-vbtn.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/drivers/platform/x86/intel-vbtn.c b/drivers/platform/x86/intel-vbtn.c +index 5c103614a409a..701d1ddda4b11 100644 +--- a/drivers/platform/x86/intel-vbtn.c ++++ b/drivers/platform/x86/intel-vbtn.c +@@ -197,6 +197,12 @@ static const struct dmi_system_id dmi_switches_allow_list[] = { + DMI_MATCH(DMI_PRODUCT_NAME, "HP Stream x360 Convertible PC 11"), + }, + }, ++ { ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion 13 x360 PC"), ++ }, ++ }, + {} /* Array terminator */ + }; + +-- +2.27.0 + diff --git a/queue-5.4/platform-x86-thinkpad_acpi-add-bat1-is-primary-batte.patch b/queue-5.4/platform-x86-thinkpad_acpi-add-bat1-is-primary-batte.patch new file mode 100644 index 00000000000..ca7b1c6c564 --- /dev/null +++ b/queue-5.4/platform-x86-thinkpad_acpi-add-bat1-is-primary-batte.patch @@ -0,0 +1,47 @@ +From 7c0822870f240d0dcb85e53948ad7bb0582647d8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Nov 2020 11:35:50 +0100 +Subject: platform/x86: thinkpad_acpi: Add BAT1 is primary battery quirk for + Thinkpad Yoga 11e 4th gen + +From: Hans de Goede + +[ Upstream commit c986a7024916c92a775fc8d853fba3cae1d5fde4 ] + +The Thinkpad Yoga 11e 4th gen with the N3450 / Celeron CPU only has +one battery which is named BAT1 instead of the expected BAT0, add a +quirk for this. This fixes not being able to set the charging tresholds +on this model; and this alsoe fixes the following errors in dmesg: + +ACPI: \_SB_.PCI0.LPCB.EC__.HKEY: BCTG evaluated but flagged as error +thinkpad_acpi: Error probing battery 2 +battery: extension failed to load: ThinkPad Battery Extension +battery: extension unregistered: ThinkPad Battery Extension + +Note that the added quirk is for the "R0K" BIOS versions which are +used on the Thinkpad Yoga 11e 4th gen's with a Celeron CPU, there +is a separate "R0L" BIOS for the i3/i5 based versions. This may also +need the same quirk, but if that really is necessary is unknown. + +Signed-off-by: Hans de Goede +Link: https://lore.kernel.org/r/20201109103550.16265-1-hdegoede@redhat.com +Signed-off-by: Sasha Levin +--- + drivers/platform/x86/thinkpad_acpi.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c +index f196a3313690f..8c54d3707fba3 100644 +--- a/drivers/platform/x86/thinkpad_acpi.c ++++ b/drivers/platform/x86/thinkpad_acpi.c +@@ -9697,6 +9697,7 @@ static const struct tpacpi_quirk battery_quirk_table[] __initconst = { + TPACPI_Q_LNV3('R', '0', 'B', true), /* Thinkpad 11e gen 3 */ + TPACPI_Q_LNV3('R', '0', 'C', true), /* Thinkpad 13 */ + TPACPI_Q_LNV3('R', '0', 'J', true), /* Thinkpad 13 gen 2 */ ++ TPACPI_Q_LNV3('R', '0', 'K', true), /* Thinkpad 11e gen 4 celeron BIOS */ + }; + + static int __init tpacpi_battery_init(struct ibm_init_struct *ibm) +-- +2.27.0 + diff --git a/queue-5.4/platform-x86-thinkpad_acpi-do-not-report-sw_tablet_m.patch b/queue-5.4/platform-x86-thinkpad_acpi-do-not-report-sw_tablet_m.patch new file mode 100644 index 00000000000..496c1f97b9e --- /dev/null +++ b/queue-5.4/platform-x86-thinkpad_acpi-do-not-report-sw_tablet_m.patch @@ -0,0 +1,66 @@ +From b9f10bf4d631fb0185999661c7f74861a9e8e06f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Nov 2020 15:01:30 +0100 +Subject: platform/x86: thinkpad_acpi: Do not report SW_TABLET_MODE on Yoga 11e + +From: Hans de Goede + +[ Upstream commit f2eae1888cf22590c38764b8fa3c989c0283870e ] + +The Yoga 11e series has 2 accelerometers described by a BOSC0200 ACPI node. +This setup relies on a Windows service which reads both accelerometers and +then calculates the angle between the 2 halves to determine laptop / tent / +tablet mode and then reports the calculated mode back to the EC by calling +special ACPI methods on the BOSC0200 node. + +The bmc150 iio driver does not support this (it involves double +calculations requiring sqrt and arccos so this really needs to be done +in userspace), as a result of this on the Yoga 11e the thinkpad_acpi +code always reports SW_TABLET_MODE=0, starting with GNOME 3.38 reporting +SW_TABLET_MODE=0 causes GNOME to: + +1. Not show the onscreen keyboard when a text-input field is focussed + with the touchscreen. +2. Disable accelerometer based auto display-rotation. + +This makes sense when in laptop-mode but not when in tablet-mode. But +since for the Yoga 11e the thinkpad_acpi code always reports +SW_TABLET_MODE=0, GNOME does not know when the device is in tablet-mode. + +Stop reporting the broken (always 0) SW_TABLET_MODE on Yoga 11e models +to fix this. + +Note there are plans for userspace to support 360 degree hinges style +2-in-1s with 2 accelerometers and figure out the mode by itself, see: +https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/216 + +Signed-off-by: Hans de Goede +Link: https://lore.kernel.org/r/20201106140130.46820-1-hdegoede@redhat.com +Signed-off-by: Sasha Levin +--- + drivers/platform/x86/thinkpad_acpi.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c +index 5081048f2356e..f196a3313690f 100644 +--- a/drivers/platform/x86/thinkpad_acpi.c ++++ b/drivers/platform/x86/thinkpad_acpi.c +@@ -3232,7 +3232,14 @@ static int hotkey_init_tablet_mode(void) + + in_tablet_mode = hotkey_gmms_get_tablet_mode(res, + &has_tablet_mode); +- if (has_tablet_mode) ++ /* ++ * The Yoga 11e series has 2 accelerometers described by a ++ * BOSC0200 ACPI node. This setup relies on a Windows service ++ * which calls special ACPI methods on this node to report ++ * the laptop/tent/tablet mode to the EC. The bmc150 iio driver ++ * does not support this, so skip the hotkey on these models. ++ */ ++ if (has_tablet_mode && !acpi_dev_present("BOSC0200", "1", -1)) + tp_features.hotkey_tablet = TP_HOTKEY_TABLET_USES_GMMS; + type = "GMMS"; + } else if (acpi_evalf(hkey_handle, &res, "MHKG", "qd")) { +-- +2.27.0 + diff --git a/queue-5.4/platform-x86-touchscreen_dmi-add-info-for-the-irbis-.patch b/queue-5.4/platform-x86-touchscreen_dmi-add-info-for-the-irbis-.patch new file mode 100644 index 00000000000..6d5c4f28a7a --- /dev/null +++ b/queue-5.4/platform-x86-touchscreen_dmi-add-info-for-the-irbis-.patch @@ -0,0 +1,63 @@ +From 7b939c4a9c809f8d1b84cce90268b680f803f60d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 24 Nov 2020 12:04:54 +0100 +Subject: platform/x86: touchscreen_dmi: Add info for the Irbis TW118 tablet + +From: Hans de Goede + +[ Upstream commit c9aa128080cbce92f8715a9328f88d8ca3134279 ] + +Add touchscreen info for the Irbis TW118 tablet. + +Reported-and-tested-by: russianneuromancer +Signed-off-by: Hans de Goede +Link: https://lore.kernel.org/r/20201124110454.114286-1-hdegoede@redhat.com +Signed-off-by: Sasha Levin +--- + drivers/platform/x86/touchscreen_dmi.c | 23 +++++++++++++++++++++++ + 1 file changed, 23 insertions(+) + +diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c +index 1c7d8324ff5c2..1e072dbba30d6 100644 +--- a/drivers/platform/x86/touchscreen_dmi.c ++++ b/drivers/platform/x86/touchscreen_dmi.c +@@ -264,6 +264,21 @@ static const struct ts_dmi_data irbis_tw90_data = { + .properties = irbis_tw90_props, + }; + ++static const struct property_entry irbis_tw118_props[] = { ++ PROPERTY_ENTRY_U32("touchscreen-min-x", 20), ++ PROPERTY_ENTRY_U32("touchscreen-min-y", 30), ++ PROPERTY_ENTRY_U32("touchscreen-size-x", 1960), ++ PROPERTY_ENTRY_U32("touchscreen-size-y", 1510), ++ PROPERTY_ENTRY_STRING("firmware-name", "gsl1680-irbis-tw118.fw"), ++ PROPERTY_ENTRY_U32("silead,max-fingers", 10), ++ { } ++}; ++ ++static const struct ts_dmi_data irbis_tw118_data = { ++ .acpi_name = "MSSL1680:00", ++ .properties = irbis_tw118_props, ++}; ++ + static const struct property_entry itworks_tw891_props[] = { + PROPERTY_ENTRY_U32("touchscreen-min-x", 1), + PROPERTY_ENTRY_U32("touchscreen-min-y", 5), +@@ -758,6 +773,14 @@ static const struct dmi_system_id touchscreen_dmi_table[] = { + DMI_MATCH(DMI_PRODUCT_NAME, "TW90"), + }, + }, ++ { ++ /* Irbis TW118 */ ++ .driver_data = (void *)&irbis_tw118_data, ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "IRBIS"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "TW118"), ++ }, ++ }, + { + /* I.T.Works TW891 */ + .driver_data = (void *)&itworks_tw891_data, +-- +2.27.0 + diff --git a/queue-5.4/powerpc-drop-me200-addition-to-build-flags.patch b/queue-5.4/powerpc-drop-me200-addition-to-build-flags.patch new file mode 100644 index 00000000000..1f5856cf526 --- /dev/null +++ b/queue-5.4/powerpc-drop-me200-addition-to-build-flags.patch @@ -0,0 +1,51 @@ +From 44f86a75de12dc471cd32ee0dfaff559af4a6acb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 16 Nov 2020 23:09:13 +1100 +Subject: powerpc: Drop -me200 addition to build flags +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Michael Ellerman + +[ Upstream commit e02152ba2810f7c88cb54e71cda096268dfa9241 ] + +Currently a build with CONFIG_E200=y will fail with: + + Error: invalid switch -me200 + Error: unrecognized option -me200 + +Upstream binutils has never supported an -me200 option. Presumably it +was supported at some point by either a fork or Freescale internal +binutils. + +We can't support code that we can't even build test, so drop the +addition of -me200 to the build flags, so we can at least build with +CONFIG_E200=y. + +Reported-by: Németh Márton +Reported-by: kernel test robot +Signed-off-by: Michael Ellerman +Reviewed-by: Nick Desaulniers +Acked-by: Scott Wood +Link: https://lore.kernel.org/r/20201116120913.165317-1-mpe@ellerman.id.au +Signed-off-by: Sasha Levin +--- + arch/powerpc/Makefile | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile +index 37ac731a556b8..9f73fb6b1cc91 100644 +--- a/arch/powerpc/Makefile ++++ b/arch/powerpc/Makefile +@@ -250,7 +250,6 @@ KBUILD_CFLAGS += $(call cc-option,-mno-string) + + cpu-as-$(CONFIG_4xx) += -Wa,-m405 + cpu-as-$(CONFIG_ALTIVEC) += $(call as-option,-Wa$(comma)-maltivec) +-cpu-as-$(CONFIG_E200) += -Wa,-me200 + cpu-as-$(CONFIG_E500) += -Wa,-me500 + + # When using '-many -mpower4' gas will first try and find a matching power4 +-- +2.27.0 + diff --git a/queue-5.4/scsi-ufs-make-sure-clk-scaling-happens-only-when-hba.patch b/queue-5.4/scsi-ufs-make-sure-clk-scaling-happens-only-when-hba.patch new file mode 100644 index 00000000000..d01d3d6cf6f --- /dev/null +++ b/queue-5.4/scsi-ufs-make-sure-clk-scaling-happens-only-when-hba.patch @@ -0,0 +1,57 @@ +From c8203871acd43a68f5c2a65663294f4b7dba72e6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 22 Sep 2020 00:09:04 -0700 +Subject: scsi: ufs: Make sure clk scaling happens only when HBA is runtime + ACTIVE + +From: Can Guo + +[ Upstream commit 73cc291c270248567245f084dcdf5078069af6b5 ] + +If someone plays with the UFS clk scaling devfreq governor through sysfs, +ufshcd_devfreq_scale may be called even when HBA is not runtime ACTIVE. +This can lead to unexpected error. We cannot just protect it by calling +pm_runtime_get_sync() because that may cause a race condition since HBA +runtime suspend ops need to suspend clk scaling. To fix this call +pm_runtime_get_noresume() and check HBA's runtime status. Only proceed if +HBA is runtime ACTIVE, otherwise just bail. + +governor_store + devfreq_performance_handler + update_devfreq + devfreq_set_target + ufshcd_devfreq_target + ufshcd_devfreq_scale + +Link: https://lore.kernel.org/r/1600758548-28576-1-git-send-email-cang@codeaurora.org +Reviewed-by: Stanley Chu +Signed-off-by: Can Guo +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/ufs/ufshcd.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c +index b6ce880ddd153..675e16e61ebdd 100644 +--- a/drivers/scsi/ufs/ufshcd.c ++++ b/drivers/scsi/ufs/ufshcd.c +@@ -1257,8 +1257,15 @@ static int ufshcd_devfreq_target(struct device *dev, + } + spin_unlock_irqrestore(hba->host->host_lock, irq_flags); + ++ pm_runtime_get_noresume(hba->dev); ++ if (!pm_runtime_active(hba->dev)) { ++ pm_runtime_put_noidle(hba->dev); ++ ret = -EAGAIN; ++ goto out; ++ } + start = ktime_get(); + ret = ufshcd_devfreq_scale(hba, scale_up); ++ pm_runtime_put(hba->dev); + + trace_ufshcd_profile_clk_scaling(dev_name(hba->dev), + (scale_up ? "up" : "down"), +-- +2.27.0 + diff --git a/queue-5.4/series b/queue-5.4/series index c7267db178e..fb2e64ccf01 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -1,2 +1,22 @@ kbuild-do-not-emit-debug-info-for-assembly-with-llvm_ias-1.patch x86-lib-change-.weak-to-sym_func_start_weak-for-arch-x86-lib-mem-_64.s.patch +iwlwifi-pcie-limit-memory-read-spin-time.patch +arm64-dts-rockchip-assign-a-fixed-index-to-mmc-devic.patch +iwlwifi-pcie-set-ltr-to-avoid-completion-timeout.patch +iwlwifi-mvm-fix-kernel-panic-in-case-of-assert-durin.patch +powerpc-drop-me200-addition-to-build-flags.patch +arm64-dts-broadcom-clear-the-warnings-caused-by-empt.patch +arc-stack-unwinding-don-t-assume-non-current-task-is.patch +scsi-ufs-make-sure-clk-scaling-happens-only-when-hba.patch +interconnect-qcom-qcs404-remove-gpu-and-display-rpm-.patch +ibmvnic-skip-tx-timeout-reset-while-in-resetting.patch +irqchip-gic-v3-its-unconditionally-save-restore-the-.patch +spi-spi-nxp-fspi-fix-fspi-panic-by-unexpected-interr.patch +soc-fsl-dpio-get-the-cpumask-through-cpumask_of-cpu.patch +arm64-tegra-disable-the-aconnect-for-jetson-tx2.patch +platform-x86-thinkpad_acpi-do-not-report-sw_tablet_m.patch +platform-x86-thinkpad_acpi-add-bat1-is-primary-batte.patch +platform-x86-acer-wmi-add-automatic-keyboard-backgro.patch +platform-x86-intel-vbtn-support-for-tablet-mode-on-h.patch +platform-x86-touchscreen_dmi-add-info-for-the-irbis-.patch +can-m_can-m_can_dev_setup-add-support-for-bosch-mcan.patch diff --git a/queue-5.4/soc-fsl-dpio-get-the-cpumask-through-cpumask_of-cpu.patch b/queue-5.4/soc-fsl-dpio-get-the-cpumask-through-cpumask_of-cpu.patch new file mode 100644 index 00000000000..9f7148a4c96 --- /dev/null +++ b/queue-5.4/soc-fsl-dpio-get-the-cpumask-through-cpumask_of-cpu.patch @@ -0,0 +1,110 @@ +From 7d0d5498062742fcaa29c88fce759e8c7e4cb496 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 20 Oct 2020 10:18:32 +0800 +Subject: soc: fsl: dpio: Get the cpumask through cpumask_of(cpu) + +From: Hao Si + +[ Upstream commit 2663b3388551230cbc4606a40fabf3331ceb59e4 ] + +The local variable 'cpumask_t mask' is in the stack memory, and its address +is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'. +But the memory area where this variable is located is at risk of being +modified. + +During LTP testing, the following error was generated: + +Unable to handle kernel paging request at virtual address ffff000012e9b790 +Mem abort info: + ESR = 0x96000007 + Exception class = DABT (current EL), IL = 32 bits + SET = 0, FnV = 0 + EA = 0, S1PTW = 0 +Data abort info: + ISV = 0, ISS = 0x00000007 + CM = 0, WnR = 0 +swapper pgtable: 4k pages, 48-bit VAs, pgdp = 0000000075ac5e07 +[ffff000012e9b790] pgd=00000027dbffe003, pud=00000027dbffd003, +pmd=00000027b6d61003, pte=0000000000000000 +Internal error: Oops: 96000007 [#1] PREEMPT SMP +Modules linked in: xt_conntrack +Process read_all (pid: 20171, stack limit = 0x0000000044ea4095) +CPU: 14 PID: 20171 Comm: read_all Tainted: G B W +Hardware name: NXP Layerscape LX2160ARDB (DT) +pstate: 80000085 (Nzcv daIf -PAN -UAO) +pc : irq_affinity_hint_proc_show+0x54/0xb0 +lr : irq_affinity_hint_proc_show+0x4c/0xb0 +sp : ffff00001138bc10 +x29: ffff00001138bc10 x28: 0000ffffd131d1e0 +x27: 00000000007000c0 x26: ffff8025b9480dc0 +x25: ffff8025b9480da8 x24: 00000000000003ff +x23: ffff8027334f8300 x22: ffff80272e97d000 +x21: ffff80272e97d0b0 x20: ffff8025b9480d80 +x19: ffff000009a49000 x18: 0000000000000000 +x17: 0000000000000000 x16: 0000000000000000 +x15: 0000000000000000 x14: 0000000000000000 +x13: 0000000000000000 x12: 0000000000000040 +x11: 0000000000000000 x10: ffff802735b79b88 +x9 : 0000000000000000 x8 : 0000000000000000 +x7 : ffff000009a49848 x6 : 0000000000000003 +x5 : 0000000000000000 x4 : ffff000008157d6c +x3 : ffff00001138bc10 x2 : ffff000012e9b790 +x1 : 0000000000000000 x0 : 0000000000000000 +Call trace: + irq_affinity_hint_proc_show+0x54/0xb0 + seq_read+0x1b0/0x440 + proc_reg_read+0x80/0xd8 + __vfs_read+0x60/0x178 + vfs_read+0x94/0x150 + ksys_read+0x74/0xf0 + __arm64_sys_read+0x24/0x30 + el0_svc_common.constprop.0+0xd8/0x1a0 + el0_svc_handler+0x34/0x88 + el0_svc+0x10/0x14 +Code: f9001bbf 943e0732 f94066c2 b4000062 (f9400041) +---[ end trace b495bdcb0b3b732b ]--- +Kernel panic - not syncing: Fatal exception +SMP: stopping secondary CPUs +SMP: failed to stop secondary CPUs 0,2-4,6,8,11,13-15 +Kernel Offset: disabled +CPU features: 0x0,21006008 +Memory Limit: none +---[ end Kernel panic - not syncing: Fatal exception ]--- + +Fix it by using 'cpumask_of(cpu)' to get the cpumask. + +Signed-off-by: Hao Si +Signed-off-by: Lin Chen +Signed-off-by: Yi Wang +Signed-off-by: Li Yang +Signed-off-by: Sasha Levin +--- + drivers/soc/fsl/dpio/dpio-driver.c | 5 +---- + 1 file changed, 1 insertion(+), 4 deletions(-) + +diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c +index 7b642c330977f..7f397b4ad878d 100644 +--- a/drivers/soc/fsl/dpio/dpio-driver.c ++++ b/drivers/soc/fsl/dpio/dpio-driver.c +@@ -95,7 +95,6 @@ static int register_dpio_irq_handlers(struct fsl_mc_device *dpio_dev, int cpu) + { + int error; + struct fsl_mc_device_irq *irq; +- cpumask_t mask; + + irq = dpio_dev->irqs[0]; + error = devm_request_irq(&dpio_dev->dev, +@@ -112,9 +111,7 @@ static int register_dpio_irq_handlers(struct fsl_mc_device *dpio_dev, int cpu) + } + + /* set the affinity hint */ +- cpumask_clear(&mask); +- cpumask_set_cpu(cpu, &mask); +- if (irq_set_affinity_hint(irq->msi_desc->irq, &mask)) ++ if (irq_set_affinity_hint(irq->msi_desc->irq, cpumask_of(cpu))) + dev_err(&dpio_dev->dev, + "irq_set_affinity failed irq %d cpu %d\n", + irq->msi_desc->irq, cpu); +-- +2.27.0 + diff --git a/queue-5.4/spi-spi-nxp-fspi-fix-fspi-panic-by-unexpected-interr.patch b/queue-5.4/spi-spi-nxp-fspi-fix-fspi-panic-by-unexpected-interr.patch new file mode 100644 index 00000000000..6c9c843fc71 --- /dev/null +++ b/queue-5.4/spi-spi-nxp-fspi-fix-fspi-panic-by-unexpected-interr.patch @@ -0,0 +1,57 @@ +From d905423a7e7e584cfd5ccd52abf2c3a4b3cfabac Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 23 Nov 2020 10:57:15 +0800 +Subject: spi: spi-nxp-fspi: fix fspi panic by unexpected interrupts + +From: Ran Wang + +[ Upstream commit 71d80563b0760a411cd90a3680536f5d887fff6b ] + +Given the case that bootloader(such as UEFI)'s FSPI driver might not +handle all interrupts before loading kernel, those legacy interrupts +would assert immidiately once kernel's FSPI driver enable them. Further, +if it was FSPI_INTR_IPCMDDONE, the irq handler nxp_fspi_irq_handler() +would call complete(&f->c) to notify others. However, f->c might not be +initialized yet at that time, then cause kernel panic. + +Of cause, we should fix this issue within bootloader. But it would be +better to have this pacth to make dirver more robust (by clearing all +interrupt status bits before enabling interrupts). + +Suggested-by: Han Xu +Signed-off-by: Ran Wang +Link: https://lore.kernel.org/r/20201123025715.14635-1-ran.wang_1@nxp.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + drivers/spi/spi-nxp-fspi.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c +index 28ae5229f889f..efd9e908e2248 100644 +--- a/drivers/spi/spi-nxp-fspi.c ++++ b/drivers/spi/spi-nxp-fspi.c +@@ -948,6 +948,7 @@ static int nxp_fspi_probe(struct platform_device *pdev) + struct resource *res; + struct nxp_fspi *f; + int ret; ++ u32 reg; + + ctlr = spi_alloc_master(&pdev->dev, sizeof(*f)); + if (!ctlr) +@@ -974,6 +975,12 @@ static int nxp_fspi_probe(struct platform_device *pdev) + goto err_put_ctrl; + } + ++ /* Clear potential interrupts */ ++ reg = fspi_readl(f, f->iobase + FSPI_INTR); ++ if (reg) ++ fspi_writel(f, reg, f->iobase + FSPI_INTR); ++ ++ + /* find the resources - controller memory mapped space */ + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "fspi_mmap"); + f->ahb_addr = devm_ioremap_resource(dev, res); +-- +2.27.0 +