--- /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
+@@ -564,6 +564,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 spi_device_id *id;
+@@ -607,17 +612,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)
+@@ -643,11 +651,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;
+ }
+@@ -656,17 +659,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
+@@ -473,6 +473,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 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
+@@ -166,6 +166,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;
+@@ -459,11 +463,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
+@@ -278,6 +278,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 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
+@@ -333,6 +333,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;
+ }
+
+@@ -366,6 +367,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 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
+@@ -222,6 +222,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 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
+@@ -58,6 +58,8 @@ struct serial_private {
+ int line[0];
+ };
+
++#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) },
+@@ -65,6 +67,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) },
+ { }
+ };
+
+@@ -1966,6 +1970,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
+ */
+ {
+@@ -4932,6 +4946,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
+@@ -3917,21 +3917,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
+@@ -863,9 +863,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.
selftests-gpio-move-include-of-lib.mk-up.patch
selftests-gpio-fix-build-when-source-tree-is-read-on.patch
kgdb-fix-gcc-11-warnings-harder.patch
+documentation-seccomp-fix-user-notification-documentation.patch
+serial-core-fix-suspicious-security_locked_down-call.patch
+misc-uss720-fix-memory-leak-in-uss720_probe.patch
+thunderbolt-dma_port-fix-nvm-read-buffer-bounds-and-offset-issue.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-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-ad7793-add-missing-error-code-in-ad7793_setup.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
--- /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
+@@ -702,7 +702,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
+@@ -364,15 +364,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) {
+@@ -384,6 +384,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 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);
projects / thirdparty / kernel / stable-queue.git / commitdiff
