--- /dev/null
+From eb795cd97365a3d3d9da3926d234a7bc32a3bb15 Mon Sep 17 00:00:00 2001
+From: Billy Tsai <billy_tsai@aspeedtech.com>
+Date: Tue, 31 Aug 2021 15:14:44 +0800
+Subject: iio: adc: aspeed: set driver data when adc probe.
+
+From: Billy Tsai <billy_tsai@aspeedtech.com>
+
+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 <billy_tsai@aspeedtech.com>
+Link: https://lore.kernel.org/r/20210831071458.2334-2-billy_tsai@aspeedtech.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From bbcf40816b547b3c37af49168950491d20d81ce1 Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sat, 21 Aug 2021 12:37:24 +0200
+Subject: iio: adc128s052: Fix the error handling path of 'adc128_probe()'
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+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 <christophe.jaillet@wanadoo.fr>
+Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
+Link: https://lore.kernel.org/r/85189f1cfcf6f5f7b42d8730966f2a074b07b5f5.1629542160.git.christophe.jaillet@wanadoo.fr
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From f7a28df7db84eb3410e9eca37832efa5aed93338 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Mon, 16 Aug 2021 21:39:54 +0300
+Subject: iio: dac: ti-dac5571: fix an error code in probe()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+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 <dan.carpenter@oracle.com>
+Link: https://lore.kernel.org/r/20210816183954.GB2068@kili
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From 26d90b5590579def54382a2fc34cfbe8518a9851 Mon Sep 17 00:00:00 2001
+From: Jiri Valek - 2N <valek@2n.cz>
+Date: Mon, 20 Sep 2021 14:53:48 +0200
+Subject: iio: light: opt3001: Fixed timeout error when 0 lux
+
+From: Jiri Valek - 2N <valek@2n.cz>
+
+commit 26d90b5590579def54382a2fc34cfbe8518a9851 upstream.
+
+Reading from sensor returned timeout error under
+zero light conditions.
+
+Signed-off-by: Jiri Valek - 2N <valek@2n.cz>
+Fixes: ac663db3678a ("iio: light: opt3001: enable operation w/o IRQ")
+Link: https://lore.kernel.org/r/20210920125351.6569-1-valek@2n.cz
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) {
--- /dev/null
+From c2980c64c7fd4585d684574c92d1624d44961edd Mon Sep 17 00:00:00 2001
+From: Hui Liu <hui.liu@mediatek.com>
+Date: Sun, 26 Sep 2021 15:30:28 +0800
+Subject: iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED
+
+From: Hui Liu <hui.liu@mediatek.com>
+
+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 <hui.liu@mediatek.com>
+Link: https://lore.kernel.org/r/20210926073028.11045-2-hui.liu@mediatek.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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:
--- /dev/null
+From 8167c9a375ccceed19048ad9d68cb2d02ed276e0 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Thu, 9 Sep 2021 12:13:36 +0300
+Subject: iio: ssp_sensors: add more range checking in ssp_parse_dataframe()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+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 <dan.carpenter@oracle.com>
+Link: https://lore.kernel.org/r/20210909091336.GA26312@kili
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From 4170d3dd1467e9d78cb9af374b19357dc324b328 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Tue, 14 Sep 2021 13:53:33 +0300
+Subject: iio: ssp_sensors: fix error code in ssp_print_mcu_debug()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+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 <jic23@kernel.org>
+Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Link: https://lore.kernel.org/r/20210914105333.GA11657@kili
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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]);
--- /dev/null
+From 9b4416c5095c20e110c82ae602c254099b83b72f Mon Sep 17 00:00:00 2001
+From: Michael Ellerman <mpe@ellerman.id.au>
+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 <mpe@ellerman.id.au>
+
+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 <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20211015133929.832061-1-mpe@ellerman.id.au
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From cdeb5d7d890e14f3b70e8087e745c4a6a7d9f337 Mon Sep 17 00:00:00 2001
+From: Michael Ellerman <mpe@ellerman.id.au>
+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 <mpe@ellerman.id.au>
+
+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 <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20211015133929.832061-2-mpe@ellerman.id.au
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 6f779e1d359b8d5801f677c1d49dcfa10bf95674 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>
+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 <clg@kaod.org>
+
+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 <clg@kaod.org>
+Tested-by: seeteena <s1seetee@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20211011070203.99726-1-clg@kaod.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
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
--- /dev/null
+From 711885906b5c2df90746a51f4cd674f1ab9fbb1d Mon Sep 17 00:00:00 2001
+From: Borislav Petkov <bp@suse.de>
+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 <bp@suse.de>
+
+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 <pmenzel@molgen.mpg.de>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Acked-by: Alex Deucher <alexander.deucher@amd.com>
+Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/8bbacd0e-4580-3194-19d2-a0ecad7df09c@molgen.mpg.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
projects / thirdparty / kernel / stable-queue.git / commitdiff
