--- /dev/null
+From 5881fa8dc2de9697a89451f6518e8b3a796c09c6 Mon Sep 17 00:00:00 2001
+From: Ondrej Mosnacek <omosnace@redhat.com>
+Date: Fri, 7 May 2021 14:53:04 +0200
+Subject: debugfs: fix security_locked_down() call for SELinux
+
+From: Ondrej Mosnacek <omosnace@redhat.com>
+
+commit 5881fa8dc2de9697a89451f6518e8b3a796c09c6 upstream.
+
+When (ia->ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID)) is zero, then
+the SELinux implementation of the locked_down hook might report a denial
+even though the operation would actually be allowed.
+
+To fix this, make sure that security_locked_down() is called only when
+the return value will be taken into account (i.e. when changing one of
+the problematic attributes).
+
+Note: this was introduced by commit 5496197f9b08 ("debugfs: Restrict
+debugfs when the kernel is locked down"), but it didn't matter at that
+time, as the SELinux support came in later.
+
+Fixes: 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
+Link: https://lore.kernel.org/r/20210507125304.144394-1-omosnace@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/debugfs/inode.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/fs/debugfs/inode.c
++++ b/fs/debugfs/inode.c
+@@ -45,10 +45,13 @@ static unsigned int debugfs_allow __ro_a
+ static int debugfs_setattr(struct user_namespace *mnt_userns,
+ struct dentry *dentry, struct iattr *ia)
+ {
+- int ret = security_locked_down(LOCKDOWN_DEBUGFS);
++ int ret;
+
+- if (ret && (ia->ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID)))
+- return ret;
++ if (ia->ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID)) {
++ ret = security_locked_down(LOCKDOWN_DEBUGFS);
++ if (ret)
++ return ret;
++ }
+ return simple_setattr(&init_user_ns, dentry, ia);
+ }
+
--- /dev/null
+From aac902925ea646e461c95edc98a8a57eb0def917 Mon Sep 17 00:00:00 2001
+From: Sargun Dhillon <sargun@sargun.me>
+Date: Mon, 17 May 2021 12:39:05 -0700
+Subject: Documentation: seccomp: Fix user notification documentation
+
+From: Sargun Dhillon <sargun@sargun.me>
+
+commit aac902925ea646e461c95edc98a8a57eb0def917 upstream.
+
+The documentation had some previously incorrect information about how
+userspace notifications (and responses) were handled due to a change
+from a previously proposed patchset.
+
+Signed-off-by: Sargun Dhillon <sargun@sargun.me>
+Acked-by: Tycho Andersen <tycho@tycho.pizza>
+Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210517193908.3113-2-sargun@sargun.me
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/userspace-api/seccomp_filter.rst | 16 ++++++++--------
+ 1 file changed, 8 insertions(+), 8 deletions(-)
+
+--- a/Documentation/userspace-api/seccomp_filter.rst
++++ b/Documentation/userspace-api/seccomp_filter.rst
+@@ -250,14 +250,14 @@ Users can read via ``ioctl(SECCOMP_IOCTL
+ seccomp notification fd to receive a ``struct seccomp_notif``, which contains
+ five members: the input length of the structure, a unique-per-filter ``id``,
+ the ``pid`` of the task which triggered this request (which may be 0 if the
+-task is in a pid ns not visible from the listener's pid namespace), a ``flags``
+-member which for now only has ``SECCOMP_NOTIF_FLAG_SIGNALED``, representing
+-whether or not the notification is a result of a non-fatal signal, and the
+-``data`` passed to seccomp. Userspace can then make a decision based on this
+-information about what to do, and ``ioctl(SECCOMP_IOCTL_NOTIF_SEND)`` a
+-response, indicating what should be returned to userspace. The ``id`` member of
+-``struct seccomp_notif_resp`` should be the same ``id`` as in ``struct
+-seccomp_notif``.
++task is in a pid ns not visible from the listener's pid namespace). The
++notification also contains the ``data`` passed to seccomp, and a filters flag.
++The structure should be zeroed out prior to calling the ioctl.
++
++Userspace can then make a decision based on this information about what to do,
++and ``ioctl(SECCOMP_IOCTL_NOTIF_SEND)`` a response, indicating what should be
++returned to userspace. The ``id`` member of ``struct seccomp_notif_resp`` should
++be the same ``id`` as in ``struct seccomp_notif``.
+
+ It is worth noting that ``struct seccomp_data`` contains the values of register
+ arguments to the syscall, but does not contain pointers to memory. The task's
--- /dev/null
+From 4573472315f0fa461330545ff2aa2f6da0b1ae76 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Thu, 13 May 2021 15:07:41 +0300
+Subject: iio: adc: ad7124: Fix missbalanced regulator enable / disable on error.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 4573472315f0fa461330545ff2aa2f6da0b1ae76 upstream.
+
+If the devm_regulator_get() call succeeded but not the regulator_enable()
+then regulator_disable() would be called on a regulator that was not
+enabled.
+
+Fix this by moving regulator enabling / disabling over to
+devm_ management via devm_add_action_or_reset.
+
+Alexandru's sign-off here because he pulled Jonathan's patch into
+a larger set which Jonathan then applied.
+
+Fixes: b3af341bbd96 ("iio: adc: Add ad7124 support")
+Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/ad7124.c | 29 +++++++++++++----------------
+ 1 file changed, 13 insertions(+), 16 deletions(-)
+
+--- a/drivers/iio/adc/ad7124.c
++++ b/drivers/iio/adc/ad7124.c
+@@ -707,6 +707,11 @@ static int ad7124_setup(struct ad7124_st
+ return ret;
+ }
+
++static void ad7124_reg_disable(void *r)
++{
++ regulator_disable(r);
++}
++
+ static int ad7124_probe(struct spi_device *spi)
+ {
+ const struct ad7124_chip_info *info;
+@@ -752,17 +757,20 @@ static int ad7124_probe(struct spi_devic
+ ret = regulator_enable(st->vref[i]);
+ if (ret)
+ return ret;
++
++ ret = devm_add_action_or_reset(&spi->dev, ad7124_reg_disable,
++ st->vref[i]);
++ if (ret)
++ return ret;
+ }
+
+ st->mclk = devm_clk_get(&spi->dev, "mclk");
+- if (IS_ERR(st->mclk)) {
+- ret = PTR_ERR(st->mclk);
+- goto error_regulator_disable;
+- }
++ if (IS_ERR(st->mclk))
++ return PTR_ERR(st->mclk);
+
+ ret = clk_prepare_enable(st->mclk);
+ if (ret < 0)
+- goto error_regulator_disable;
++ return ret;
+
+ ret = ad7124_soft_reset(st);
+ if (ret < 0)
+@@ -792,11 +800,6 @@ error_remove_trigger:
+ ad_sd_cleanup_buffer_and_trigger(indio_dev);
+ error_clk_disable_unprepare:
+ clk_disable_unprepare(st->mclk);
+-error_regulator_disable:
+- for (i = ARRAY_SIZE(st->vref) - 1; i >= 0; i--) {
+- if (!IS_ERR_OR_NULL(st->vref[i]))
+- regulator_disable(st->vref[i]);
+- }
+
+ return ret;
+ }
+@@ -805,17 +808,11 @@ static int ad7124_remove(struct spi_devi
+ {
+ struct iio_dev *indio_dev = spi_get_drvdata(spi);
+ struct ad7124_state *st = iio_priv(indio_dev);
+- int i;
+
+ iio_device_unregister(indio_dev);
+ ad_sd_cleanup_buffer_and_trigger(indio_dev);
+ clk_disable_unprepare(st->mclk);
+
+- for (i = ARRAY_SIZE(st->vref) - 1; i >= 0; i--) {
+- if (!IS_ERR_OR_NULL(st->vref[i]))
+- regulator_disable(st->vref[i]);
+- }
+-
+ return 0;
+ }
+
--- /dev/null
+From f2a772c51206b0c3f262e4f6a3812c89a650191b Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Thu, 13 May 2021 15:07:42 +0300
+Subject: iio: adc: ad7124: Fix potential overflow due to non sequential channel numbers
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit f2a772c51206b0c3f262e4f6a3812c89a650191b upstream.
+
+Channel numbering must start at 0 and then not have any holes, or
+it is possible to overflow the available storage. Note this bug was
+introduced as part of a fix to ensure we didn't rely on the ordering
+of child nodes. So we need to support arbitrary ordering but they all
+need to be there somewhere.
+
+Note I hit this when using qemu to test the rest of this series.
+Arguably this isn't the best fix, but it is probably the most minimal
+option for backporting etc.
+
+Alexandru's sign-off is here because he carried this patch in a larger
+set that Jonathan then applied.
+
+Fixes: d7857e4ee1ba6 ("iio: adc: ad7124: Fix DT channel configuration")
+Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/ad7124.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/iio/adc/ad7124.c
++++ b/drivers/iio/adc/ad7124.c
+@@ -616,6 +616,13 @@ static int ad7124_of_parse_channel_confi
+ if (ret)
+ goto err;
+
++ if (channel >= indio_dev->num_channels) {
++ dev_err(indio_dev->dev.parent,
++ "Channel index >= number of channels\n");
++ ret = -EINVAL;
++ goto err;
++ }
++
+ ret = of_property_read_u32_array(child, "diff-channels",
+ ain, 2);
+ if (ret)
--- /dev/null
+From e32fe6d90f44922ccbb94016cfc3c238359e3e39 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Thu, 13 May 2021 15:07:43 +0300
+Subject: iio: adc: ad7192: Avoid disabling a clock that was never enabled.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit e32fe6d90f44922ccbb94016cfc3c238359e3e39 upstream.
+
+Found by inspection.
+
+If the internal clock source is being used, the driver doesn't
+call clk_prepare_enable() and as such we should not call
+clk_disable_unprepare()
+
+Use the same condition to protect the disable path as is used
+on the enable one. Note this will all get simplified when
+the driver moves over to a full devm_ flow, but that would make
+backporting the fix harder.
+
+Fix obviously predates move out of staging, but backporting will
+become more complex (and is unlikely to happen), hence that patch
+is given in the fixes tag.
+
+Alexandru's sign off is here because he added this patch into
+a larger series that Jonathan then applied.
+
+Fixes: b581f748cce0 ("staging: iio: adc: ad7192: move out of staging")
+Cc: Alexandru Tachici <alexandru.tachici@analog.com>
+Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/ad7192.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/adc/ad7192.c
++++ b/drivers/iio/adc/ad7192.c
+@@ -1014,7 +1014,9 @@ static int ad7192_probe(struct spi_devic
+ return 0;
+
+ error_disable_clk:
+- clk_disable_unprepare(st->mclk);
++ if (st->clock_sel == AD7192_CLK_EXT_MCLK1_2 ||
++ st->clock_sel == AD7192_CLK_EXT_MCLK2)
++ clk_disable_unprepare(st->mclk);
+ error_remove_trigger:
+ ad_sd_cleanup_buffer_and_trigger(indio_dev);
+ error_disable_dvdd:
+@@ -1031,7 +1033,9 @@ static int ad7192_remove(struct spi_devi
+ struct ad7192_state *st = iio_priv(indio_dev);
+
+ iio_device_unregister(indio_dev);
+- clk_disable_unprepare(st->mclk);
++ if (st->clock_sel == AD7192_CLK_EXT_MCLK1_2 ||
++ st->clock_sel == AD7192_CLK_EXT_MCLK2)
++ clk_disable_unprepare(st->mclk);
+ ad_sd_cleanup_buffer_and_trigger(indio_dev);
+
+ regulator_disable(st->dvdd);
--- /dev/null
+From b0f27fca5a6c7652e265aae6a4452ce2f2ed64da Mon Sep 17 00:00:00 2001
+From: Alexandru Ardelean <aardelean@deviqon.com>
+Date: Thu, 13 May 2021 15:07:44 +0300
+Subject: iio: adc: ad7192: handle regulator voltage error first
+
+From: Alexandru Ardelean <aardelean@deviqon.com>
+
+commit b0f27fca5a6c7652e265aae6a4452ce2f2ed64da upstream.
+
+This change fixes a corner-case, where for a zero regulator value, the
+driver would exit early, initializing the driver only partially.
+The driver would be in an unknown state.
+
+This change reworks the code to check regulator_voltage() return value
+for negative (error) first, and return early. This is the more common
+idiom.
+
+Also, this change is removing the 'voltage_uv' variable and using the 'ret'
+value directly. The only place where 'voltage_uv' is being used is to
+compute the internal reference voltage, and the type of this variable is
+'int' (same are for 'ret'). Using only 'ret' avoids having to assign it on
+the error path.
+
+Fixes: ab0afa65bbc7 ("staging: iio: adc: ad7192: fail probe on get_voltage")
+Cc: Alexandru Tachici <alexandru.tachici@analog.com>
+Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/ad7192.c | 11 ++++-------
+ 1 file changed, 4 insertions(+), 7 deletions(-)
+
+--- a/drivers/iio/adc/ad7192.c
++++ b/drivers/iio/adc/ad7192.c
+@@ -912,7 +912,7 @@ static int ad7192_probe(struct spi_devic
+ {
+ struct ad7192_state *st;
+ struct iio_dev *indio_dev;
+- int ret, voltage_uv = 0;
++ int ret;
+
+ if (!spi->irq) {
+ dev_err(&spi->dev, "no IRQ?\n");
+@@ -949,15 +949,12 @@ static int ad7192_probe(struct spi_devic
+ goto error_disable_avdd;
+ }
+
+- voltage_uv = regulator_get_voltage(st->avdd);
+-
+- if (voltage_uv > 0) {
+- st->int_vref_mv = voltage_uv / 1000;
+- } else {
+- ret = voltage_uv;
++ ret = regulator_get_voltage(st->avdd);
++ if (ret < 0) {
+ dev_err(&spi->dev, "Device tree error, reference voltage undefined\n");
+ goto error_disable_avdd;
+ }
++ st->int_vref_mv = ret / 1000;
+
+ spi_set_drvdata(spi, indio_dev);
+ st->chip_info = of_device_get_match_data(&spi->dev);
--- /dev/null
+From a1caeebab07e9d72eec534489f47964782b93ba9 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Sat, 1 May 2021 17:53:13 +0100
+Subject: iio: adc: ad7768-1: Fix too small buffer passed to iio_push_to_buffers_with_timestamp()
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit a1caeebab07e9d72eec534489f47964782b93ba9 upstream.
+
+Add space for the timestamp to be inserted. Also ensure correct
+alignment for passing to iio_push_to_buffers_with_timestamp()
+
+Fixes: a5f8c7da3dbe ("iio: adc: Add AD7768-1 ADC basic support")
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Link: https://lore.kernel.org/r/20210501165314.511954-2-jic23@kernel.org
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/ad7768-1.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/adc/ad7768-1.c
++++ b/drivers/iio/adc/ad7768-1.c
+@@ -167,6 +167,10 @@ struct ad7768_state {
+ * transfer buffers to live in their own cache lines.
+ */
+ union {
++ struct {
++ __be32 chan;
++ s64 timestamp;
++ } scan;
+ __be32 d32;
+ u8 d8[2];
+ } data ____cacheline_aligned;
+@@ -469,11 +473,11 @@ static irqreturn_t ad7768_trigger_handle
+
+ mutex_lock(&st->lock);
+
+- ret = spi_read(st->spi, &st->data.d32, 3);
++ ret = spi_read(st->spi, &st->data.scan.chan, 3);
+ if (ret < 0)
+ goto err_unlock;
+
+- iio_push_to_buffers_with_timestamp(indio_dev, &st->data.d32,
++ iio_push_to_buffers_with_timestamp(indio_dev, &st->data.scan,
+ iio_get_time_ns(indio_dev));
+
+ iio_trigger_notify_done(indio_dev->trig);
--- /dev/null
+From 4ed243b1da169bcbc1ec5507867e56250c5f1ff9 Mon Sep 17 00:00:00 2001
+From: YueHaibing <yuehaibing@huawei.com>
+Date: Fri, 14 May 2021 16:02:54 +0800
+Subject: iio: adc: ad7793: Add missing error code in ad7793_setup()
+
+From: YueHaibing <yuehaibing@huawei.com>
+
+commit 4ed243b1da169bcbc1ec5507867e56250c5f1ff9 upstream.
+
+Set error code while device ID query failed.
+
+Fixes: 88bc30548aae ("IIO: ADC: New driver for AD7792/AD7793 3 Channel SPI ADC")
+Signed-off-by: YueHaibing <yuehaibing@huawei.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/ad7793.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/iio/adc/ad7793.c
++++ b/drivers/iio/adc/ad7793.c
+@@ -279,6 +279,7 @@ static int ad7793_setup(struct iio_dev *
+ id &= AD7793_ID_MASK;
+
+ if (id != st->chip_info->id) {
++ ret = -ENODEV;
+ dev_err(&st->sd.spi->dev, "device ID query failed\n");
+ goto out;
+ }
--- /dev/null
+From 01fcf129f61b26d5b3d2d8afb03e770dee271bc8 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Sat, 1 May 2021 17:53:14 +0100
+Subject: iio: adc: ad7923: Fix undersized rx buffer.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 01fcf129f61b26d5b3d2d8afb03e770dee271bc8 upstream.
+
+Fixes tag is where the max channels became 8, but timestamp space was missing
+before that.
+
+Fixes: 851644a60d20 ("iio: adc: ad7923: Add support for the ad7908/ad7918/ad7928")
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Cc: Daniel Junho <djunho@gmail.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Link: https://lore.kernel.org/r/20210501165314.511954-3-jic23@kernel.org
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/ad7923.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/iio/adc/ad7923.c
++++ b/drivers/iio/adc/ad7923.c
+@@ -59,8 +59,10 @@ struct ad7923_state {
+ /*
+ * DMA (thus cache coherency maintenance) requires the
+ * transfer buffers to live in their own cache lines.
++ * Ensure rx_buf can be directly used in iio_push_to_buffers_with_timetamp
++ * Length = 8 channels + 4 extra for 8 byte timestamp
+ */
+- __be16 rx_buf[4] ____cacheline_aligned;
++ __be16 rx_buf[12] ____cacheline_aligned;
+ __be16 tx_buf[4];
+ };
+
--- /dev/null
+From 98b7b0ca0828907dbb706387c11356a45463e2ea Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andy.shevchenko@gmail.com>
+Date: Mon, 10 May 2021 12:56:49 +0300
+Subject: iio: dac: ad5770r: Put fwnode in error case during ->probe()
+
+From: Andy Shevchenko <andy.shevchenko@gmail.com>
+
+commit 98b7b0ca0828907dbb706387c11356a45463e2ea upstream.
+
+device_for_each_child_node() bumps a reference counting of a returned variable.
+We have to balance it whenever we return to the caller.
+
+Fixes: cbbb819837f6 ("iio: dac: ad5770r: Add AD5770R support")
+Cc: Alexandru Tachici <alexandru.tachici@analog.com>
+Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
+Link: https://lore.kernel.org/r/20210510095649.3302835-1-andy.shevchenko@gmail.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/dac/ad5770r.c | 16 +++++++++++-----
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+--- a/drivers/iio/dac/ad5770r.c
++++ b/drivers/iio/dac/ad5770r.c
+@@ -524,23 +524,29 @@ static int ad5770r_channel_config(struct
+ device_for_each_child_node(&st->spi->dev, child) {
+ ret = fwnode_property_read_u32(child, "num", &num);
+ if (ret)
+- return ret;
+- if (num >= AD5770R_MAX_CHANNELS)
+- return -EINVAL;
++ goto err_child_out;
++ if (num >= AD5770R_MAX_CHANNELS) {
++ ret = -EINVAL;
++ goto err_child_out;
++ }
+
+ ret = fwnode_property_read_u32_array(child,
+ "adi,range-microamp",
+ tmp, 2);
+ if (ret)
+- return ret;
++ goto err_child_out;
+
+ min = tmp[0] / 1000;
+ max = tmp[1] / 1000;
+ ret = ad5770r_store_output_range(st, min, max, num);
+ if (ret)
+- return ret;
++ goto err_child_out;
+ }
+
++ return 0;
++
++err_child_out:
++ fwnode_handle_put(child);
+ return ret;
+ }
+
--- /dev/null
+From 2a54c8c9ebc2006bf72554afc84ffc67768979a0 Mon Sep 17 00:00:00 2001
+From: Rui Miguel Silva <rui.silva@linaro.org>
+Date: Wed, 12 May 2021 23:39:29 +0100
+Subject: iio: gyro: fxas21002c: balance runtime power in error path
+
+From: Rui Miguel Silva <rui.silva@linaro.org>
+
+commit 2a54c8c9ebc2006bf72554afc84ffc67768979a0 upstream.
+
+If we fail to read temperature or axis we need to decrement the
+runtime pm reference count to trigger autosuspend.
+
+Add the call to pm_put to do that in case of error.
+
+Fixes: a0701b6263ae ("iio: gyro: add core driver for fxas21002c")
+Suggested-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
+Link: https://lore.kernel.org/linux-iio/CBBZA9T1OY9C.2611WSV49DV2G@arch-thunder/
+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/gyro/fxas21002c_core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/iio/gyro/fxas21002c_core.c
++++ b/drivers/iio/gyro/fxas21002c_core.c
+@@ -399,6 +399,7 @@ static int fxas21002c_temp_get(struct fx
+ ret = regmap_field_read(data->regmap_fields[F_TEMP], &temp);
+ if (ret < 0) {
+ dev_err(dev, "failed to read temp: %d\n", ret);
++ fxas21002c_pm_put(data);
+ goto data_unlock;
+ }
+
+@@ -432,6 +433,7 @@ static int fxas21002c_axis_get(struct fx
+ &axis_be, sizeof(axis_be));
+ if (ret < 0) {
+ dev_err(dev, "failed to read axis: %d: %d\n", index, ret);
++ fxas21002c_pm_put(data);
+ goto data_unlock;
+ }
+
--- /dev/null
+From cb853ded1d25e5b026ce115dbcde69e3d7e2e831 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Fri, 14 May 2021 09:05:41 +0100
+Subject: KVM: arm64: Fix debug register indexing
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit cb853ded1d25e5b026ce115dbcde69e3d7e2e831 upstream.
+
+Commit 03fdfb2690099 ("KVM: arm64: Don't write junk to sysregs on
+reset") flipped the register number to 0 for all the debug registers
+in the sysreg table, hereby indicating that these registers live
+in a separate shadow structure.
+
+However, the author of this patch failed to realise that all the
+accessors are using that particular index instead of the register
+encoding, resulting in all the registers hitting index 0. Not quite
+a valid implementation of the architecture...
+
+Address the issue by fixing all the accessors to use the CRm field
+of the encoding, which contains the debug register index.
+
+Fixes: 03fdfb2690099 ("KVM: arm64: Don't write junk to sysregs on reset")
+Reported-by: Ricardo Koller <ricarkol@google.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kvm/sys_regs.c | 42 +++++++++++++++++++++---------------------
+ 1 file changed, 21 insertions(+), 21 deletions(-)
+
+--- a/arch/arm64/kvm/sys_regs.c
++++ b/arch/arm64/kvm/sys_regs.c
+@@ -399,14 +399,14 @@ static bool trap_bvr(struct kvm_vcpu *vc
+ struct sys_reg_params *p,
+ const struct sys_reg_desc *rd)
+ {
+- u64 *dbg_reg = &vcpu->arch.vcpu_debug_state.dbg_bvr[rd->reg];
++ u64 *dbg_reg = &vcpu->arch.vcpu_debug_state.dbg_bvr[rd->CRm];
+
+ if (p->is_write)
+ reg_to_dbg(vcpu, p, rd, dbg_reg);
+ else
+ dbg_to_reg(vcpu, p, rd, dbg_reg);
+
+- trace_trap_reg(__func__, rd->reg, p->is_write, *dbg_reg);
++ trace_trap_reg(__func__, rd->CRm, p->is_write, *dbg_reg);
+
+ return true;
+ }
+@@ -414,7 +414,7 @@ static bool trap_bvr(struct kvm_vcpu *vc
+ static int set_bvr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
+ const struct kvm_one_reg *reg, void __user *uaddr)
+ {
+- __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_bvr[rd->reg];
++ __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_bvr[rd->CRm];
+
+ if (copy_from_user(r, uaddr, KVM_REG_SIZE(reg->id)) != 0)
+ return -EFAULT;
+@@ -424,7 +424,7 @@ static int set_bvr(struct kvm_vcpu *vcpu
+ static int get_bvr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
+ const struct kvm_one_reg *reg, void __user *uaddr)
+ {
+- __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_bvr[rd->reg];
++ __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_bvr[rd->CRm];
+
+ if (copy_to_user(uaddr, r, KVM_REG_SIZE(reg->id)) != 0)
+ return -EFAULT;
+@@ -434,21 +434,21 @@ static int get_bvr(struct kvm_vcpu *vcpu
+ static void reset_bvr(struct kvm_vcpu *vcpu,
+ const struct sys_reg_desc *rd)
+ {
+- vcpu->arch.vcpu_debug_state.dbg_bvr[rd->reg] = rd->val;
++ vcpu->arch.vcpu_debug_state.dbg_bvr[rd->CRm] = rd->val;
+ }
+
+ static bool trap_bcr(struct kvm_vcpu *vcpu,
+ struct sys_reg_params *p,
+ const struct sys_reg_desc *rd)
+ {
+- u64 *dbg_reg = &vcpu->arch.vcpu_debug_state.dbg_bcr[rd->reg];
++ u64 *dbg_reg = &vcpu->arch.vcpu_debug_state.dbg_bcr[rd->CRm];
+
+ if (p->is_write)
+ reg_to_dbg(vcpu, p, rd, dbg_reg);
+ else
+ dbg_to_reg(vcpu, p, rd, dbg_reg);
+
+- trace_trap_reg(__func__, rd->reg, p->is_write, *dbg_reg);
++ trace_trap_reg(__func__, rd->CRm, p->is_write, *dbg_reg);
+
+ return true;
+ }
+@@ -456,7 +456,7 @@ static bool trap_bcr(struct kvm_vcpu *vc
+ static int set_bcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
+ const struct kvm_one_reg *reg, void __user *uaddr)
+ {
+- __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_bcr[rd->reg];
++ __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_bcr[rd->CRm];
+
+ if (copy_from_user(r, uaddr, KVM_REG_SIZE(reg->id)) != 0)
+ return -EFAULT;
+@@ -467,7 +467,7 @@ static int set_bcr(struct kvm_vcpu *vcpu
+ static int get_bcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
+ const struct kvm_one_reg *reg, void __user *uaddr)
+ {
+- __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_bcr[rd->reg];
++ __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_bcr[rd->CRm];
+
+ if (copy_to_user(uaddr, r, KVM_REG_SIZE(reg->id)) != 0)
+ return -EFAULT;
+@@ -477,22 +477,22 @@ static int get_bcr(struct kvm_vcpu *vcpu
+ static void reset_bcr(struct kvm_vcpu *vcpu,
+ const struct sys_reg_desc *rd)
+ {
+- vcpu->arch.vcpu_debug_state.dbg_bcr[rd->reg] = rd->val;
++ vcpu->arch.vcpu_debug_state.dbg_bcr[rd->CRm] = rd->val;
+ }
+
+ static bool trap_wvr(struct kvm_vcpu *vcpu,
+ struct sys_reg_params *p,
+ const struct sys_reg_desc *rd)
+ {
+- u64 *dbg_reg = &vcpu->arch.vcpu_debug_state.dbg_wvr[rd->reg];
++ u64 *dbg_reg = &vcpu->arch.vcpu_debug_state.dbg_wvr[rd->CRm];
+
+ if (p->is_write)
+ reg_to_dbg(vcpu, p, rd, dbg_reg);
+ else
+ dbg_to_reg(vcpu, p, rd, dbg_reg);
+
+- trace_trap_reg(__func__, rd->reg, p->is_write,
+- vcpu->arch.vcpu_debug_state.dbg_wvr[rd->reg]);
++ trace_trap_reg(__func__, rd->CRm, p->is_write,
++ vcpu->arch.vcpu_debug_state.dbg_wvr[rd->CRm]);
+
+ return true;
+ }
+@@ -500,7 +500,7 @@ static bool trap_wvr(struct kvm_vcpu *vc
+ static int set_wvr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
+ const struct kvm_one_reg *reg, void __user *uaddr)
+ {
+- __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_wvr[rd->reg];
++ __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_wvr[rd->CRm];
+
+ if (copy_from_user(r, uaddr, KVM_REG_SIZE(reg->id)) != 0)
+ return -EFAULT;
+@@ -510,7 +510,7 @@ static int set_wvr(struct kvm_vcpu *vcpu
+ static int get_wvr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
+ const struct kvm_one_reg *reg, void __user *uaddr)
+ {
+- __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_wvr[rd->reg];
++ __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_wvr[rd->CRm];
+
+ if (copy_to_user(uaddr, r, KVM_REG_SIZE(reg->id)) != 0)
+ return -EFAULT;
+@@ -520,21 +520,21 @@ static int get_wvr(struct kvm_vcpu *vcpu
+ static void reset_wvr(struct kvm_vcpu *vcpu,
+ const struct sys_reg_desc *rd)
+ {
+- vcpu->arch.vcpu_debug_state.dbg_wvr[rd->reg] = rd->val;
++ vcpu->arch.vcpu_debug_state.dbg_wvr[rd->CRm] = rd->val;
+ }
+
+ static bool trap_wcr(struct kvm_vcpu *vcpu,
+ struct sys_reg_params *p,
+ const struct sys_reg_desc *rd)
+ {
+- u64 *dbg_reg = &vcpu->arch.vcpu_debug_state.dbg_wcr[rd->reg];
++ u64 *dbg_reg = &vcpu->arch.vcpu_debug_state.dbg_wcr[rd->CRm];
+
+ if (p->is_write)
+ reg_to_dbg(vcpu, p, rd, dbg_reg);
+ else
+ dbg_to_reg(vcpu, p, rd, dbg_reg);
+
+- trace_trap_reg(__func__, rd->reg, p->is_write, *dbg_reg);
++ trace_trap_reg(__func__, rd->CRm, p->is_write, *dbg_reg);
+
+ return true;
+ }
+@@ -542,7 +542,7 @@ static bool trap_wcr(struct kvm_vcpu *vc
+ static int set_wcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
+ const struct kvm_one_reg *reg, void __user *uaddr)
+ {
+- __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_wcr[rd->reg];
++ __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_wcr[rd->CRm];
+
+ if (copy_from_user(r, uaddr, KVM_REG_SIZE(reg->id)) != 0)
+ return -EFAULT;
+@@ -552,7 +552,7 @@ static int set_wcr(struct kvm_vcpu *vcpu
+ static int get_wcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
+ const struct kvm_one_reg *reg, void __user *uaddr)
+ {
+- __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_wcr[rd->reg];
++ __u64 *r = &vcpu->arch.vcpu_debug_state.dbg_wcr[rd->CRm];
+
+ if (copy_to_user(uaddr, r, KVM_REG_SIZE(reg->id)) != 0)
+ return -EFAULT;
+@@ -562,7 +562,7 @@ static int get_wcr(struct kvm_vcpu *vcpu
+ static void reset_wcr(struct kvm_vcpu *vcpu,
+ const struct sys_reg_desc *rd)
+ {
+- vcpu->arch.vcpu_debug_state.dbg_wcr[rd->reg] = rd->val;
++ vcpu->arch.vcpu_debug_state.dbg_wcr[rd->CRm] = rd->val;
+ }
+
+ static void reset_amair_el1(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
--- /dev/null
+From f5e30680616ab09e690b153b7a68ff7dd13e6579 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Thu, 6 May 2021 14:31:42 +0100
+Subject: KVM: arm64: Move __adjust_pc out of line
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit f5e30680616ab09e690b153b7a68ff7dd13e6579 upstream.
+
+In order to make it easy to call __adjust_pc() from the EL1 code
+(in the case of nVHE), rename it to __kvm_adjust_pc() and move
+it out of line.
+
+No expected functional change.
+
+Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
+Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
+Tested-by: Zenghui Yu <yuzenghui@huawei.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Cc: stable@vger.kernel.org # 5.11
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/include/asm/kvm_asm.h | 2 ++
+ arch/arm64/kvm/hyp/exception.c | 18 +++++++++++++++++-
+ arch/arm64/kvm/hyp/include/hyp/adjust_pc.h | 18 ------------------
+ arch/arm64/kvm/hyp/nvhe/switch.c | 3 +--
+ arch/arm64/kvm/hyp/vhe/switch.c | 3 +--
+ 5 files changed, 21 insertions(+), 23 deletions(-)
+
+--- a/arch/arm64/include/asm/kvm_asm.h
++++ b/arch/arm64/include/asm/kvm_asm.h
+@@ -192,6 +192,8 @@ extern void __kvm_timer_set_cntvoff(u64
+
+ extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
+
++extern void __kvm_adjust_pc(struct kvm_vcpu *vcpu);
++
+ extern u64 __vgic_v3_get_gic_config(void);
+ extern u64 __vgic_v3_read_vmcr(void);
+ extern void __vgic_v3_write_vmcr(u32 vmcr);
+--- a/arch/arm64/kvm/hyp/exception.c
++++ b/arch/arm64/kvm/hyp/exception.c
+@@ -296,7 +296,7 @@ static void enter_exception32(struct kvm
+ *vcpu_pc(vcpu) = vect_offset;
+ }
+
+-void kvm_inject_exception(struct kvm_vcpu *vcpu)
++static void kvm_inject_exception(struct kvm_vcpu *vcpu)
+ {
+ if (vcpu_el1_is_32bit(vcpu)) {
+ switch (vcpu->arch.flags & KVM_ARM64_EXCEPT_MASK) {
+@@ -329,3 +329,19 @@ void kvm_inject_exception(struct kvm_vcp
+ }
+ }
+ }
++
++/*
++ * Adjust the guest PC on entry, depending on flags provided by EL1
++ * for the purpose of emulation (MMIO, sysreg) or exception injection.
++ */
++void __kvm_adjust_pc(struct kvm_vcpu *vcpu)
++{
++ if (vcpu->arch.flags & KVM_ARM64_PENDING_EXCEPTION) {
++ kvm_inject_exception(vcpu);
++ vcpu->arch.flags &= ~(KVM_ARM64_PENDING_EXCEPTION |
++ KVM_ARM64_EXCEPT_MASK);
++ } else if (vcpu->arch.flags & KVM_ARM64_INCREMENT_PC) {
++ kvm_skip_instr(vcpu);
++ vcpu->arch.flags &= ~KVM_ARM64_INCREMENT_PC;
++ }
++}
+--- a/arch/arm64/kvm/hyp/include/hyp/adjust_pc.h
++++ b/arch/arm64/kvm/hyp/include/hyp/adjust_pc.h
+@@ -13,8 +13,6 @@
+ #include <asm/kvm_emulate.h>
+ #include <asm/kvm_host.h>
+
+-void kvm_inject_exception(struct kvm_vcpu *vcpu);
+-
+ static inline void kvm_skip_instr(struct kvm_vcpu *vcpu)
+ {
+ if (vcpu_mode_is_32bit(vcpu)) {
+@@ -44,22 +42,6 @@ static inline void __kvm_skip_instr(stru
+ }
+
+ /*
+- * Adjust the guest PC on entry, depending on flags provided by EL1
+- * for the purpose of emulation (MMIO, sysreg) or exception injection.
+- */
+-static inline void __adjust_pc(struct kvm_vcpu *vcpu)
+-{
+- if (vcpu->arch.flags & KVM_ARM64_PENDING_EXCEPTION) {
+- kvm_inject_exception(vcpu);
+- vcpu->arch.flags &= ~(KVM_ARM64_PENDING_EXCEPTION |
+- KVM_ARM64_EXCEPT_MASK);
+- } else if (vcpu->arch.flags & KVM_ARM64_INCREMENT_PC) {
+- kvm_skip_instr(vcpu);
+- vcpu->arch.flags &= ~KVM_ARM64_INCREMENT_PC;
+- }
+-}
+-
+-/*
+ * Skip an instruction while host sysregs are live.
+ * Assumes host is always 64-bit.
+ */
+--- a/arch/arm64/kvm/hyp/nvhe/switch.c
++++ b/arch/arm64/kvm/hyp/nvhe/switch.c
+@@ -4,7 +4,6 @@
+ * Author: Marc Zyngier <marc.zyngier@arm.com>
+ */
+
+-#include <hyp/adjust_pc.h>
+ #include <hyp/switch.h>
+ #include <hyp/sysreg-sr.h>
+
+@@ -201,7 +200,7 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu
+ */
+ __debug_save_host_buffers_nvhe(vcpu);
+
+- __adjust_pc(vcpu);
++ __kvm_adjust_pc(vcpu);
+
+ /*
+ * We must restore the 32-bit state before the sysregs, thanks
+--- a/arch/arm64/kvm/hyp/vhe/switch.c
++++ b/arch/arm64/kvm/hyp/vhe/switch.c
+@@ -4,7 +4,6 @@
+ * Author: Marc Zyngier <marc.zyngier@arm.com>
+ */
+
+-#include <hyp/adjust_pc.h>
+ #include <hyp/switch.h>
+
+ #include <linux/arm-smccc.h>
+@@ -134,7 +133,7 @@ static int __kvm_vcpu_run_vhe(struct kvm
+ __load_guest_stage2(vcpu->arch.hw_mmu);
+ __activate_traps(vcpu);
+
+- __adjust_pc(vcpu);
++ __kvm_adjust_pc(vcpu);
+
+ sysreg_restore_guest_state_vhe(guest_ctxt);
+ __debug_switch_to_guest(vcpu);
--- /dev/null
+From 66e94d5cafd4decd4f92d16a022ea587d7f4094f Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Mon, 24 May 2021 18:07:52 +0100
+Subject: KVM: arm64: Prevent mixed-width VM creation
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit 66e94d5cafd4decd4f92d16a022ea587d7f4094f upstream.
+
+It looks like we have tolerated creating mixed-width VMs since...
+forever. However, that was never the intention, and we'd rather
+not have to support that pointless complexity.
+
+Forbid such a setup by making sure all the vcpus have the same
+register width.
+
+Reported-by: Steven Price <steven.price@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Cc: stable@vger.kernel.org
+Acked-by: Mark Rutland <mark.rutland@arm.com>
+Link: https://lore.kernel.org/r/20210524170752.1549797-1-maz@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/include/asm/kvm_emulate.h | 5 +++++
+ arch/arm64/kvm/reset.c | 28 ++++++++++++++++++++++++----
+ 2 files changed, 29 insertions(+), 4 deletions(-)
+
+--- a/arch/arm64/include/asm/kvm_emulate.h
++++ b/arch/arm64/include/asm/kvm_emulate.h
+@@ -463,4 +463,9 @@ static __always_inline void kvm_incr_pc(
+ vcpu->arch.flags |= KVM_ARM64_INCREMENT_PC;
+ }
+
++static inline bool vcpu_has_feature(struct kvm_vcpu *vcpu, int feature)
++{
++ return test_bit(feature, vcpu->arch.features);
++}
++
+ #endif /* __ARM64_KVM_EMULATE_H__ */
+--- a/arch/arm64/kvm/reset.c
++++ b/arch/arm64/kvm/reset.c
+@@ -170,6 +170,25 @@ static int kvm_vcpu_enable_ptrauth(struc
+ return 0;
+ }
+
++static bool vcpu_allowed_register_width(struct kvm_vcpu *vcpu)
++{
++ struct kvm_vcpu *tmp;
++ bool is32bit;
++ int i;
++
++ is32bit = vcpu_has_feature(vcpu, KVM_ARM_VCPU_EL1_32BIT);
++ if (!cpus_have_const_cap(ARM64_HAS_32BIT_EL1) && is32bit)
++ return false;
++
++ /* Check that the vcpus are either all 32bit or all 64bit */
++ kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
++ if (vcpu_has_feature(tmp, KVM_ARM_VCPU_EL1_32BIT) != is32bit)
++ return false;
++ }
++
++ return true;
++}
++
+ /**
+ * kvm_reset_vcpu - sets core registers and sys_regs to reset value
+ * @vcpu: The VCPU pointer
+@@ -221,13 +240,14 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu
+ }
+ }
+
++ if (!vcpu_allowed_register_width(vcpu)) {
++ ret = -EINVAL;
++ goto out;
++ }
++
+ switch (vcpu->arch.target) {
+ default:
+ if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features)) {
+- if (!cpus_have_const_cap(ARM64_HAS_32BIT_EL1)) {
+- ret = -EINVAL;
+- goto out;
+- }
+ pstate = VCPU_RESET_PSTATE_SVC;
+ } else {
+ pstate = VCPU_RESET_PSTATE_EL1;
--- /dev/null
+From e3e880bb1518eb10a4b4bb4344ed614d6856f190 Mon Sep 17 00:00:00 2001
+From: Zenghui Yu <yuzenghui@huawei.com>
+Date: Wed, 26 May 2021 22:18:31 +0800
+Subject: KVM: arm64: Resolve all pending PC updates before immediate exit
+
+From: Zenghui Yu <yuzenghui@huawei.com>
+
+commit e3e880bb1518eb10a4b4bb4344ed614d6856f190 upstream.
+
+Commit 26778aaa134a ("KVM: arm64: Commit pending PC adjustemnts before
+returning to userspace") fixed the PC updating issue by forcing an explicit
+synchronisation of the exception state on vcpu exit to userspace.
+
+However, we forgot to take into account the case where immediate_exit is
+set by userspace and KVM_RUN will exit immediately. Fix it by resolving all
+pending PC updates before returning to userspace.
+
+Since __kvm_adjust_pc() relies on a loaded vcpu context, I moved the
+immediate_exit checking right after vcpu_load(). We will get some overhead
+if immediate_exit is true (which should hopefully be rare).
+
+Fixes: 26778aaa134a ("KVM: arm64: Commit pending PC adjustemnts before returning to userspace")
+Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20210526141831.1662-1-yuzenghui@huawei.com
+Cc: stable@vger.kernel.org # 5.11
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kvm/arm.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/arch/arm64/kvm/arm.c
++++ b/arch/arm64/kvm/arm.c
+@@ -715,11 +715,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
+ return ret;
+ }
+
+- if (run->immediate_exit)
+- return -EINTR;
+-
+ vcpu_load(vcpu);
+
++ if (run->immediate_exit) {
++ ret = -EINTR;
++ goto out;
++ }
++
+ kvm_sigset_activate(vcpu);
+
+ ret = 1;
+@@ -913,6 +915,7 @@ static int vcpu_interrupt_line(struct kv
+ else
+ set = test_and_clear_bit(bit_index, hcr);
+
++out:
+ /*
+ * If we didn't change anything, no need to wake up or kick other CPUs
+ */
--- /dev/null
+From 1eff0ada88b48e4ac1e3fe26483b3684fedecd27 Mon Sep 17 00:00:00 2001
+From: Wanpeng Li <wanpengli@tencent.com>
+Date: Tue, 18 May 2021 05:00:33 -0700
+Subject: KVM: X86: Fix vCPU preempted state from guest's point of view
+
+From: Wanpeng Li <wanpengli@tencent.com>
+
+commit 1eff0ada88b48e4ac1e3fe26483b3684fedecd27 upstream.
+
+Commit 66570e966dd9 (kvm: x86: only provide PV features if enabled in guest's
+CPUID) avoids to access pv tlb shootdown host side logic when this pv feature
+is not exposed to guest, however, kvm_steal_time.preempted not only leveraged
+by pv tlb shootdown logic but also mitigate the lock holder preemption issue.
+From guest's point of view, vCPU is always preempted since we lose the reset
+of kvm_steal_time.preempted before vmentry if pv tlb shootdown feature is not
+exposed. This patch fixes it by clearing kvm_steal_time.preempted before
+vmentry.
+
+Fixes: 66570e966dd9 (kvm: x86: only provide PV features if enabled in guest's CPUID)
+Reviewed-by: Sean Christopherson <seanjc@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
+Message-Id: <1621339235-11131-3-git-send-email-wanpengli@tencent.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/x86.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -3015,6 +3015,8 @@ static void record_steal_time(struct kvm
+ st->preempted & KVM_VCPU_FLUSH_TLB);
+ if (xchg(&st->preempted, 0) & KVM_VCPU_FLUSH_TLB)
+ kvm_vcpu_flush_tlb_guest(vcpu);
++ } else {
++ st->preempted = 0;
+ }
+
+ vcpu->arch.st.preempted = 0;
--- /dev/null
+From bbf0a94744edfeee298e4a9ab6fd694d639a5cdf Mon Sep 17 00:00:00 2001
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+Date: Wed, 26 May 2021 22:33:34 +0300
+Subject: mei: request autosuspend after sending rx flow control
+
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+
+commit bbf0a94744edfeee298e4a9ab6fd694d639a5cdf upstream.
+
+A rx flow control waiting in the control queue may block autosuspend.
+Re-request autosuspend after flow control been sent to unblock
+the transition to the low power state.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
+Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
+Link: https://lore.kernel.org/r/20210526193334.445759-1-tomas.winkler@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/mei/interrupt.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/misc/mei/interrupt.c
++++ b/drivers/misc/mei/interrupt.c
+@@ -277,6 +277,9 @@ static int mei_cl_irq_read(struct mei_cl
+ return ret;
+ }
+
++ pm_runtime_mark_last_busy(dev->dev);
++ pm_request_autosuspend(dev->dev);
++
+ list_move_tail(&cb->list, &cl->rd_pending);
+
+ return 0;
--- /dev/null
+From dcb4b8ad6a448532d8b681b5d1a7036210b622de Mon Sep 17 00:00:00 2001
+From: Dongliang Mu <mudongliangabcd@gmail.com>
+Date: Fri, 14 May 2021 20:43:48 +0800
+Subject: misc/uss720: fix memory leak in uss720_probe
+
+From: Dongliang Mu <mudongliangabcd@gmail.com>
+
+commit dcb4b8ad6a448532d8b681b5d1a7036210b622de upstream.
+
+uss720_probe forgets to decrease the refcount of usbdev in uss720_probe.
+Fix this by decreasing the refcount of usbdev by usb_put_dev.
+
+BUG: memory leak
+unreferenced object 0xffff888101113800 (size 2048):
+ comm "kworker/0:1", pid 7, jiffies 4294956777 (age 28.870s)
+ hex dump (first 32 bytes):
+ ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00 ....1...........
+ 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 ................
+ backtrace:
+ [<ffffffff82b8e822>] kmalloc include/linux/slab.h:554 [inline]
+ [<ffffffff82b8e822>] kzalloc include/linux/slab.h:684 [inline]
+ [<ffffffff82b8e822>] usb_alloc_dev+0x32/0x450 drivers/usb/core/usb.c:582
+ [<ffffffff82b98441>] hub_port_connect drivers/usb/core/hub.c:5129 [inline]
+ [<ffffffff82b98441>] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline]
+ [<ffffffff82b98441>] port_event drivers/usb/core/hub.c:5509 [inline]
+ [<ffffffff82b98441>] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591
+ [<ffffffff81259229>] process_one_work+0x2c9/0x600 kernel/workqueue.c:2275
+ [<ffffffff81259b19>] worker_thread+0x59/0x5d0 kernel/workqueue.c:2421
+ [<ffffffff81261228>] kthread+0x178/0x1b0 kernel/kthread.c:292
+ [<ffffffff8100227f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
+
+Fixes: 0f36163d3abe ("[PATCH] usb: fix uss720 schedule with interrupts off")
+Cc: stable <stable@vger.kernel.org>
+Reported-by: syzbot+636c58f40a86b4a879e7@syzkaller.appspotmail.com
+Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
+Link: https://lore.kernel.org/r/20210514124348.6587-1-mudongliangabcd@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/misc/uss720.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/misc/uss720.c
++++ b/drivers/usb/misc/uss720.c
+@@ -736,6 +736,7 @@ static int uss720_probe(struct usb_inter
+ parport_announce_port(pp);
+
+ usb_set_intfdata(intf, pp);
++ usb_put_dev(usbdev);
+ return 0;
+
+ probe_abort:
--- /dev/null
+From e44b49f623c77bee7451f1a82ccfb969c1028ae2 Mon Sep 17 00:00:00 2001
+From: Zhu Lingshan <lingshan.zhu@intel.com>
+Date: Sat, 8 May 2021 15:11:52 +0800
+Subject: Revert "irqbypass: do not start cons/prod when failed connect"
+
+From: Zhu Lingshan <lingshan.zhu@intel.com>
+
+commit e44b49f623c77bee7451f1a82ccfb969c1028ae2 upstream.
+
+This reverts commit a979a6aa009f3c99689432e0cdb5402a4463fb88.
+
+The reverted commit may cause VM freeze on arm64 with GICv4,
+where stopping a consumer is implemented by suspending the VM.
+Should the connect fail, the VM will not be resumed, which
+is a bit of a problem.
+
+It also erroneously calls the producer destructor unconditionally,
+which is unexpected.
+
+Reported-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
+Suggested-by: Marc Zyngier <maz@kernel.org>
+Acked-by: Jason Wang <jasowang@redhat.com>
+Acked-by: Michael S. Tsirkin <mst@redhat.com>
+Reviewed-by: Eric Auger <eric.auger@redhat.com>
+Tested-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
+Signed-off-by: Zhu Lingshan <lingshan.zhu@intel.com>
+[maz: tags and cc-stable, commit message update]
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Fixes: a979a6aa009f ("irqbypass: do not start cons/prod when failed connect")
+Link: https://lore.kernel.org/r/3a2c66d6-6ca0-8478-d24b-61e8e3241b20@hisilicon.com
+Link: https://lore.kernel.org/r/20210508071152.722425-1-lingshan.zhu@intel.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ virt/lib/irqbypass.c | 16 ++++++----------
+ 1 file changed, 6 insertions(+), 10 deletions(-)
+
+--- a/virt/lib/irqbypass.c
++++ b/virt/lib/irqbypass.c
+@@ -40,21 +40,17 @@ static int __connect(struct irq_bypass_p
+ if (prod->add_consumer)
+ ret = prod->add_consumer(prod, cons);
+
+- if (ret)
+- goto err_add_consumer;
+-
+- ret = cons->add_producer(cons, prod);
+- if (ret)
+- goto err_add_producer;
++ if (!ret) {
++ ret = cons->add_producer(cons, prod);
++ if (ret && prod->del_consumer)
++ prod->del_consumer(prod, cons);
++ }
+
+ if (cons->start)
+ cons->start(cons);
+ if (prod->start)
+ prod->start(prod);
+-err_add_producer:
+- if (prod->del_consumer)
+- prod->del_consumer(prod, cons);
+-err_add_consumer:
++
+ return ret;
+ }
+
--- /dev/null
+From eac2f3059e02382d91f8c887462083841d6ea2a3 Mon Sep 17 00:00:00 2001
+From: Chen Huang <chenhuang5@huawei.com>
+Date: Thu, 29 Apr 2021 07:03:48 +0000
+Subject: riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled
+
+From: Chen Huang <chenhuang5@huawei.com>
+
+commit eac2f3059e02382d91f8c887462083841d6ea2a3 upstream.
+
+As [1] and [2] said, the arch_stack_walk should not to trace itself, or it will
+leave the trace unexpectedly when called. The example is when we do "cat
+/sys/kernel/debug/page_owner", all pages' stack is the same.
+
+arch_stack_walk+0x18/0x20
+stack_trace_save+0x40/0x60
+register_dummy_stack+0x24/0x5e
+init_page_owner+0x2e
+
+So we use __builtin_frame_address(1) as the first frame to be walked. And mark
+the arch_stack_walk() noinline.
+
+We found that pr_cont will affact pages' stack whose task state is RUNNING when
+testing "echo t > /proc/sysrq-trigger". So move the place of pr_cont and mark
+the function dump_backtrace() noinline.
+
+Also we move the case when task == NULL into else branch, and test for it in
+"echo c > /proc/sysrq-trigger".
+
+[1] https://lore.kernel.org/lkml/20210319184106.5688-1-mark.rutland@arm.com/
+[2] https://lore.kernel.org/lkml/20210317142050.57712-1-chenjun102@huawei.com/
+
+Signed-off-by: Chen Huang <chenhuang5@huawei.com>
+Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
+Cc: stable@vger.kernel.org
+Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/kernel/stacktrace.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/arch/riscv/kernel/stacktrace.c
++++ b/arch/riscv/kernel/stacktrace.c
+@@ -27,10 +27,10 @@ void notrace walk_stackframe(struct task
+ fp = frame_pointer(regs);
+ sp = user_stack_pointer(regs);
+ pc = instruction_pointer(regs);
+- } else if (task == NULL || task == current) {
+- fp = (unsigned long)__builtin_frame_address(0);
+- sp = sp_in_global;
+- pc = (unsigned long)walk_stackframe;
++ } else if (task == current) {
++ fp = (unsigned long)__builtin_frame_address(1);
++ sp = (unsigned long)__builtin_frame_address(0);
++ pc = (unsigned long)__builtin_return_address(0);
+ } else {
+ /* task blocked in __switch_to */
+ fp = task->thread.s[0];
+@@ -106,15 +106,15 @@ static bool print_trace_address(void *ar
+ return true;
+ }
+
+-void dump_backtrace(struct pt_regs *regs, struct task_struct *task,
++noinline void dump_backtrace(struct pt_regs *regs, struct task_struct *task,
+ const char *loglvl)
+ {
+- pr_cont("%sCall Trace:\n", loglvl);
+ walk_stackframe(task, regs, print_trace_address, (void *)loglvl);
+ }
+
+ void show_stack(struct task_struct *task, unsigned long *sp, const char *loglvl)
+ {
++ pr_cont("%sCall Trace:\n", loglvl);
+ dump_backtrace(NULL, task, loglvl);
+ }
+
+@@ -139,7 +139,7 @@ unsigned long get_wchan(struct task_stru
+
+ #ifdef CONFIG_STACKTRACE
+
+-void arch_stack_walk(stack_trace_consume_fn consume_entry, void *cookie,
++noinline void arch_stack_walk(stack_trace_consume_fn consume_entry, void *cookie,
+ struct task_struct *task, struct pt_regs *regs)
+ {
+ walk_stackframe(task, regs, consume_entry, cookie);
--- /dev/null
+From ddc473916955f7710d1eb17c1273d91c8622a9fe Mon Sep 17 00:00:00 2001
+From: Sargun Dhillon <sargun@sargun.me>
+Date: Mon, 17 May 2021 12:39:06 -0700
+Subject: seccomp: Refactor notification handler to prepare for new semantics
+
+From: Sargun Dhillon <sargun@sargun.me>
+
+commit ddc473916955f7710d1eb17c1273d91c8622a9fe upstream.
+
+This refactors the user notification code to have a do / while loop around
+the completion condition. This has a small change in semantic, in that
+previously we ignored addfd calls upon wakeup if the notification had been
+responded to, but instead with the new change we check for an outstanding
+addfd calls prior to returning to userspace.
+
+Rodrigo Campos also identified a bug that can result in addfd causing
+an early return, when the supervisor didn't actually handle the
+syscall [1].
+
+[1]: https://lore.kernel.org/lkml/20210413160151.3301-1-rodrigo@kinvolk.io/
+
+Fixes: 7cf97b125455 ("seccomp: Introduce addfd ioctl to seccomp user notifier")
+Signed-off-by: Sargun Dhillon <sargun@sargun.me>
+Acked-by: Tycho Andersen <tycho@tycho.pizza>
+Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Tested-by: Rodrigo Campos <rodrigo@kinvolk.io>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210517193908.3113-3-sargun@sargun.me
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/seccomp.c | 30 ++++++++++++++++--------------
+ 1 file changed, 16 insertions(+), 14 deletions(-)
+
+--- a/kernel/seccomp.c
++++ b/kernel/seccomp.c
+@@ -1098,28 +1098,30 @@ static int seccomp_do_user_notification(
+
+ up(&match->notif->request);
+ wake_up_poll(&match->wqh, EPOLLIN | EPOLLRDNORM);
+- mutex_unlock(&match->notify_lock);
+
+ /*
+ * This is where we wait for a reply from userspace.
+ */
+-wait:
+- err = wait_for_completion_interruptible(&n.ready);
+- mutex_lock(&match->notify_lock);
+- if (err == 0) {
+- /* Check if we were woken up by a addfd message */
++ do {
++ mutex_unlock(&match->notify_lock);
++ err = wait_for_completion_interruptible(&n.ready);
++ mutex_lock(&match->notify_lock);
++ if (err != 0)
++ goto interrupted;
++
+ addfd = list_first_entry_or_null(&n.addfd,
+ struct seccomp_kaddfd, list);
+- if (addfd && n.state != SECCOMP_NOTIFY_REPLIED) {
++ /* Check if we were woken up by a addfd message */
++ if (addfd)
+ seccomp_handle_addfd(addfd);
+- mutex_unlock(&match->notify_lock);
+- goto wait;
+- }
+- ret = n.val;
+- err = n.error;
+- flags = n.flags;
+- }
+
++ } while (n.state != SECCOMP_NOTIFY_REPLIED);
++
++ ret = n.val;
++ err = n.error;
++ flags = n.flags;
++
++interrupted:
+ /* If there were any pending addfd calls, clear them out */
+ list_for_each_entry_safe(addfd, tmp, &n.addfd, list) {
+ /* The process went away before we got a chance to handle it */
--- /dev/null
+From df8f2be2fd0b44b2cb6077068f52e05f0ac40897 Mon Sep 17 00:00:00 2001
+From: Andrew Jeffery <andrew@aj.id.au>
+Date: Thu, 20 May 2021 11:43:33 +0930
+Subject: serial: 8250: Add UART_BUG_TXRACE workaround for Aspeed VUART
+
+From: Andrew Jeffery <andrew@aj.id.au>
+
+commit df8f2be2fd0b44b2cb6077068f52e05f0ac40897 upstream.
+
+Aspeed Virtual UARTs directly bridge e.g. the system console UART on the
+LPC bus to the UART interface on the BMC's internal APB. As such there's
+no RS-232 signalling involved - the UART interfaces on each bus are
+directly connected as the producers and consumers of the one set of
+FIFOs.
+
+The APB in the AST2600 generally runs at 100MHz while the LPC bus peaks
+at 33MHz. The difference in clock speeds exposes a race in the VUART
+design where a Tx data burst on the APB interface can result in a byte
+lost on the LPC interface. The symptom is LSR[DR] remains clear on the
+LPC interface despite data being present in its Rx FIFO, while LSR[THRE]
+remains clear on the APB interface as the host has not consumed the data
+the BMC has transmitted. In this state, the UART has stalled and no
+further data can be transmitted without manual intervention (e.g.
+resetting the FIFOs, resulting in loss of data).
+
+The recommended work-around is to insert a read cycle on the APB
+interface between writes to THR.
+
+Cc: ChiaWei Wang <chiawei_wang@aspeedtech.com>
+Tested-by: ChiaWei Wang <chiawei_wang@aspeedtech.com>
+Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
+Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210520021334.497341-2-andrew@aj.id.au
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250.h | 1 +
+ drivers/tty/serial/8250/8250_aspeed_vuart.c | 1 +
+ drivers/tty/serial/8250/8250_port.c | 12 ++++++++++++
+ 3 files changed, 14 insertions(+)
+
+--- a/drivers/tty/serial/8250/8250.h
++++ b/drivers/tty/serial/8250/8250.h
+@@ -88,6 +88,7 @@ struct serial8250_config {
+ #define UART_BUG_NOMSR (1 << 2) /* UART has buggy MSR status bits (Au1x00) */
+ #define UART_BUG_THRE (1 << 3) /* UART has buggy THRE reassertion */
+ #define UART_BUG_PARITY (1 << 4) /* UART mishandles parity if FIFO enabled */
++#define UART_BUG_TXRACE (1 << 5) /* UART Tx fails to set remote DR */
+
+
+ #ifdef CONFIG_SERIAL_8250_SHARE_IRQ
+--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
++++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
+@@ -403,6 +403,7 @@ static int aspeed_vuart_probe(struct pla
+ port.port.status = UPSTAT_SYNC_FIFO;
+ port.port.dev = &pdev->dev;
+ port.port.has_sysrq = IS_ENABLED(CONFIG_SERIAL_8250_CONSOLE);
++ port.bugs |= UART_BUG_TXRACE;
+
+ rc = sysfs_create_group(&vuart->dev->kobj, &aspeed_vuart_attr_group);
+ if (rc < 0)
+--- a/drivers/tty/serial/8250/8250_port.c
++++ b/drivers/tty/serial/8250/8250_port.c
+@@ -1815,6 +1815,18 @@ void serial8250_tx_chars(struct uart_825
+ count = up->tx_loadsz;
+ do {
+ serial_out(up, UART_TX, xmit->buf[xmit->tail]);
++ if (up->bugs & UART_BUG_TXRACE) {
++ /*
++ * The Aspeed BMC virtual UARTs have a bug where data
++ * may get stuck in the BMC's Tx FIFO from bursts of
++ * writes on the APB interface.
++ *
++ * Delay back-to-back writes by a read cycle to avoid
++ * stalling the VUART. Read a register that won't have
++ * side-effects and discard the result.
++ */
++ serial_in(up, UART_SCR);
++ }
+ xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+ port->icount.tx++;
+ if (uart_circ_empty(xmit))
--- /dev/null
+From 3c35d2a960c0077a4cb09bf4989f45d289332ea0 Mon Sep 17 00:00:00 2001
+From: Maximilian Luz <luzmaximilian@gmail.com>
+Date: Wed, 12 May 2021 23:04:13 +0200
+Subject: serial: 8250_dw: Add device HID for new AMD UART controller
+
+From: Maximilian Luz <luzmaximilian@gmail.com>
+
+commit 3c35d2a960c0077a4cb09bf4989f45d289332ea0 upstream.
+
+Add device HID AMDI0022 to the AMD UART controller driver match table
+and create a platform device for it. This controller can be found on
+Microsoft Surface Laptop 4 devices and seems similar enough that we can
+just copy the existing AMDI0020 entries.
+
+Cc: <stable@vger.kernel.org> # 5.10+
+Tested-by: Sachi King <nakato@nakato.io>
+Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # for 8250_dw part
+Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
+Link: https://lore.kernel.org/r/20210512210413.1982933-1-luzmaximilian@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/acpi_apd.c | 1 +
+ drivers/tty/serial/8250/8250_dw.c | 1 +
+ 2 files changed, 2 insertions(+)
+
+--- a/drivers/acpi/acpi_apd.c
++++ b/drivers/acpi/acpi_apd.c
+@@ -226,6 +226,7 @@ static const struct acpi_device_id acpi_
+ { "AMDI0010", APD_ADDR(wt_i2c_desc) },
+ { "AMD0020", APD_ADDR(cz_uart_desc) },
+ { "AMDI0020", APD_ADDR(cz_uart_desc) },
++ { "AMDI0022", APD_ADDR(cz_uart_desc) },
+ { "AMD0030", },
+ { "AMD0040", APD_ADDR(fch_misc_desc)},
+ { "HYGO0010", APD_ADDR(wt_i2c_desc) },
+--- a/drivers/tty/serial/8250/8250_dw.c
++++ b/drivers/tty/serial/8250/8250_dw.c
+@@ -714,6 +714,7 @@ static const struct acpi_device_id dw825
+ { "APMC0D08", 0},
+ { "AMD0020", 0 },
+ { "AMDI0020", 0 },
++ { "AMDI0022", 0 },
+ { "BRCM2032", 0 },
+ { "HISI0031", 0 },
+ { },
--- /dev/null
+From e0e24208792080135248f23fdf6d51aa2e04df05 Mon Sep 17 00:00:00 2001
+From: Randy Wright <rwright@hpe.com>
+Date: Fri, 14 May 2021 10:26:54 -0600
+Subject: serial: 8250_pci: Add support for new HPE serial device
+
+From: Randy Wright <rwright@hpe.com>
+
+commit e0e24208792080135248f23fdf6d51aa2e04df05 upstream.
+
+Add support for new HPE serial device. It is MSI enabled,
+but otherwise similar to legacy HP server serial devices.
+
+Tested-by: Jerry Hoemann <jerry.hoemann@hpe.com>
+Signed-off-by: Randy Wright <rwright@hpe.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/1621009614-28836-1-git-send-email-rwright@hpe.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250_pci.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+--- a/drivers/tty/serial/8250/8250_pci.c
++++ b/drivers/tty/serial/8250/8250_pci.c
+@@ -56,6 +56,8 @@ struct serial_private {
+ int line[];
+ };
+
++#define PCI_DEVICE_ID_HPE_PCI_SERIAL 0x37e
++
+ static const struct pci_device_id pci_use_msi[] = {
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9900,
+ 0xA000, 0x1000) },
+@@ -63,6 +65,8 @@ static const struct pci_device_id pci_us
+ 0xA000, 0x1000) },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9922,
+ 0xA000, 0x1000) },
++ { PCI_DEVICE_SUB(PCI_VENDOR_ID_HP_3PAR, PCI_DEVICE_ID_HPE_PCI_SERIAL,
++ PCI_ANY_ID, PCI_ANY_ID) },
+ { }
+ };
+
+@@ -1998,6 +2002,16 @@ static struct pci_serial_quirk pci_seria
+ .setup = pci_hp_diva_setup,
+ },
+ /*
++ * HPE PCI serial device
++ */
++ {
++ .vendor = PCI_VENDOR_ID_HP_3PAR,
++ .device = PCI_DEVICE_ID_HPE_PCI_SERIAL,
++ .subvendor = PCI_ANY_ID,
++ .subdevice = PCI_ANY_ID,
++ .setup = pci_hp_diva_setup,
++ },
++ /*
+ * Intel
+ */
+ {
+@@ -4973,6 +4987,10 @@ static const struct pci_device_id serial
+ { PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_DIVA_AUX,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ pbn_b2_1_115200 },
++ /* HPE PCI serial device */
++ { PCI_VENDOR_ID_HP_3PAR, PCI_DEVICE_ID_HPE_PCI_SERIAL,
++ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
++ pbn_b1_1_115200 },
+
+ { PCI_VENDOR_ID_DCI, PCI_DEVICE_ID_DCI_PCCOM2,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
--- /dev/null
+From 9808f9be31c68af43f6e531f2c851ebb066513fe Mon Sep 17 00:00:00 2001
+From: Christian Gmeiner <christian.gmeiner@gmail.com>
+Date: Thu, 27 May 2021 11:54:40 +0200
+Subject: serial: 8250_pci: handle FL_NOIRQ board flag
+
+From: Christian Gmeiner <christian.gmeiner@gmail.com>
+
+commit 9808f9be31c68af43f6e531f2c851ebb066513fe upstream.
+
+In commit 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support")
+the way the irq gets allocated was changed. With that change the
+handling FL_NOIRQ got lost. Restore the old behaviour.
+
+Fixes: 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
+Link: https://lore.kernel.org/r/20210527095529.26281-1-christian.gmeiner@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250_pci.c | 29 +++++++++++++++++------------
+ 1 file changed, 17 insertions(+), 12 deletions(-)
+
+--- a/drivers/tty/serial/8250/8250_pci.c
++++ b/drivers/tty/serial/8250/8250_pci.c
+@@ -3958,21 +3958,26 @@ pciserial_init_ports(struct pci_dev *dev
+ uart.port.flags = UPF_SKIP_TEST | UPF_BOOT_AUTOCONF | UPF_SHARE_IRQ;
+ uart.port.uartclk = board->base_baud * 16;
+
+- if (pci_match_id(pci_use_msi, dev)) {
+- dev_dbg(&dev->dev, "Using MSI(-X) interrupts\n");
+- pci_set_master(dev);
+- rc = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_ALL_TYPES);
++ if (board->flags & FL_NOIRQ) {
++ uart.port.irq = 0;
+ } else {
+- dev_dbg(&dev->dev, "Using legacy interrupts\n");
+- rc = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_LEGACY);
+- }
+- if (rc < 0) {
+- kfree(priv);
+- priv = ERR_PTR(rc);
+- goto err_deinit;
++ if (pci_match_id(pci_use_msi, dev)) {
++ dev_dbg(&dev->dev, "Using MSI(-X) interrupts\n");
++ pci_set_master(dev);
++ rc = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_ALL_TYPES);
++ } else {
++ dev_dbg(&dev->dev, "Using legacy interrupts\n");
++ rc = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_LEGACY);
++ }
++ if (rc < 0) {
++ kfree(priv);
++ priv = ERR_PTR(rc);
++ goto err_deinit;
++ }
++
++ uart.port.irq = pci_irq_vector(dev, 0);
+ }
+
+- uart.port.irq = pci_irq_vector(dev, 0);
+ uart.port.dev = &dev->dev;
+
+ for (i = 0; i < nr_ports; i++) {
--- /dev/null
+From 5e722b217ad3cf41f5504db80a68062df82b5242 Mon Sep 17 00:00:00 2001
+From: Ondrej Mosnacek <omosnace@redhat.com>
+Date: Fri, 7 May 2021 13:57:19 +0200
+Subject: serial: core: fix suspicious security_locked_down() call
+
+From: Ondrej Mosnacek <omosnace@redhat.com>
+
+commit 5e722b217ad3cf41f5504db80a68062df82b5242 upstream.
+
+The commit that added this check did so in a very strange way - first
+security_locked_down() is called, its value stored into retval, and if
+it's nonzero, then an additional check is made for (change_irq ||
+change_port), and if this is true, the function returns. However, if
+the goto exit branch is not taken, the code keeps the retval value and
+continues executing the function. Then, depending on whether
+uport->ops->verify_port is set, the retval value may or may not be reset
+to zero and eventually the error value from security_locked_down() may
+abort the function a few lines below.
+
+I will go out on a limb and assume that this isn't the intended behavior
+and that an error value from security_locked_down() was supposed to
+abort the function only in case (change_irq || change_port) is true.
+
+Note that security_locked_down() should be called last in any series of
+checks, since the SELinux implementation of this hook will do a check
+against the policy and generate an audit record in case of denial. If
+the operation was to carry on after calling security_locked_down(), then
+the SELinux denial record would be bogus.
+
+See commit 59438b46471a ("security,lockdown,selinux: implement SELinux
+lockdown") for how SELinux implements this hook.
+
+Fixes: 794edf30ee6c ("lockdown: Lock down TIOCSSERIAL")
+Acked-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210507115719.140799-1-omosnace@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/serial_core.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/drivers/tty/serial/serial_core.c
++++ b/drivers/tty/serial/serial_core.c
+@@ -865,9 +865,11 @@ static int uart_set_info(struct tty_stru
+ goto check_and_exit;
+ }
+
+- retval = security_locked_down(LOCKDOWN_TIOCSSERIAL);
+- if (retval && (change_irq || change_port))
+- goto exit;
++ if (change_irq || change_port) {
++ retval = security_locked_down(LOCKDOWN_TIOCSSERIAL);
++ if (retval)
++ goto exit;
++ }
+
+ /*
+ * Ask the low level driver to verify the settings.
drm-amdgpu-vcn2.5-add-cancel_delayed_work_sync-before-power-gate.patch
drm-amdgpu-jpeg2.0-add-cancel_delayed_work_sync-before-power-gate.patch
kgdb-fix-gcc-11-warnings-harder.patch
+documentation-seccomp-fix-user-notification-documentation.patch
+riscv-stacktrace-fix-the-riscv-stacktrace-when-config_frame_pointer-enabled.patch
+seccomp-refactor-notification-handler-to-prepare-for-new-semantics.patch
+debugfs-fix-security_locked_down-call-for-selinux.patch
+serial-core-fix-suspicious-security_locked_down-call.patch
+misc-uss720-fix-memory-leak-in-uss720_probe.patch
+thunderbolt-usb4-fix-nvm-read-buffer-bounds-and-offset-issue.patch
+thunderbolt-dma_port-fix-nvm-read-buffer-bounds-and-offset-issue.patch
+kvm-x86-fix-vcpu-preempted-state-from-guest-s-point-of-view.patch
+kvm-arm64-move-__adjust_pc-out-of-line.patch
+kvm-arm64-fix-debug-register-indexing.patch
+kvm-arm64-prevent-mixed-width-vm-creation.patch
+kvm-arm64-resolve-all-pending-pc-updates-before-immediate-exit.patch
+mei-request-autosuspend-after-sending-rx-flow-control.patch
+staging-iio-cdc-ad7746-avoid-overwrite-of-num_channels.patch
+iio-gyro-fxas21002c-balance-runtime-power-in-error-path.patch
+iio-dac-ad5770r-put-fwnode-in-error-case-during-probe.patch
+iio-adc-ad7768-1-fix-too-small-buffer-passed-to-iio_push_to_buffers_with_timestamp.patch
+iio-adc-ad7124-fix-missbalanced-regulator-enable-disable-on-error.patch
+iio-adc-ad7124-fix-potential-overflow-due-to-non-sequential-channel-numbers.patch
+iio-adc-ad7923-fix-undersized-rx-buffer.patch
+iio-adc-ad7793-add-missing-error-code-in-ad7793_setup.patch
+iio-adc-ad7192-avoid-disabling-a-clock-that-was-never-enabled.patch
+iio-adc-ad7192-handle-regulator-voltage-error-first.patch
+serial-8250-add-uart_bug_txrace-workaround-for-aspeed-vuart.patch
+serial-8250_dw-add-device-hid-for-new-amd-uart-controller.patch
+serial-8250_pci-add-support-for-new-hpe-serial-device.patch
+serial-8250_pci-handle-fl_noirq-board-flag.patch
+usb-trancevibrator-fix-control-request-direction.patch
+revert-irqbypass-do-not-start-cons-prod-when-failed-connect.patch
--- /dev/null
+From 04f5b9f539ce314f758d919a14dc7a669f3b7838 Mon Sep 17 00:00:00 2001
+From: Lucas Stankus <lucas.p.stankus@gmail.com>
+Date: Tue, 11 May 2021 17:54:18 -0300
+Subject: staging: iio: cdc: ad7746: avoid overwrite of num_channels
+
+From: Lucas Stankus <lucas.p.stankus@gmail.com>
+
+commit 04f5b9f539ce314f758d919a14dc7a669f3b7838 upstream.
+
+AD7745 devices don't have the CIN2 pins and therefore can't handle related
+channels. Forcing the number of AD7746 channels may lead to enabling more
+channels than what the hardware actually supports.
+Avoid num_channels being overwritten after first assignment.
+
+Signed-off-by: Lucas Stankus <lucas.p.stankus@gmail.com>
+Fixes: 83e416f458d53 ("staging: iio: adc: Replace, rewrite ad7745 from scratch.")
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/iio/cdc/ad7746.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/staging/iio/cdc/ad7746.c
++++ b/drivers/staging/iio/cdc/ad7746.c
+@@ -700,7 +700,6 @@ static int ad7746_probe(struct i2c_clien
+ indio_dev->num_channels = ARRAY_SIZE(ad7746_channels);
+ else
+ indio_dev->num_channels = ARRAY_SIZE(ad7746_channels) - 2;
+- indio_dev->num_channels = ARRAY_SIZE(ad7746_channels);
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ if (pdata) {
--- /dev/null
+From b106776080a1cf953a1b2fd50cb2a995db4732be Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Tue, 27 Apr 2021 15:48:29 +0300
+Subject: thunderbolt: dma_port: Fix NVM read buffer bounds and offset issue
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit b106776080a1cf953a1b2fd50cb2a995db4732be upstream.
+
+Up to 64 bytes of data can be read from NVM in one go. Read address
+must be dword aligned. Data is read into a local buffer.
+
+If caller asks to read data starting at an unaligned address then full
+dword is anyway read from NVM into a local buffer. Data is then copied
+from the local buffer starting at the unaligned offset to the caller
+buffer.
+
+In cases where asked data length + unaligned offset is over 64 bytes
+we need to make sure we don't read past the 64 bytes in the local
+buffer when copying to caller buffer, and make sure that we don't
+skip copying unaligned offset bytes from local buffer anymore after
+the first round of 64 byte NVM data read.
+
+Fixes: 3e13676862f9 ("thunderbolt: Add support for DMA configuration based mailbox")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thunderbolt/dma_port.c | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+--- a/drivers/thunderbolt/dma_port.c
++++ b/drivers/thunderbolt/dma_port.c
+@@ -366,15 +366,15 @@ int dma_port_flash_read(struct tb_dma_po
+ void *buf, size_t size)
+ {
+ unsigned int retries = DMA_PORT_RETRIES;
+- unsigned int offset;
+-
+- offset = address & 3;
+- address = address & ~3;
+
+ do {
+- u32 nbytes = min_t(u32, size, MAIL_DATA_DWORDS * 4);
++ unsigned int offset;
++ size_t nbytes;
+ int ret;
+
++ offset = address & 3;
++ nbytes = min_t(size_t, size + offset, MAIL_DATA_DWORDS * 4);
++
+ ret = dma_port_flash_read_block(dma, address, dma->buf,
+ ALIGN(nbytes, 4));
+ if (ret) {
+@@ -386,6 +386,7 @@ int dma_port_flash_read(struct tb_dma_po
+ return ret;
+ }
+
++ nbytes -= offset;
+ memcpy(buf, dma->buf + offset, nbytes);
+
+ size -= nbytes;
--- /dev/null
+From 22c7a18ed5f007faccb7527bc890463763214081 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Thu, 25 Mar 2021 10:32:50 +0200
+Subject: thunderbolt: usb4: Fix NVM read buffer bounds and offset issue
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit 22c7a18ed5f007faccb7527bc890463763214081 upstream.
+
+Up to 64 bytes of data can be read from NVM in one go.
+Read address must be dword aligned. Data is read into a local buffer.
+
+If caller asks to read data starting at an unaligned address then full
+dword is anyway read from NVM into a local buffer. Data is then copied
+from the local buffer starting at the unaligned offset to the caller
+buffer.
+
+In cases where asked data length + unaligned offset is over 64 bytes
+we need to make sure we don't read past the 64 bytes in the local
+buffer when copying to caller buffer, and make sure that we don't
+skip copying unaligned offset bytes from local buffer anymore after
+the first round of 64 byte NVM data read.
+
+Fixes: b04079837b20 ("thunderbolt: Add initial support for USB4")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thunderbolt/usb4.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/drivers/thunderbolt/usb4.c
++++ b/drivers/thunderbolt/usb4.c
+@@ -68,15 +68,15 @@ static int usb4_do_read_data(u16 address
+ unsigned int retries = USB4_DATA_RETRIES;
+ unsigned int offset;
+
+- offset = address & 3;
+- address = address & ~3;
+-
+ do {
+- size_t nbytes = min_t(size_t, size, USB4_DATA_DWORDS * 4);
+ unsigned int dwaddress, dwords;
+ u8 data[USB4_DATA_DWORDS * 4];
++ size_t nbytes;
+ int ret;
+
++ offset = address & 3;
++ nbytes = min_t(size_t, size + offset, USB4_DATA_DWORDS * 4);
++
+ dwaddress = address / 4;
+ dwords = ALIGN(nbytes, 4) / 4;
+
+@@ -87,6 +87,7 @@ static int usb4_do_read_data(u16 address
+ return ret;
+ }
+
++ nbytes -= offset;
+ memcpy(buf, data + offset, nbytes);
+
+ size -= nbytes;
--- /dev/null
+From 746e4acf87bcacf1406e05ef24a0b7139147c63e Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 21 May 2021 15:31:09 +0200
+Subject: USB: trancevibrator: fix control-request direction
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 746e4acf87bcacf1406e05ef24a0b7139147c63e upstream.
+
+The direction of the pipe argument must match the request-type direction
+bit or control requests may fail depending on the host-controller-driver
+implementation.
+
+Fix the set-speed request which erroneously used USB_DIR_IN and update
+the default timeout argument to match (same value).
+
+Fixes: 5638e4d92e77 ("USB: add PlayStation 2 Trance Vibrator driver")
+Cc: stable@vger.kernel.org # 2.6.19
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Link: https://lore.kernel.org/r/20210521133109.17396-1-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/misc/trancevibrator.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/misc/trancevibrator.c
++++ b/drivers/usb/misc/trancevibrator.c
+@@ -61,9 +61,9 @@ static ssize_t speed_store(struct device
+ /* Set speed */
+ retval = usb_control_msg(tv->udev, usb_sndctrlpipe(tv->udev, 0),
+ 0x01, /* vendor request: set speed */
+- USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
++ USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_OTHER,
+ tv->speed, /* speed value */
+- 0, NULL, 0, USB_CTRL_GET_TIMEOUT);
++ 0, NULL, 0, USB_CTRL_SET_TIMEOUT);
+ if (retval) {
+ tv->speed = old;
+ dev_dbg(&tv->udev->dev, "retval = %d\n", retval);