From: Greg Kroah-Hartman Date: Mon, 18 Oct 2021 10:56:13 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v4.14.252~21 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=2f8e870ebaa1f59eeac82c777320a3ebdf026b7a;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: iio-adc-aspeed-set-driver-data-when-adc-probe.patch iio-adc128s052-fix-the-error-handling-path-of-adc128_probe.patch iio-dac-ti-dac5571-fix-an-error-code-in-probe.patch iio-light-opt3001-fixed-timeout-error-when-0-lux.patch iio-mtk-auxadc-fix-case-iio_chan_info_processed.patch iio-ssp_sensors-add-more-range-checking-in-ssp_parse_dataframe.patch iio-ssp_sensors-fix-error-code-in-ssp_print_mcu_debug.patch kvm-ppc-book3s-hv-fix-stack-handling-in-idle_kvm_start_guest.patch kvm-ppc-book3s-hv-make-idle_kvm_start_guest-return-0-if-it-went-to-guest.patch powerpc-xive-discard-disabled-interrupts-in-get_irqchip_state.patch x86-kconfig-do-not-enable-amd_mem_encrypt_active_by_default-automatically.patch --- diff --git a/queue-5.4/iio-adc-aspeed-set-driver-data-when-adc-probe.patch b/queue-5.4/iio-adc-aspeed-set-driver-data-when-adc-probe.patch new file mode 100644 index 00000000000..4b92f01e550 --- /dev/null +++ b/queue-5.4/iio-adc-aspeed-set-driver-data-when-adc-probe.patch @@ -0,0 +1,31 @@ +From eb795cd97365a3d3d9da3926d234a7bc32a3bb15 Mon Sep 17 00:00:00 2001 +From: Billy Tsai +Date: Tue, 31 Aug 2021 15:14:44 +0800 +Subject: iio: adc: aspeed: set driver data when adc probe. + +From: Billy Tsai + +commit eb795cd97365a3d3d9da3926d234a7bc32a3bb15 upstream. + +Fix the issue when adc remove will get the null driver data. + +Fixed: commit 573803234e72 ("iio: Aspeed ADC") +Signed-off-by: Billy Tsai +Link: https://lore.kernel.org/r/20210831071458.2334-2-billy_tsai@aspeedtech.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/adc/aspeed_adc.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/iio/adc/aspeed_adc.c ++++ b/drivers/iio/adc/aspeed_adc.c +@@ -184,6 +184,7 @@ static int aspeed_adc_probe(struct platf + + data = iio_priv(indio_dev); + data->dev = &pdev->dev; ++ platform_set_drvdata(pdev, indio_dev); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + data->base = devm_ioremap_resource(&pdev->dev, res); diff --git a/queue-5.4/iio-adc128s052-fix-the-error-handling-path-of-adc128_probe.patch b/queue-5.4/iio-adc128s052-fix-the-error-handling-path-of-adc128_probe.patch new file mode 100644 index 00000000000..1561d91fe6a --- /dev/null +++ b/queue-5.4/iio-adc128s052-fix-the-error-handling-path-of-adc128_probe.patch @@ -0,0 +1,42 @@ +From bbcf40816b547b3c37af49168950491d20d81ce1 Mon Sep 17 00:00:00 2001 +From: Christophe JAILLET +Date: Sat, 21 Aug 2021 12:37:24 +0200 +Subject: iio: adc128s052: Fix the error handling path of 'adc128_probe()' + +From: Christophe JAILLET + +commit bbcf40816b547b3c37af49168950491d20d81ce1 upstream. + +A successful 'regulator_enable()' call should be balanced by a +corresponding 'regulator_disable()' call in the error handling path of the +probe, as already done in the remove function. + +Update the error handling path accordingly. + +Fixes: 913b86468674 ("iio: adc: Add TI ADC128S052") +Signed-off-by: Christophe JAILLET +Reviewed-by: Alexandru Ardelean +Link: https://lore.kernel.org/r/85189f1cfcf6f5f7b42d8730966f2a074b07b5f5.1629542160.git.christophe.jaillet@wanadoo.fr +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/adc/ti-adc128s052.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/iio/adc/ti-adc128s052.c ++++ b/drivers/iio/adc/ti-adc128s052.c +@@ -172,7 +172,13 @@ static int adc128_probe(struct spi_devic + mutex_init(&adc->lock); + + ret = iio_device_register(indio_dev); ++ if (ret) ++ goto err_disable_regulator; + ++ return 0; ++ ++err_disable_regulator: ++ regulator_disable(adc->reg); + return ret; + } + diff --git a/queue-5.4/iio-dac-ti-dac5571-fix-an-error-code-in-probe.patch b/queue-5.4/iio-dac-ti-dac5571-fix-an-error-code-in-probe.patch new file mode 100644 index 00000000000..dcdec99f69c --- /dev/null +++ b/queue-5.4/iio-dac-ti-dac5571-fix-an-error-code-in-probe.patch @@ -0,0 +1,31 @@ +From f7a28df7db84eb3410e9eca37832efa5aed93338 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Mon, 16 Aug 2021 21:39:54 +0300 +Subject: iio: dac: ti-dac5571: fix an error code in probe() + +From: Dan Carpenter + +commit f7a28df7db84eb3410e9eca37832efa5aed93338 upstream. + +If we have an unexpected number of channels then return -EINVAL instead +of returning success. + +Fixes: df38a4a72a3b ("iio: dac: add TI DAC5571 family support") +Signed-off-by: Dan Carpenter +Link: https://lore.kernel.org/r/20210816183954.GB2068@kili +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/dac/ti-dac5571.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/iio/dac/ti-dac5571.c ++++ b/drivers/iio/dac/ti-dac5571.c +@@ -352,6 +352,7 @@ static int dac5571_probe(struct i2c_clie + data->dac5571_pwrdwn = dac5571_pwrdwn_quad; + break; + default: ++ ret = -EINVAL; + goto err; + } + diff --git a/queue-5.4/iio-light-opt3001-fixed-timeout-error-when-0-lux.patch b/queue-5.4/iio-light-opt3001-fixed-timeout-error-when-0-lux.patch new file mode 100644 index 00000000000..cbe039d1e19 --- /dev/null +++ b/queue-5.4/iio-light-opt3001-fixed-timeout-error-when-0-lux.patch @@ -0,0 +1,44 @@ +From 26d90b5590579def54382a2fc34cfbe8518a9851 Mon Sep 17 00:00:00 2001 +From: Jiri Valek - 2N +Date: Mon, 20 Sep 2021 14:53:48 +0200 +Subject: iio: light: opt3001: Fixed timeout error when 0 lux + +From: Jiri Valek - 2N + +commit 26d90b5590579def54382a2fc34cfbe8518a9851 upstream. + +Reading from sensor returned timeout error under +zero light conditions. + +Signed-off-by: Jiri Valek - 2N +Fixes: ac663db3678a ("iio: light: opt3001: enable operation w/o IRQ") +Link: https://lore.kernel.org/r/20210920125351.6569-1-valek@2n.cz +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/light/opt3001.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/iio/light/opt3001.c ++++ b/drivers/iio/light/opt3001.c +@@ -275,6 +275,8 @@ static int opt3001_get_lux(struct opt300 + ret = wait_event_timeout(opt->result_ready_queue, + opt->result_ready, + msecs_to_jiffies(OPT3001_RESULT_READY_LONG)); ++ if (ret == 0) ++ return -ETIMEDOUT; + } else { + /* Sleep for result ready time */ + timeout = (opt->int_time == OPT3001_INT_TIME_SHORT) ? +@@ -311,9 +313,7 @@ err: + /* Disallow IRQ to access the device while lock is active */ + opt->ok_to_ignore_lock = false; + +- if (ret == 0) +- return -ETIMEDOUT; +- else if (ret < 0) ++ if (ret < 0) + return ret; + + if (opt->use_irq) { diff --git a/queue-5.4/iio-mtk-auxadc-fix-case-iio_chan_info_processed.patch b/queue-5.4/iio-mtk-auxadc-fix-case-iio_chan_info_processed.patch new file mode 100644 index 00000000000..729820dace7 --- /dev/null +++ b/queue-5.4/iio-mtk-auxadc-fix-case-iio_chan_info_processed.patch @@ -0,0 +1,48 @@ +From c2980c64c7fd4585d684574c92d1624d44961edd Mon Sep 17 00:00:00 2001 +From: Hui Liu +Date: Sun, 26 Sep 2021 15:30:28 +0800 +Subject: iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED + +From: Hui Liu + +commit c2980c64c7fd4585d684574c92d1624d44961edd upstream. + +The previous driver does't apply the necessary scaling to take the +voltage range into account. +We change readback value from raw data to input voltage to fix case +IIO_CHAN_INFO_PROCESSED. + +Fixes: ace4cdfe67be ("iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.") +Signed-off-by: Hui Liu +Link: https://lore.kernel.org/r/20210926073028.11045-2-hui.liu@mediatek.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/adc/mt6577_auxadc.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/iio/adc/mt6577_auxadc.c ++++ b/drivers/iio/adc/mt6577_auxadc.c +@@ -82,6 +82,10 @@ static const struct iio_chan_spec mt6577 + MT6577_AUXADC_CHANNEL(15), + }; + ++/* For Voltage calculation */ ++#define VOLTAGE_FULL_RANGE 1500 /* VA voltage */ ++#define AUXADC_PRECISE 4096 /* 12 bits */ ++ + static int mt_auxadc_get_cali_data(int rawdata, bool enable_cali) + { + return rawdata; +@@ -191,6 +195,10 @@ static int mt6577_auxadc_read_raw(struct + } + if (adc_dev->dev_comp->sample_data_cali) + *val = mt_auxadc_get_cali_data(*val, true); ++ ++ /* Convert adc raw data to voltage: 0 - 1500 mV */ ++ *val = *val * VOLTAGE_FULL_RANGE / AUXADC_PRECISE; ++ + return IIO_VAL_INT; + + default: diff --git a/queue-5.4/iio-ssp_sensors-add-more-range-checking-in-ssp_parse_dataframe.patch b/queue-5.4/iio-ssp_sensors-add-more-range-checking-in-ssp_parse_dataframe.patch new file mode 100644 index 00000000000..48157f462d9 --- /dev/null +++ b/queue-5.4/iio-ssp_sensors-add-more-range-checking-in-ssp_parse_dataframe.patch @@ -0,0 +1,57 @@ +From 8167c9a375ccceed19048ad9d68cb2d02ed276e0 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Thu, 9 Sep 2021 12:13:36 +0300 +Subject: iio: ssp_sensors: add more range checking in ssp_parse_dataframe() + +From: Dan Carpenter + +commit 8167c9a375ccceed19048ad9d68cb2d02ed276e0 upstream. + +The "idx" is validated at the start of the loop but it gets incremented +during the iteration so it needs to be checked again. + +Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") +Signed-off-by: Dan Carpenter +Link: https://lore.kernel.org/r/20210909091336.GA26312@kili +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/common/ssp_sensors/ssp_spi.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/iio/common/ssp_sensors/ssp_spi.c ++++ b/drivers/iio/common/ssp_sensors/ssp_spi.c +@@ -273,6 +273,8 @@ static int ssp_parse_dataframe(struct ss + for (idx = 0; idx < len;) { + switch (dataframe[idx++]) { + case SSP_MSG2AP_INST_BYPASS_DATA: ++ if (idx >= len) ++ return -EPROTO; + sd = dataframe[idx++]; + if (sd < 0 || sd >= SSP_SENSOR_MAX) { + dev_err(SSP_DEV, +@@ -282,10 +284,13 @@ static int ssp_parse_dataframe(struct ss + + if (indio_devs[sd]) { + spd = iio_priv(indio_devs[sd]); +- if (spd->process_data) ++ if (spd->process_data) { ++ if (idx >= len) ++ return -EPROTO; + spd->process_data(indio_devs[sd], + &dataframe[idx], + data->timestamp); ++ } + } else { + dev_err(SSP_DEV, "no client for frame\n"); + } +@@ -293,6 +298,8 @@ static int ssp_parse_dataframe(struct ss + idx += ssp_offset_map[sd]; + break; + case SSP_MSG2AP_INST_DEBUG_DATA: ++ if (idx >= len) ++ return -EPROTO; + sd = ssp_print_mcu_debug(dataframe, &idx, len); + if (sd) { + dev_err(SSP_DEV, diff --git a/queue-5.4/iio-ssp_sensors-fix-error-code-in-ssp_print_mcu_debug.patch b/queue-5.4/iio-ssp_sensors-fix-error-code-in-ssp_print_mcu_debug.patch new file mode 100644 index 00000000000..c4ac7e17250 --- /dev/null +++ b/queue-5.4/iio-ssp_sensors-fix-error-code-in-ssp_print_mcu_debug.patch @@ -0,0 +1,35 @@ +From 4170d3dd1467e9d78cb9af374b19357dc324b328 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Tue, 14 Sep 2021 13:53:33 +0300 +Subject: iio: ssp_sensors: fix error code in ssp_print_mcu_debug() + +From: Dan Carpenter + +commit 4170d3dd1467e9d78cb9af374b19357dc324b328 upstream. + +The ssp_print_mcu_debug() function should return negative error codes on +error. Returning "length" is meaningless. This change does not affect +runtime because the callers only care about zero/non-zero. + +Reported-by: Jonathan Cameron +Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") +Signed-off-by: Dan Carpenter +Link: https://lore.kernel.org/r/20210914105333.GA11657@kili +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/common/ssp_sensors/ssp_spi.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/common/ssp_sensors/ssp_spi.c ++++ b/drivers/iio/common/ssp_sensors/ssp_spi.c +@@ -137,7 +137,7 @@ static int ssp_print_mcu_debug(char *dat + if (length > received_len - *data_index || length <= 0) { + ssp_dbg("[SSP]: MSG From MCU-invalid debug length(%d/%d)\n", + length, received_len); +- return length ? length : -EPROTO; ++ return -EPROTO; + } + + ssp_dbg("[SSP]: MSG From MCU - %s\n", &data_frame[*data_index]); diff --git a/queue-5.4/kvm-ppc-book3s-hv-fix-stack-handling-in-idle_kvm_start_guest.patch b/queue-5.4/kvm-ppc-book3s-hv-fix-stack-handling-in-idle_kvm_start_guest.patch new file mode 100644 index 00000000000..26345499222 --- /dev/null +++ b/queue-5.4/kvm-ppc-book3s-hv-fix-stack-handling-in-idle_kvm_start_guest.patch @@ -0,0 +1,105 @@ +From 9b4416c5095c20e110c82ae602c254099b83b72f Mon Sep 17 00:00:00 2001 +From: Michael Ellerman +Date: Fri, 15 Oct 2021 23:01:48 +1100 +Subject: KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest() + +From: Michael Ellerman + +commit 9b4416c5095c20e110c82ae602c254099b83b72f upstream. + +In commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in +C") kvm_start_guest() became idle_kvm_start_guest(). The old code +allocated a stack frame on the emergency stack, but didn't use the +frame to store anything, and also didn't store anything in its caller's +frame. + +idle_kvm_start_guest() on the other hand is written more like a normal C +function, it creates a frame on entry, and also stores CR/LR into its +callers frame (per the ABI). The problem is that there is no caller +frame on the emergency stack. + +The emergency stack for a given CPU is allocated with: + + paca_ptrs[i]->emergency_sp = alloc_stack(limit, i) + THREAD_SIZE; + +So emergency_sp actually points to the first address above the emergency +stack allocation for a given CPU, we must not store above it without +first decrementing it to create a frame. This is different to the +regular kernel stack, paca->kstack, which is initialised to point at an +initial frame that is ready to use. + +idle_kvm_start_guest() stores the backchain, CR and LR all of which +write outside the allocation for the emergency stack. It then creates a +stack frame and saves the non-volatile registers. Unfortunately the +frame it creates is not large enough to fit the non-volatiles, and so +the saving of the non-volatile registers also writes outside the +emergency stack allocation. + +The end result is that we corrupt whatever is at 0-24 bytes, and 112-248 +bytes above the emergency stack allocation. + +In practice this has gone unnoticed because the memory immediately above +the emergency stack happens to be used for other stack allocations, +either another CPUs mc_emergency_sp or an IRQ stack. See the order of +calls to irqstack_early_init() and emergency_stack_init(). + +The low addresses of another stack are the top of that stack, and so are +only used if that stack is under extreme pressue, which essentially +never happens in practice - and if it did there's a high likelyhood we'd +crash due to that stack overflowing. + +Still, we shouldn't be corrupting someone else's stack, and it is purely +luck that we aren't corrupting something else. + +To fix it we save CR/LR into the caller's frame using the existing r1 on +entry, we then create a SWITCH_FRAME_SIZE frame (which has space for +pt_regs) on the emergency stack with the backchain pointing to the +existing stack, and then finally we switch to the new frame on the +emergency stack. + +Fixes: 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C") +Cc: stable@vger.kernel.org # v5.2+ +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20211015133929.832061-1-mpe@ellerman.id.au +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/kvm/book3s_hv_rmhandlers.S | 19 ++++++++++--------- + 1 file changed, 10 insertions(+), 9 deletions(-) + +--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S ++++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S +@@ -292,13 +292,15 @@ kvm_novcpu_exit: + * r3 contains the SRR1 wakeup value, SRR1 is trashed. + */ + _GLOBAL(idle_kvm_start_guest) +- ld r4,PACAEMERGSP(r13) + mfcr r5 + mflr r0 +- std r1,0(r4) +- std r5,8(r4) +- std r0,16(r4) +- subi r1,r4,STACK_FRAME_OVERHEAD ++ std r5, 8(r1) // Save CR in caller's frame ++ std r0, 16(r1) // Save LR in caller's frame ++ // Create frame on emergency stack ++ ld r4, PACAEMERGSP(r13) ++ stdu r1, -SWITCH_FRAME_SIZE(r4) ++ // Switch to new frame on emergency stack ++ mr r1, r4 + SAVE_NVGPRS(r1) + + /* +@@ -444,10 +446,9 @@ kvm_no_guest: + /* set up r3 for return */ + mfspr r3,SPRN_SRR1 + REST_NVGPRS(r1) +- addi r1, r1, STACK_FRAME_OVERHEAD +- ld r0, 16(r1) +- ld r5, 8(r1) +- ld r1, 0(r1) ++ ld r1, 0(r1) // Switch back to caller stack ++ ld r0, 16(r1) // Reload LR ++ ld r5, 8(r1) // Reload CR + mtlr r0 + mtcr r5 + blr diff --git a/queue-5.4/kvm-ppc-book3s-hv-make-idle_kvm_start_guest-return-0-if-it-went-to-guest.patch b/queue-5.4/kvm-ppc-book3s-hv-make-idle_kvm_start_guest-return-0-if-it-went-to-guest.patch new file mode 100644 index 00000000000..c23921e2936 --- /dev/null +++ b/queue-5.4/kvm-ppc-book3s-hv-make-idle_kvm_start_guest-return-0-if-it-went-to-guest.patch @@ -0,0 +1,71 @@ +From cdeb5d7d890e14f3b70e8087e745c4a6a7d9f337 Mon Sep 17 00:00:00 2001 +From: Michael Ellerman +Date: Fri, 15 Oct 2021 23:02:08 +1100 +Subject: KVM: PPC: Book3S HV: Make idle_kvm_start_guest() return 0 if it went to guest + +From: Michael Ellerman + +commit cdeb5d7d890e14f3b70e8087e745c4a6a7d9f337 upstream. + +We call idle_kvm_start_guest() from power7_offline() if the thread has +been requested to enter KVM. We pass it the SRR1 value that was returned +from power7_idle_insn() which tells us what sort of wakeup we're +processing. + +Depending on the SRR1 value we pass in, the KVM code might enter the +guest, or it might return to us to do some host action if the wakeup +requires it. + +If idle_kvm_start_guest() is able to handle the wakeup, and enter the +guest it is supposed to indicate that by returning a zero SRR1 value to +us. + +That was the behaviour prior to commit 10d91611f426 ("powerpc/64s: +Reimplement book3s idle code in C"), however in that commit the +handling of SRR1 was reworked, and the zeroing behaviour was lost. + +Returning from idle_kvm_start_guest() without zeroing the SRR1 value can +confuse the host offline code, causing the guest to crash and other +weirdness. + +Fixes: 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C") +Cc: stable@vger.kernel.org # v5.2+ +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20211015133929.832061-2-mpe@ellerman.id.au +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/kvm/book3s_hv_rmhandlers.S | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S ++++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S +@@ -301,6 +301,7 @@ _GLOBAL(idle_kvm_start_guest) + stdu r1, -SWITCH_FRAME_SIZE(r4) + // Switch to new frame on emergency stack + mr r1, r4 ++ std r3, 32(r1) // Save SRR1 wakeup value + SAVE_NVGPRS(r1) + + /* +@@ -352,6 +353,10 @@ kvm_unsplit_wakeup: + + kvm_secondary_got_guest: + ++ // About to go to guest, clear saved SRR1 ++ li r0, 0 ++ std r0, 32(r1) ++ + /* Set HSTATE_DSCR(r13) to something sensible */ + ld r6, PACA_DSCR_DEFAULT(r13) + std r6, HSTATE_DSCR(r13) +@@ -443,8 +448,8 @@ kvm_no_guest: + mfspr r4, SPRN_LPCR + rlwimi r4, r3, 0, LPCR_PECE0 | LPCR_PECE1 + mtspr SPRN_LPCR, r4 +- /* set up r3 for return */ +- mfspr r3,SPRN_SRR1 ++ // Return SRR1 wakeup value, or 0 if we went into the guest ++ ld r3, 32(r1) + REST_NVGPRS(r1) + ld r1, 0(r1) // Switch back to caller stack + ld r0, 16(r1) // Reload LR diff --git a/queue-5.4/powerpc-xive-discard-disabled-interrupts-in-get_irqchip_state.patch b/queue-5.4/powerpc-xive-discard-disabled-interrupts-in-get_irqchip_state.patch new file mode 100644 index 00000000000..3b5652dfa22 --- /dev/null +++ b/queue-5.4/powerpc-xive-discard-disabled-interrupts-in-get_irqchip_state.patch @@ -0,0 +1,48 @@ +From 6f779e1d359b8d5801f677c1d49dcfa10bf95674 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= +Date: Mon, 11 Oct 2021 09:02:03 +0200 +Subject: powerpc/xive: Discard disabled interrupts in get_irqchip_state() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Cédric Le Goater + +commit 6f779e1d359b8d5801f677c1d49dcfa10bf95674 upstream. + +When an interrupt is passed through, the KVM XIVE device calls the +set_vcpu_affinity() handler which raises the P bit to mask the +interrupt and to catch any in-flight interrupts while routing the +interrupt to the guest. + +On the guest side, drivers (like some Intels) can request at probe +time some MSIs and call synchronize_irq() to check that there are no +in flight interrupts. This will call the XIVE get_irqchip_state() +handler which will always return true as the interrupt P bit has been +set on the host side and lock the CPU in an infinite loop. + +Fix that by discarding disabled interrupts in get_irqchip_state(). + +Fixes: da15c03b047d ("powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race") +Cc: stable@vger.kernel.org #v5.4+ +Signed-off-by: Cédric Le Goater +Tested-by: seeteena +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20211011070203.99726-1-clg@kaod.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/sysdev/xive/common.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/sysdev/xive/common.c ++++ b/arch/powerpc/sysdev/xive/common.c +@@ -990,7 +990,8 @@ static int xive_get_irqchip_state(struct + * interrupt to be inactive in that case. + */ + *state = (pq != XIVE_ESB_INVALID) && !xd->stale_p && +- (xd->saved_p || !!(pq & XIVE_ESB_VAL_P)); ++ (xd->saved_p || (!!(pq & XIVE_ESB_VAL_P) && ++ !irqd_irq_disabled(data))); + return 0; + default: + return -EINVAL; diff --git a/queue-5.4/series b/queue-5.4/series index 439d42b1972..190bfdd4baa 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -31,3 +31,14 @@ usb-serial-option-add-prod.-id-for-quectel-eg91.patch virtio-write-back-f_version_1-before-validate.patch edac-armada-xp-fix-output-of-uncorrectable-error-counter.patch nvmem-fix-shift-out-of-bound-ubsan-with-byte-size-cells.patch +kvm-ppc-book3s-hv-fix-stack-handling-in-idle_kvm_start_guest.patch +kvm-ppc-book3s-hv-make-idle_kvm_start_guest-return-0-if-it-went-to-guest.patch +x86-kconfig-do-not-enable-amd_mem_encrypt_active_by_default-automatically.patch +powerpc-xive-discard-disabled-interrupts-in-get_irqchip_state.patch +iio-adc-aspeed-set-driver-data-when-adc-probe.patch +iio-adc128s052-fix-the-error-handling-path-of-adc128_probe.patch +iio-mtk-auxadc-fix-case-iio_chan_info_processed.patch +iio-light-opt3001-fixed-timeout-error-when-0-lux.patch +iio-ssp_sensors-add-more-range-checking-in-ssp_parse_dataframe.patch +iio-ssp_sensors-fix-error-code-in-ssp_print_mcu_debug.patch +iio-dac-ti-dac5571-fix-an-error-code-in-probe.patch diff --git a/queue-5.4/x86-kconfig-do-not-enable-amd_mem_encrypt_active_by_default-automatically.patch b/queue-5.4/x86-kconfig-do-not-enable-amd_mem_encrypt_active_by_default-automatically.patch new file mode 100644 index 00000000000..35bc3ae7760 --- /dev/null +++ b/queue-5.4/x86-kconfig-do-not-enable-amd_mem_encrypt_active_by_default-automatically.patch @@ -0,0 +1,68 @@ +From 711885906b5c2df90746a51f4cd674f1ab9fbb1d Mon Sep 17 00:00:00 2001 +From: Borislav Petkov +Date: Wed, 6 Oct 2021 19:34:55 +0200 +Subject: x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT automatically + +From: Borislav Petkov + +commit 711885906b5c2df90746a51f4cd674f1ab9fbb1d upstream. + +This Kconfig option was added initially so that memory encryption is +enabled by default on machines which support it. + +However, devices which have DMA masks that are less than the bit +position of the encryption bit, aka C-bit, require the use of an IOMMU +or the use of SWIOTLB. + +If the IOMMU is disabled or in passthrough mode, the kernel would switch +to SWIOTLB bounce-buffering for those transfers. + +In order to avoid that, + + 2cc13bb4f59f ("iommu: Disable passthrough mode when SME is active") + +disables the default IOMMU passthrough mode so that devices for which the +default 256K DMA is insufficient, can use the IOMMU instead. + +However 2, there are cases where the IOMMU is disabled in the BIOS, etc. +(think the usual hardware folk "oops, I dropped the ball there" cases) or a +driver doesn't properly use the DMA APIs or a device has a firmware or +hardware bug, e.g.: + + ea68573d408f ("drm/amdgpu: Fail to load on RAVEN if SME is active") + +However 3, in the above GPU use case, there are APIs like Vulkan and +some OpenGL/OpenCL extensions which are under the assumption that +user-allocated memory can be passed in to the kernel driver and both the +GPU and CPU can do coherent and concurrent access to the same memory. +That cannot work with SWIOTLB bounce buffers, of course. + +So, in order for those devices to function, drop the "default y" for the +SME by default active option so that users who want to have SME enabled, +will need to either enable it in their config or use "mem_encrypt=on" on +the kernel command line. + + [ tlendacky: Generalize commit message. ] + +Fixes: 7744ccdbc16f ("x86/mm: Add Secure Memory Encryption (SME) support") +Reported-by: Paul Menzel +Signed-off-by: Borislav Petkov +Acked-by: Alex Deucher +Acked-by: Tom Lendacky +Cc: +Link: https://lkml.kernel.org/r/8bbacd0e-4580-3194-19d2-a0ecad7df09c@molgen.mpg.de +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/Kconfig | 1 - + 1 file changed, 1 deletion(-) + +--- a/arch/x86/Kconfig ++++ b/arch/x86/Kconfig +@@ -1541,7 +1541,6 @@ config AMD_MEM_ENCRYPT + + config AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT + bool "Activate AMD Secure Memory Encryption (SME) by default" +- default y + depends on AMD_MEM_ENCRYPT + ---help--- + Say yes to have system memory encrypted by default if running on