]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.14-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 13 Dec 2021 08:30:57 +0000 (09:30 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 13 Dec 2021 08:30:57 +0000 (09:30 +0100)
added patches:
iio-accel-kxcjk-1013-fix-possible-memory-leak-in-probe-and-remove.patch
iio-adc-axp20x_adc-fix-charging-current-reporting-on-axp22x.patch
iio-dln2-adc-fix-lockdep-complaint.patch
iio-dln2-check-return-value-of-devm_iio_trigger_register.patch
iio-itg3200-call-iio_trigger_notify_done-on-error.patch
iio-kxsd9-don-t-return-error-code-in-trigger-handler.patch
iio-ltr501-don-t-return-error-code-in-trigger-handler.patch
iio-mma8452-fix-trigger-reference-couting.patch
iio-stk3310-don-t-return-error-code-in-interrupt-handler.patch
iio-trigger-fix-reference-counting.patch
iio-trigger-stm32-timer-fix-module_alias.patch
irqchip-armada-370-xp-fix-return-value-of-armada_370_xp_msi_alloc.patch
irqchip-armada-370-xp-fix-support-for-multi-msi-interrupts.patch
irqchip-irq-gic-v3-its.c-force-synchronisation-when-issuing-invall.patch
irqchip-nvic-fix-offset-for-interrupt-priority-offsets.patch
usb-core-config-fix-validation-of-wmaxpacketvalue-entries.patch
usb-core-config-using-bit-mask-instead-of-individual-bits.patch
usb-gadget-detect-too-big-endpoint-0-requests.patch
usb-gadget-zero-allocate-endpoint-0-buffers.patch
xhci-remove-config_usb_default_persist-to-prevent-xhci-from-runtime-suspending.patch

21 files changed:
queue-4.14/iio-accel-kxcjk-1013-fix-possible-memory-leak-in-probe-and-remove.patch [new file with mode: 0644]
queue-4.14/iio-adc-axp20x_adc-fix-charging-current-reporting-on-axp22x.patch [new file with mode: 0644]
queue-4.14/iio-dln2-adc-fix-lockdep-complaint.patch [new file with mode: 0644]
queue-4.14/iio-dln2-check-return-value-of-devm_iio_trigger_register.patch [new file with mode: 0644]
queue-4.14/iio-itg3200-call-iio_trigger_notify_done-on-error.patch [new file with mode: 0644]
queue-4.14/iio-kxsd9-don-t-return-error-code-in-trigger-handler.patch [new file with mode: 0644]
queue-4.14/iio-ltr501-don-t-return-error-code-in-trigger-handler.patch [new file with mode: 0644]
queue-4.14/iio-mma8452-fix-trigger-reference-couting.patch [new file with mode: 0644]
queue-4.14/iio-stk3310-don-t-return-error-code-in-interrupt-handler.patch [new file with mode: 0644]
queue-4.14/iio-trigger-fix-reference-counting.patch [new file with mode: 0644]
queue-4.14/iio-trigger-stm32-timer-fix-module_alias.patch [new file with mode: 0644]
queue-4.14/irqchip-armada-370-xp-fix-return-value-of-armada_370_xp_msi_alloc.patch [new file with mode: 0644]
queue-4.14/irqchip-armada-370-xp-fix-support-for-multi-msi-interrupts.patch [new file with mode: 0644]
queue-4.14/irqchip-irq-gic-v3-its.c-force-synchronisation-when-issuing-invall.patch [new file with mode: 0644]
queue-4.14/irqchip-nvic-fix-offset-for-interrupt-priority-offsets.patch [new file with mode: 0644]
queue-4.14/series
queue-4.14/usb-core-config-fix-validation-of-wmaxpacketvalue-entries.patch [new file with mode: 0644]
queue-4.14/usb-core-config-using-bit-mask-instead-of-individual-bits.patch [new file with mode: 0644]
queue-4.14/usb-gadget-detect-too-big-endpoint-0-requests.patch [new file with mode: 0644]
queue-4.14/usb-gadget-zero-allocate-endpoint-0-buffers.patch [new file with mode: 0644]
queue-4.14/xhci-remove-config_usb_default_persist-to-prevent-xhci-from-runtime-suspending.patch [new file with mode: 0644]

diff --git a/queue-4.14/iio-accel-kxcjk-1013-fix-possible-memory-leak-in-probe-and-remove.patch b/queue-4.14/iio-accel-kxcjk-1013-fix-possible-memory-leak-in-probe-and-remove.patch
new file mode 100644 (file)
index 0000000..b4cb757
--- /dev/null
@@ -0,0 +1,60 @@
+From 70c9774e180d151abaab358108e3510a8e615215 Mon Sep 17 00:00:00 2001
+From: Yang Yingliang <yangyingliang@huawei.com>
+Date: Mon, 25 Oct 2021 20:41:59 +0800
+Subject: iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+commit 70c9774e180d151abaab358108e3510a8e615215 upstream.
+
+When ACPI type is ACPI_SMO8500, the data->dready_trig will not be set, the
+memory allocated by iio_triggered_buffer_setup() will not be freed, and cause
+memory leak as follows:
+
+unreferenced object 0xffff888009551400 (size 512):
+  comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s)
+  hex dump (first 32 bytes):
+    02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
+    00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff  ........ .......
+  backtrace:
+    [<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360
+    [<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf]
+    [<000000004b40c1f5>] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer]
+    [<000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013]
+
+Fix it by remove data->dready_trig condition in probe and remove.
+
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Fixes: a25691c1f967 ("iio: accel: kxcjk1013: allow using an external trigger")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Cc: <Stable@vger.kernel.org>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Link: https://lore.kernel.org/r/20211025124159.2700301-1-yangyingliang@huawei.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/accel/kxcjk-1013.c |    5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/accel/kxcjk-1013.c
++++ b/drivers/iio/accel/kxcjk-1013.c
+@@ -1326,8 +1326,7 @@ static int kxcjk1013_probe(struct i2c_cl
+       return 0;
+ err_buffer_cleanup:
+-      if (data->dready_trig)
+-              iio_triggered_buffer_cleanup(indio_dev);
++      iio_triggered_buffer_cleanup(indio_dev);
+ err_trigger_unregister:
+       if (data->dready_trig)
+               iio_trigger_unregister(data->dready_trig);
+@@ -1350,8 +1349,8 @@ static int kxcjk1013_remove(struct i2c_c
+       pm_runtime_set_suspended(&client->dev);
+       pm_runtime_put_noidle(&client->dev);
++      iio_triggered_buffer_cleanup(indio_dev);
+       if (data->dready_trig) {
+-              iio_triggered_buffer_cleanup(indio_dev);
+               iio_trigger_unregister(data->dready_trig);
+               iio_trigger_unregister(data->motion_trig);
+       }
diff --git a/queue-4.14/iio-adc-axp20x_adc-fix-charging-current-reporting-on-axp22x.patch b/queue-4.14/iio-adc-axp20x_adc-fix-charging-current-reporting-on-axp22x.patch
new file mode 100644 (file)
index 0000000..ef818ed
--- /dev/null
@@ -0,0 +1,66 @@
+From 92beafb76a31bdc02649eb44e93a8e4f4cfcdbe8 Mon Sep 17 00:00:00 2001
+From: Evgeny Boger <boger@wirenboard.com>
+Date: Wed, 17 Nov 2021 00:37:46 +0300
+Subject: iio: adc: axp20x_adc: fix charging current reporting on AXP22x
+
+From: Evgeny Boger <boger@wirenboard.com>
+
+commit 92beafb76a31bdc02649eb44e93a8e4f4cfcdbe8 upstream.
+
+Both the charging and discharging currents on AXP22x are stored as
+12-bit integers, in accordance with the datasheet.
+It's also confirmed by vendor BSP (axp20x_adc.c:axp22_icharge_to_mA).
+
+The scale factor of 0.5 is never mentioned in datasheet, nor in the
+vendor source code. I think it was here to compensate for
+erroneous addition bit in register width.
+
+Tested on custom A40i+AXP221s board with external ammeter as
+a reference.
+
+Fixes: 0e34d5de961d ("iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs")
+Signed-off-by: Evgeny Boger <boger@wirenboard.com>
+Acked-by: Chen-Yu Tsai <wens@csie.org>
+Link: https://lore.kernel.org/r/20211116213746.264378-1-boger@wirenboard.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/axp20x_adc.c |   18 +++---------------
+ 1 file changed, 3 insertions(+), 15 deletions(-)
+
+--- a/drivers/iio/adc/axp20x_adc.c
++++ b/drivers/iio/adc/axp20x_adc.c
+@@ -224,19 +224,8 @@ static int axp22x_adc_raw(struct iio_dev
+                         struct iio_chan_spec const *chan, int *val)
+ {
+       struct axp20x_adc_iio *info = iio_priv(indio_dev);
+-      int size;
+-      /*
+-       * N.B.: Unlike the Chinese datasheets tell, the charging current is
+-       * stored on 12 bits, not 13 bits. Only discharging current is on 13
+-       * bits.
+-       */
+-      if (chan->type == IIO_CURRENT && chan->channel == AXP22X_BATT_DISCHRG_I)
+-              size = 13;
+-      else
+-              size = 12;
+-
+-      *val = axp20x_read_variable_width(info->regmap, chan->address, size);
++      *val = axp20x_read_variable_width(info->regmap, chan->address, 12);
+       if (*val < 0)
+               return *val;
+@@ -329,9 +318,8 @@ static int axp22x_adc_scale(struct iio_c
+               return IIO_VAL_INT_PLUS_MICRO;
+       case IIO_CURRENT:
+-              *val = 0;
+-              *val2 = 500000;
+-              return IIO_VAL_INT_PLUS_MICRO;
++              *val = 1;
++              return IIO_VAL_INT;
+       case IIO_TEMP:
+               *val = 100;
diff --git a/queue-4.14/iio-dln2-adc-fix-lockdep-complaint.patch b/queue-4.14/iio-dln2-adc-fix-lockdep-complaint.patch
new file mode 100644 (file)
index 0000000..736c144
--- /dev/null
@@ -0,0 +1,94 @@
+From 59f92868176f191eefde70d284bdfc1ed76a84bc Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Noralf=20Tr=C3=B8nnes?= <noralf@tronnes.org>
+Date: Mon, 18 Oct 2021 13:37:31 +0200
+Subject: iio: dln2-adc: Fix lockdep complaint
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Noralf Trønnes <noralf@tronnes.org>
+
+commit 59f92868176f191eefde70d284bdfc1ed76a84bc upstream.
+
+When reading the voltage:
+
+$ cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw
+
+Lockdep complains:
+
+[  153.910616] ======================================================
+[  153.916918] WARNING: possible circular locking dependency detected
+[  153.923221] 5.14.0+ #5 Not tainted
+[  153.926692] ------------------------------------------------------
+[  153.932992] cat/717 is trying to acquire lock:
+[  153.937525] c2585358 (&indio_dev->mlock){+.+.}-{3:3}, at: iio_device_claim_direct_mode+0x28/0x44
+[  153.946541]
+               but task is already holding lock:
+[  153.952487] c2585860 (&dln2->mutex){+.+.}-{3:3}, at: dln2_adc_read_raw+0x94/0x2bc [dln2_adc]
+[  153.961152]
+               which lock already depends on the new lock.
+
+Fix this by not calling into the iio core underneath the dln2->mutex lock.
+
+Fixes: 7c0299e879dd ("iio: adc: Add support for DLN2 ADC")
+Cc: Jack Andersen <jackoalan@gmail.com>
+Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
+Link: https://lore.kernel.org/r/20211018113731.25723-1-noralf@tronnes.org
+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/dln2-adc.c |   15 +++++++--------
+ 1 file changed, 7 insertions(+), 8 deletions(-)
+
+--- a/drivers/iio/adc/dln2-adc.c
++++ b/drivers/iio/adc/dln2-adc.c
+@@ -251,7 +251,6 @@ static int dln2_adc_set_chan_period(stru
+ static int dln2_adc_read(struct dln2_adc *dln2, unsigned int channel)
+ {
+       int ret, i;
+-      struct iio_dev *indio_dev = platform_get_drvdata(dln2->pdev);
+       u16 conflict;
+       __le16 value;
+       int olen = sizeof(value);
+@@ -260,13 +259,9 @@ static int dln2_adc_read(struct dln2_adc
+               .chan = channel,
+       };
+-      ret = iio_device_claim_direct_mode(indio_dev);
+-      if (ret < 0)
+-              return ret;
+-
+       ret = dln2_adc_set_chan_enabled(dln2, channel, true);
+       if (ret < 0)
+-              goto release_direct;
++              return ret;
+       ret = dln2_adc_set_port_enabled(dln2, true, &conflict);
+       if (ret < 0) {
+@@ -303,8 +298,6 @@ disable_port:
+       dln2_adc_set_port_enabled(dln2, false, NULL);
+ disable_chan:
+       dln2_adc_set_chan_enabled(dln2, channel, false);
+-release_direct:
+-      iio_device_release_direct_mode(indio_dev);
+       return ret;
+ }
+@@ -340,10 +333,16 @@ static int dln2_adc_read_raw(struct iio_
+       switch (mask) {
+       case IIO_CHAN_INFO_RAW:
++              ret = iio_device_claim_direct_mode(indio_dev);
++              if (ret < 0)
++                      return ret;
++
+               mutex_lock(&dln2->mutex);
+               ret = dln2_adc_read(dln2, chan->channel);
+               mutex_unlock(&dln2->mutex);
++              iio_device_release_direct_mode(indio_dev);
++
+               if (ret < 0)
+                       return ret;
diff --git a/queue-4.14/iio-dln2-check-return-value-of-devm_iio_trigger_register.patch b/queue-4.14/iio-dln2-check-return-value-of-devm_iio_trigger_register.patch
new file mode 100644 (file)
index 0000000..70d19f2
--- /dev/null
@@ -0,0 +1,38 @@
+From 90751fb9f224e0e1555b49a8aa9e68f6537e4cec Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Mon, 1 Nov 2021 14:30:43 +0100
+Subject: iio: dln2: Check return value of devm_iio_trigger_register()
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 90751fb9f224e0e1555b49a8aa9e68f6537e4cec upstream.
+
+Registering a trigger can fail and the return value of
+devm_iio_trigger_register() must be checked. Otherwise undefined behavior
+can occur when the trigger is used.
+
+Fixes: 7c0299e879dd ("iio: adc: Add support for DLN2 ADC")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Link: https://lore.kernel.org/r/20211101133043.6974-1-lars@metafoo.de
+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/dln2-adc.c |    6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/iio/adc/dln2-adc.c
++++ b/drivers/iio/adc/dln2-adc.c
+@@ -674,7 +674,11 @@ static int dln2_adc_probe(struct platfor
+       }
+       dln2->trig->ops = &dln2_adc_trigger_ops;
+       iio_trigger_set_drvdata(dln2->trig, dln2);
+-      devm_iio_trigger_register(dev, dln2->trig);
++      ret = devm_iio_trigger_register(dev, dln2->trig);
++      if (ret) {
++              dev_err(dev, "failed to register trigger: %d\n", ret);
++              return ret;
++      }
+       iio_trigger_set_immutable(indio_dev, dln2->trig);
+       ret = devm_iio_triggered_buffer_setup(dev, indio_dev, NULL,
diff --git a/queue-4.14/iio-itg3200-call-iio_trigger_notify_done-on-error.patch b/queue-4.14/iio-itg3200-call-iio_trigger_notify_done-on-error.patch
new file mode 100644 (file)
index 0000000..fab2bb2
--- /dev/null
@@ -0,0 +1,41 @@
+From 67fe29583e72b2103abb661bb58036e3c1f00277 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Mon, 1 Nov 2021 15:40:54 +0100
+Subject: iio: itg3200: Call iio_trigger_notify_done() on error
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 67fe29583e72b2103abb661bb58036e3c1f00277 upstream.
+
+IIO trigger handlers must call iio_trigger_notify_done() when done. This
+must be done even when an error occurred. Otherwise the trigger will be
+seen as busy indefinitely and the trigger handler will never be called
+again.
+
+The itg3200 driver neglects to call iio_trigger_notify_done() when there is
+an error reading the gyro data. Fix this by making sure that
+iio_trigger_notify_done() is included in the error exit path.
+
+Fixes: 9dbf091da080 ("iio: gyro: Add itg3200")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Link: https://lore.kernel.org/r/20211101144055.13858-1-lars@metafoo.de
+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/itg3200_buffer.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/gyro/itg3200_buffer.c
++++ b/drivers/iio/gyro/itg3200_buffer.c
+@@ -64,9 +64,9 @@ static irqreturn_t itg3200_trigger_handl
+       iio_push_to_buffers_with_timestamp(indio_dev, &scan, pf->timestamp);
++error_ret:
+       iio_trigger_notify_done(indio_dev->trig);
+-error_ret:
+       return IRQ_HANDLED;
+ }
diff --git a/queue-4.14/iio-kxsd9-don-t-return-error-code-in-trigger-handler.patch b/queue-4.14/iio-kxsd9-don-t-return-error-code-in-trigger-handler.patch
new file mode 100644 (file)
index 0000000..fa8b750
--- /dev/null
@@ -0,0 +1,54 @@
+From 45febe0d63917ee908198c5be08511c64ee1790a Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Sun, 24 Oct 2021 19:12:50 +0200
+Subject: iio: kxsd9: Don't return error code in trigger handler
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 45febe0d63917ee908198c5be08511c64ee1790a upstream.
+
+IIO trigger handlers need to return one of the irqreturn_t values.
+Returning an error code is not supported.
+
+The kxsd9 interrupt handler returns an error code if reading the data
+registers fails. In addition when exiting due to an error the trigger
+handler does not call `iio_trigger_notify_done()`. Which when not done
+keeps the triggered disabled forever.
+
+Modify the code so that the function returns a valid irqreturn_t value as
+well as calling `iio_trigger_notify_done()` on all exit paths.
+
+Since we can't return the error code make sure to at least log it as part
+of the error message.
+
+Fixes: 0427a106a98a ("iio: accel: kxsd9: Add triggered buffer handling")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/20211024171251.22896-2-lars@metafoo.de
+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/accel/kxsd9.c |    6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/accel/kxsd9.c
++++ b/drivers/iio/accel/kxsd9.c
+@@ -227,14 +227,14 @@ static irqreturn_t kxsd9_trigger_handler
+                              hw_values.chan,
+                              sizeof(hw_values.chan));
+       if (ret) {
+-              dev_err(st->dev,
+-                      "error reading data\n");
+-              return ret;
++              dev_err(st->dev, "error reading data: %d\n", ret);
++              goto out;
+       }
+       iio_push_to_buffers_with_timestamp(indio_dev,
+                                          &hw_values,
+                                          iio_get_time_ns(indio_dev));
++out:
+       iio_trigger_notify_done(indio_dev->trig);
+       return IRQ_HANDLED;
diff --git a/queue-4.14/iio-ltr501-don-t-return-error-code-in-trigger-handler.patch b/queue-4.14/iio-ltr501-don-t-return-error-code-in-trigger-handler.patch
new file mode 100644 (file)
index 0000000..088194f
--- /dev/null
@@ -0,0 +1,43 @@
+From ef9d67fa72c1b149a420587e435a3e888bdbf74f Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Sun, 24 Oct 2021 19:12:49 +0200
+Subject: iio: ltr501: Don't return error code in trigger handler
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit ef9d67fa72c1b149a420587e435a3e888bdbf74f upstream.
+
+IIO trigger handlers need to return one of the irqreturn_t values.
+Returning an error code is not supported.
+
+The ltr501 interrupt handler gets this right for most error paths, but
+there is one case where it returns the error code.
+
+In addition for this particular case the trigger handler does not call
+`iio_trigger_notify_done()`. Which when not done keeps the triggered
+disabled forever.
+
+Modify the code so that the function returns a valid irqreturn_t value as
+well as calling `iio_trigger_notify_done()` on all exit paths.
+
+Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Link: https://lore.kernel.org/r/20211024171251.22896-1-lars@metafoo.de
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/light/ltr501.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/light/ltr501.c
++++ b/drivers/iio/light/ltr501.c
+@@ -1279,7 +1279,7 @@ static irqreturn_t ltr501_trigger_handle
+               ret = regmap_bulk_read(data->regmap, LTR501_ALS_DATA1,
+                                      (u8 *)als_buf, sizeof(als_buf));
+               if (ret < 0)
+-                      return ret;
++                      goto done;
+               if (test_bit(0, indio_dev->active_scan_mask))
+                       scan.channels[j++] = le16_to_cpu(als_buf[1]);
+               if (test_bit(1, indio_dev->active_scan_mask))
diff --git a/queue-4.14/iio-mma8452-fix-trigger-reference-couting.patch b/queue-4.14/iio-mma8452-fix-trigger-reference-couting.patch
new file mode 100644 (file)
index 0000000..fb01394
--- /dev/null
@@ -0,0 +1,41 @@
+From cd0082235783f814241a1c9483fb89e405f4f892 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Sun, 24 Oct 2021 11:26:59 +0200
+Subject: iio: mma8452: Fix trigger reference couting
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit cd0082235783f814241a1c9483fb89e405f4f892 upstream.
+
+The mma8452 driver directly assigns a trigger to the struct iio_dev. The
+IIO core when done using this trigger will call `iio_trigger_put()` to drop
+the reference count by 1.
+
+Without the matching `iio_trigger_get()` in the driver the reference count
+can reach 0 too early, the trigger gets freed while still in use and a
+use-after-free occurs.
+
+Fix this by getting a reference to the trigger before assigning it to the
+IIO device.
+
+Fixes: ae6d9ce05691 ("iio: mma8452: Add support for interrupt driven triggers.")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Link: https://lore.kernel.org/r/20211024092700.6844-1-lars@metafoo.de
+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/accel/mma8452.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/accel/mma8452.c
++++ b/drivers/iio/accel/mma8452.c
+@@ -1396,7 +1396,7 @@ static int mma8452_trigger_setup(struct
+       if (ret)
+               return ret;
+-      indio_dev->trig = trig;
++      indio_dev->trig = iio_trigger_get(trig);
+       return 0;
+ }
diff --git a/queue-4.14/iio-stk3310-don-t-return-error-code-in-interrupt-handler.patch b/queue-4.14/iio-stk3310-don-t-return-error-code-in-interrupt-handler.patch
new file mode 100644 (file)
index 0000000..2bca24f
--- /dev/null
@@ -0,0 +1,49 @@
+From 8e1eeca5afa7ba84d885987165dbdc5decf15413 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Sun, 24 Oct 2021 19:12:51 +0200
+Subject: iio: stk3310: Don't return error code in interrupt handler
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 8e1eeca5afa7ba84d885987165dbdc5decf15413 upstream.
+
+Interrupt handlers must return one of the irqreturn_t values. Returning a
+error code is not supported.
+
+The stk3310 event interrupt handler returns an error code when reading the
+flags register fails.
+
+Fix the implementation to always return an irqreturn_t value.
+
+Fixes: 3dd477acbdd1 ("iio: light: Add threshold interrupt support for STK3310")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Link: https://lore.kernel.org/r/20211024171251.22896-3-lars@metafoo.de
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/light/stk3310.c |    6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/light/stk3310.c
++++ b/drivers/iio/light/stk3310.c
+@@ -546,9 +546,8 @@ static irqreturn_t stk3310_irq_event_han
+       mutex_lock(&data->lock);
+       ret = regmap_field_read(data->reg_flag_nf, &dir);
+       if (ret < 0) {
+-              dev_err(&data->client->dev, "register read failed\n");
+-              mutex_unlock(&data->lock);
+-              return ret;
++              dev_err(&data->client->dev, "register read failed: %d\n", ret);
++              goto out;
+       }
+       event = IIO_UNMOD_EVENT_CODE(IIO_PROXIMITY, 1,
+                                    IIO_EV_TYPE_THRESH,
+@@ -560,6 +559,7 @@ static irqreturn_t stk3310_irq_event_han
+       ret = regmap_field_write(data->reg_flag_psint, 0);
+       if (ret < 0)
+               dev_err(&data->client->dev, "failed to reset interrupts\n");
++out:
+       mutex_unlock(&data->lock);
+       return IRQ_HANDLED;
diff --git a/queue-4.14/iio-trigger-fix-reference-counting.patch b/queue-4.14/iio-trigger-fix-reference-counting.patch
new file mode 100644 (file)
index 0000000..dad8ae1
--- /dev/null
@@ -0,0 +1,48 @@
+From a827a4984664308f13599a0b26c77018176d0c7c Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Sun, 24 Oct 2021 11:27:00 +0200
+Subject: iio: trigger: Fix reference counting
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit a827a4984664308f13599a0b26c77018176d0c7c upstream.
+
+In viio_trigger_alloc() device_initialize() is used to set the initial
+reference count of the trigger to 1. Then another get_device() is called on
+trigger. This sets the reference count to 2 before the trigger is returned.
+
+iio_trigger_free(), which is the matching API to viio_trigger_alloc(),
+calls put_device() which decreases the reference count by 1. But the second
+reference count acquired in viio_trigger_alloc() is never dropped.
+
+As a result the iio_trigger_release() function is never called and the
+memory associated with the trigger is never freed.
+
+Since there is no reason for the trigger to start its lifetime with two
+reference counts just remove the extra get_device() in
+viio_trigger_alloc().
+
+Fixes: 5f9c035cae18 ("staging:iio:triggers. Add a reference get to the core for triggers.")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Acked-by: Nuno Sá <nuno.sa@analog.com>
+Link: https://lore.kernel.org/r/20211024092700.6844-2-lars@metafoo.de
+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/industrialio-trigger.c |    1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/iio/industrialio-trigger.c
++++ b/drivers/iio/industrialio-trigger.c
+@@ -549,7 +549,6 @@ static struct iio_trigger *viio_trigger_
+               irq_modify_status(trig->subirq_base + i,
+                                 IRQ_NOREQUEST | IRQ_NOAUTOEN, IRQ_NOPROBE);
+       }
+-      get_device(&trig->dev);
+       return trig;
diff --git a/queue-4.14/iio-trigger-stm32-timer-fix-module_alias.patch b/queue-4.14/iio-trigger-stm32-timer-fix-module_alias.patch
new file mode 100644 (file)
index 0000000..de08eb5
--- /dev/null
@@ -0,0 +1,31 @@
+From 893621e0606747c5bbefcaf2794d12c7aa6212b7 Mon Sep 17 00:00:00 2001
+From: Alyssa Ross <hi@alyssa.is>
+Date: Thu, 25 Nov 2021 18:28:48 +0000
+Subject: iio: trigger: stm32-timer: fix MODULE_ALIAS
+
+From: Alyssa Ross <hi@alyssa.is>
+
+commit 893621e0606747c5bbefcaf2794d12c7aa6212b7 upstream.
+
+modprobe can't handle spaces in aliases.
+
+Fixes: 93fbe91b5521 ("iio: Add STM32 timer trigger driver")
+Signed-off-by: Alyssa Ross <hi@alyssa.is>
+Link: https://lore.kernel.org/r/20211125182850.2645424-1-hi@alyssa.is
+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/trigger/stm32-timer-trigger.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/trigger/stm32-timer-trigger.c
++++ b/drivers/iio/trigger/stm32-timer-trigger.c
+@@ -886,6 +886,6 @@ static struct platform_driver stm32_time
+ };
+ module_platform_driver(stm32_timer_trigger_driver);
+-MODULE_ALIAS("platform: stm32-timer-trigger");
++MODULE_ALIAS("platform:stm32-timer-trigger");
+ MODULE_DESCRIPTION("STMicroelectronics STM32 Timer Trigger driver");
+ MODULE_LICENSE("GPL v2");
diff --git a/queue-4.14/irqchip-armada-370-xp-fix-return-value-of-armada_370_xp_msi_alloc.patch b/queue-4.14/irqchip-armada-370-xp-fix-return-value-of-armada_370_xp_msi_alloc.patch
new file mode 100644 (file)
index 0000000..ca24c7a
--- /dev/null
@@ -0,0 +1,36 @@
+From ce20eff57361e72878a772ef08b5239d3ae102b6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali@kernel.org>
+Date: Thu, 25 Nov 2021 14:00:56 +0100
+Subject: irqchip/armada-370-xp: Fix return value of armada_370_xp_msi_alloc()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Pali Rohár <pali@kernel.org>
+
+commit ce20eff57361e72878a772ef08b5239d3ae102b6 upstream.
+
+IRQ domain alloc function should return zero on success. Non-zero value
+indicates failure.
+
+Signed-off-by: Pali Rohár <pali@kernel.org>
+Fixes: fcc392d501bd ("irqchip/armada-370-xp: Use the generic MSI infrastructure")
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20211125130057.26705-1-pali@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-armada-370-xp.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/irqchip/irq-armada-370-xp.c
++++ b/drivers/irqchip/irq-armada-370-xp.c
+@@ -250,7 +250,7 @@ static int armada_370_xp_msi_alloc(struc
+                                   NULL, NULL);
+       }
+-      return hwirq;
++      return 0;
+ }
+ static void armada_370_xp_msi_free(struct irq_domain *domain,
diff --git a/queue-4.14/irqchip-armada-370-xp-fix-support-for-multi-msi-interrupts.patch b/queue-4.14/irqchip-armada-370-xp-fix-support-for-multi-msi-interrupts.patch
new file mode 100644 (file)
index 0000000..14c7bdb
--- /dev/null
@@ -0,0 +1,62 @@
+From d0a553502efd545c1ce3fd08fc4d423f8e4ac3d6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali@kernel.org>
+Date: Thu, 25 Nov 2021 14:00:57 +0100
+Subject: irqchip/armada-370-xp: Fix support for Multi-MSI interrupts
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Pali Rohár <pali@kernel.org>
+
+commit d0a553502efd545c1ce3fd08fc4d423f8e4ac3d6 upstream.
+
+irq-armada-370-xp driver already sets MSI_FLAG_MULTI_PCI_MSI flag into
+msi_domain_info structure. But allocated interrupt numbers for Multi-MSI
+needs to be properly aligned otherwise devices send MSI interrupt with
+wrong number.
+
+Fix this issue by using function bitmap_find_free_region() instead of
+bitmap_find_next_zero_area() to allocate aligned interrupt numbers.
+
+Signed-off-by: Pali Rohár <pali@kernel.org>
+Fixes: a71b9412c90c ("irqchip/armada-370-xp: Allow allocation of multiple MSIs")
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20211125130057.26705-2-pali@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-armada-370-xp.c |   14 +++++---------
+ 1 file changed, 5 insertions(+), 9 deletions(-)
+
+--- a/drivers/irqchip/irq-armada-370-xp.c
++++ b/drivers/irqchip/irq-armada-370-xp.c
+@@ -232,16 +232,12 @@ static int armada_370_xp_msi_alloc(struc
+       int hwirq, i;
+       mutex_lock(&msi_used_lock);
++      hwirq = bitmap_find_free_region(msi_used, PCI_MSI_DOORBELL_NR,
++                                      order_base_2(nr_irqs));
++      mutex_unlock(&msi_used_lock);
+-      hwirq = bitmap_find_next_zero_area(msi_used, PCI_MSI_DOORBELL_NR,
+-                                         0, nr_irqs, 0);
+-      if (hwirq >= PCI_MSI_DOORBELL_NR) {
+-              mutex_unlock(&msi_used_lock);
++      if (hwirq < 0)
+               return -ENOSPC;
+-      }
+-
+-      bitmap_set(msi_used, hwirq, nr_irqs);
+-      mutex_unlock(&msi_used_lock);
+       for (i = 0; i < nr_irqs; i++) {
+               irq_domain_set_info(domain, virq + i, hwirq + i,
+@@ -259,7 +255,7 @@ static void armada_370_xp_msi_free(struc
+       struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+       mutex_lock(&msi_used_lock);
+-      bitmap_clear(msi_used, d->hwirq, nr_irqs);
++      bitmap_release_region(msi_used, d->hwirq, order_base_2(nr_irqs));
+       mutex_unlock(&msi_used_lock);
+ }
diff --git a/queue-4.14/irqchip-irq-gic-v3-its.c-force-synchronisation-when-issuing-invall.patch b/queue-4.14/irqchip-irq-gic-v3-its.c-force-synchronisation-when-issuing-invall.patch
new file mode 100644 (file)
index 0000000..13d705b
--- /dev/null
@@ -0,0 +1,38 @@
+From b383a42ca523ce54bcbd63f7c8f3cf974abc9b9a Mon Sep 17 00:00:00 2001
+From: Wudi Wang <wangwudi@hisilicon.com>
+Date: Wed, 8 Dec 2021 09:54:29 +0800
+Subject: irqchip/irq-gic-v3-its.c: Force synchronisation when issuing INVALL
+
+From: Wudi Wang <wangwudi@hisilicon.com>
+
+commit b383a42ca523ce54bcbd63f7c8f3cf974abc9b9a upstream.
+
+INVALL CMD specifies that the ITS must ensure any caching associated with
+the interrupt collection defined by ICID is consistent with the LPI
+configuration tables held in memory for all Redistributors. SYNC is
+required to ensure that INVALL is executed.
+
+Currently, LPI configuration data may be inconsistent with that in the
+memory within a short period of time after the INVALL command is executed.
+
+Signed-off-by: Wudi Wang <wangwudi@hisilicon.com>
+Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue")
+Link: https://lore.kernel.org/r/20211208015429.5007-1-zhangshaokun@hisilicon.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-gic-v3-its.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/irqchip/irq-gic-v3-its.c
++++ b/drivers/irqchip/irq-gic-v3-its.c
+@@ -531,7 +531,7 @@ static struct its_collection *its_build_
+       its_fixup_cmd(cmd);
+-      return NULL;
++      return desc->its_invall_cmd.col;
+ }
+ static struct its_vpe *its_build_vinvall_cmd(struct its_cmd_block *cmd,
diff --git a/queue-4.14/irqchip-nvic-fix-offset-for-interrupt-priority-offsets.patch b/queue-4.14/irqchip-nvic-fix-offset-for-interrupt-priority-offsets.patch
new file mode 100644 (file)
index 0000000..8df499f
--- /dev/null
@@ -0,0 +1,33 @@
+From c5e0cbe2858d278a27d5b3fe31890aea5be064c4 Mon Sep 17 00:00:00 2001
+From: Vladimir Murzin <vladimir.murzin@arm.com>
+Date: Wed, 1 Dec 2021 11:02:58 +0000
+Subject: irqchip: nvic: Fix offset for Interrupt Priority Offsets
+
+From: Vladimir Murzin <vladimir.murzin@arm.com>
+
+commit c5e0cbe2858d278a27d5b3fe31890aea5be064c4 upstream.
+
+According to ARM(v7M) ARM Interrupt Priority Offsets located at
+0xE000E400-0xE000E5EC, while 0xE000E300-0xE000E33C covers read-only
+Interrupt Active Bit Registers
+
+Fixes: 292ec080491d ("irqchip: Add support for ARMv7-M NVIC")
+Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20211201110259.84857-1-vladimir.murzin@arm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-nvic.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/irqchip/irq-nvic.c
++++ b/drivers/irqchip/irq-nvic.c
+@@ -29,7 +29,7 @@
+ #define NVIC_ISER             0x000
+ #define NVIC_ICER             0x080
+-#define NVIC_IPR              0x300
++#define NVIC_IPR              0x400
+ #define NVIC_MAX_BANKS                16
+ /*
index df520cbc3a8191db87cfc48d6144d195fab391c6..006aa5efbbce91873ba88b2b732b9034cd5f0fef 100644 (file)
@@ -31,3 +31,23 @@ net-altera-set-a-couple-error-code-in-probe.patch
 net-fec-only-clear-interrupt-of-handling-queue-in-fec_enet_rx_queue.patch
 net-neigh-clear-whole-pneigh_entry-at-alloc-time.patch
 net-qla3xxx-fix-an-error-code-in-ql_adapter_up.patch
+usb-gadget-detect-too-big-endpoint-0-requests.patch
+usb-gadget-zero-allocate-endpoint-0-buffers.patch
+usb-core-config-fix-validation-of-wmaxpacketvalue-entries.patch
+xhci-remove-config_usb_default_persist-to-prevent-xhci-from-runtime-suspending.patch
+usb-core-config-using-bit-mask-instead-of-individual-bits.patch
+iio-trigger-fix-reference-counting.patch
+iio-trigger-stm32-timer-fix-module_alias.patch
+iio-stk3310-don-t-return-error-code-in-interrupt-handler.patch
+iio-mma8452-fix-trigger-reference-couting.patch
+iio-ltr501-don-t-return-error-code-in-trigger-handler.patch
+iio-kxsd9-don-t-return-error-code-in-trigger-handler.patch
+iio-itg3200-call-iio_trigger_notify_done-on-error.patch
+iio-dln2-adc-fix-lockdep-complaint.patch
+iio-dln2-check-return-value-of-devm_iio_trigger_register.patch
+iio-adc-axp20x_adc-fix-charging-current-reporting-on-axp22x.patch
+iio-accel-kxcjk-1013-fix-possible-memory-leak-in-probe-and-remove.patch
+irqchip-armada-370-xp-fix-return-value-of-armada_370_xp_msi_alloc.patch
+irqchip-armada-370-xp-fix-support-for-multi-msi-interrupts.patch
+irqchip-irq-gic-v3-its.c-force-synchronisation-when-issuing-invall.patch
+irqchip-nvic-fix-offset-for-interrupt-priority-offsets.patch
diff --git a/queue-4.14/usb-core-config-fix-validation-of-wmaxpacketvalue-entries.patch b/queue-4.14/usb-core-config-fix-validation-of-wmaxpacketvalue-entries.patch
new file mode 100644 (file)
index 0000000..166bb0d
--- /dev/null
@@ -0,0 +1,37 @@
+From 1a3910c80966e4a76b25ce812f6bea0ef1b1d530 Mon Sep 17 00:00:00 2001
+From: Pavel Hofman <pavel.hofman@ivitera.com>
+Date: Fri, 10 Dec 2021 09:52:18 +0100
+Subject: usb: core: config: fix validation of wMaxPacketValue entries
+
+From: Pavel Hofman <pavel.hofman@ivitera.com>
+
+commit 1a3910c80966e4a76b25ce812f6bea0ef1b1d530 upstream.
+
+The checks performed by commit aed9d65ac327 ("USB: validate
+wMaxPacketValue entries in endpoint descriptors") require that initial
+value of the maxp variable contains both maximum packet size bits
+(10..0) and multiple-transactions bits (12..11). However, the existing
+code assings only the maximum packet size bits. This patch assigns all
+bits of wMaxPacketSize to the variable.
+
+Fixes: aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors")
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com>
+Link: https://lore.kernel.org/r/20211210085219.16796-1-pavel.hofman@ivitera.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/core/config.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/core/config.c
++++ b/drivers/usb/core/config.c
+@@ -409,7 +409,7 @@ static int usb_parse_endpoint(struct dev
+        * the USB-2 spec requires such endpoints to have wMaxPacketSize = 0
+        * (see the end of section 5.6.3), so don't warn about them.
+        */
+-      maxp = usb_endpoint_maxp(&endpoint->desc);
++      maxp = le16_to_cpu(endpoint->desc.wMaxPacketSize);
+       if (maxp == 0 && !(usb_endpoint_xfer_isoc(d) && asnum == 0)) {
+               dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has invalid wMaxPacketSize 0\n",
+                   cfgno, inum, asnum, d->bEndpointAddress);
diff --git a/queue-4.14/usb-core-config-using-bit-mask-instead-of-individual-bits.patch b/queue-4.14/usb-core-config-using-bit-mask-instead-of-individual-bits.patch
new file mode 100644 (file)
index 0000000..f17beb1
--- /dev/null
@@ -0,0 +1,34 @@
+From ca5737396927afd4d57b133fd2874bbcf3421cdb Mon Sep 17 00:00:00 2001
+From: Pavel Hofman <pavel.hofman@ivitera.com>
+Date: Fri, 10 Dec 2021 09:52:19 +0100
+Subject: usb: core: config: using bit mask instead of individual bits
+
+From: Pavel Hofman <pavel.hofman@ivitera.com>
+
+commit ca5737396927afd4d57b133fd2874bbcf3421cdb upstream.
+
+Using standard USB_EP_MAXP_MULT_MASK instead of individual bits for
+extracting multiple-transactions bits from wMaxPacketSize value.
+
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com>
+Link: https://lore.kernel.org/r/20211210085219.16796-2-pavel.hofman@ivitera.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/core/config.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/core/config.c
++++ b/drivers/usb/core/config.c
+@@ -425,9 +425,9 @@ static int usb_parse_endpoint(struct dev
+               maxpacket_maxes = full_speed_maxpacket_maxes;
+               break;
+       case USB_SPEED_HIGH:
+-              /* Bits 12..11 are allowed only for HS periodic endpoints */
++              /* Multiple-transactions bits are allowed only for HS periodic endpoints */
+               if (usb_endpoint_xfer_int(d) || usb_endpoint_xfer_isoc(d)) {
+-                      i = maxp & (BIT(12) | BIT(11));
++                      i = maxp & USB_EP_MAXP_MULT_MASK;
+                       maxp &= ~i;
+               }
+               /* fallthrough */
diff --git a/queue-4.14/usb-gadget-detect-too-big-endpoint-0-requests.patch b/queue-4.14/usb-gadget-detect-too-big-endpoint-0-requests.patch
new file mode 100644 (file)
index 0000000..dcd78b6
--- /dev/null
@@ -0,0 +1,104 @@
+From 153a2d7e3350cc89d406ba2d35be8793a64c2038 Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Thu, 9 Dec 2021 18:59:27 +0100
+Subject: USB: gadget: detect too-big endpoint 0 requests
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit 153a2d7e3350cc89d406ba2d35be8793a64c2038 upstream.
+
+Sometimes USB hosts can ask for buffers that are too large from endpoint
+0, which should not be allowed.  If this happens for OUT requests, stall
+the endpoint, but for IN requests, trim the request size to the endpoint
+buffer size.
+
+Co-developed-by: Szymon Heidrich <szymon.heidrich@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/composite.c    |   12 ++++++++++++
+ drivers/usb/gadget/legacy/dbgp.c  |   13 +++++++++++++
+ drivers/usb/gadget/legacy/inode.c |   16 +++++++++++++++-
+ 3 files changed, 40 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/gadget/composite.c
++++ b/drivers/usb/gadget/composite.c
+@@ -1635,6 +1635,18 @@ composite_setup(struct usb_gadget *gadge
+       struct usb_function             *f = NULL;
+       u8                              endp;
++      if (w_length > USB_COMP_EP0_BUFSIZ) {
++              if (ctrl->bRequestType == USB_DIR_OUT) {
++                      goto done;
++              } else {
++                      /* Cast away the const, we are going to overwrite on purpose. */
++                      __le16 *temp = (__le16 *)&ctrl->wLength;
++
++                      *temp = cpu_to_le16(USB_COMP_EP0_BUFSIZ);
++                      w_length = USB_COMP_EP0_BUFSIZ;
++              }
++      }
++
+       /* partial re-init of the response message; the function or the
+        * gadget might need to intercept e.g. a control-OUT completion
+        * when we delegate to it.
+--- a/drivers/usb/gadget/legacy/dbgp.c
++++ b/drivers/usb/gadget/legacy/dbgp.c
+@@ -344,6 +344,19 @@ static int dbgp_setup(struct usb_gadget
+       void *data = NULL;
+       u16 len = 0;
++      if (length > DBGP_REQ_LEN) {
++              if (ctrl->bRequestType == USB_DIR_OUT) {
++                      return err;
++              } else {
++                      /* Cast away the const, we are going to overwrite on purpose. */
++                      __le16 *temp = (__le16 *)&ctrl->wLength;
++
++                      *temp = cpu_to_le16(DBGP_REQ_LEN);
++                      length = DBGP_REQ_LEN;
++              }
++      }
++
++
+       if (request == USB_REQ_GET_DESCRIPTOR) {
+               switch (value>>8) {
+               case USB_DT_DEVICE:
+--- a/drivers/usb/gadget/legacy/inode.c
++++ b/drivers/usb/gadget/legacy/inode.c
+@@ -113,6 +113,8 @@ enum ep0_state {
+ /* enough for the whole queue: most events invalidate others */
+ #define       N_EVENT                 5
++#define RBUF_SIZE             256
++
+ struct dev_data {
+       spinlock_t                      lock;
+       refcount_t                      count;
+@@ -147,7 +149,7 @@ struct dev_data {
+       struct dentry                   *dentry;
+       /* except this scratch i/o buffer for ep0 */
+-      u8                              rbuf [256];
++      u8                              rbuf[RBUF_SIZE];
+ };
+ static inline void get_dev (struct dev_data *data)
+@@ -1336,6 +1338,18 @@ gadgetfs_setup (struct usb_gadget *gadge
+       u16                             w_value = le16_to_cpu(ctrl->wValue);
+       u16                             w_length = le16_to_cpu(ctrl->wLength);
++      if (w_length > RBUF_SIZE) {
++              if (ctrl->bRequestType == USB_DIR_OUT) {
++                      return value;
++              } else {
++                      /* Cast away the const, we are going to overwrite on purpose. */
++                      __le16 *temp = (__le16 *)&ctrl->wLength;
++
++                      *temp = cpu_to_le16(RBUF_SIZE);
++                      w_length = RBUF_SIZE;
++              }
++      }
++
+       spin_lock (&dev->lock);
+       dev->setup_abort = 0;
+       if (dev->state == STATE_DEV_UNCONNECTED) {
diff --git a/queue-4.14/usb-gadget-zero-allocate-endpoint-0-buffers.patch b/queue-4.14/usb-gadget-zero-allocate-endpoint-0-buffers.patch
new file mode 100644 (file)
index 0000000..926c5ed
--- /dev/null
@@ -0,0 +1,43 @@
+From 86ebbc11bb3f60908a51f3e41a17e3f477c2eaa3 Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Thu, 9 Dec 2021 19:02:15 +0100
+Subject: USB: gadget: zero allocate endpoint 0 buffers
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit 86ebbc11bb3f60908a51f3e41a17e3f477c2eaa3 upstream.
+
+Under some conditions, USB gadget devices can show allocated buffer
+contents to a host.  Fix this up by zero-allocating them so that any
+extra data will all just be zeros.
+
+Reported-by: Szymon Heidrich <szymon.heidrich@gmail.com>
+Tested-by: Szymon Heidrich <szymon.heidrich@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/composite.c   |    2 +-
+ drivers/usb/gadget/legacy/dbgp.c |    2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/gadget/composite.c
++++ b/drivers/usb/gadget/composite.c
+@@ -2191,7 +2191,7 @@ int composite_dev_prepare(struct usb_com
+       if (!cdev->req)
+               return -ENOMEM;
+-      cdev->req->buf = kmalloc(USB_COMP_EP0_BUFSIZ, GFP_KERNEL);
++      cdev->req->buf = kzalloc(USB_COMP_EP0_BUFSIZ, GFP_KERNEL);
+       if (!cdev->req->buf)
+               goto fail;
+--- a/drivers/usb/gadget/legacy/dbgp.c
++++ b/drivers/usb/gadget/legacy/dbgp.c
+@@ -136,7 +136,7 @@ static int dbgp_enable_ep_req(struct usb
+               goto fail_1;
+       }
+-      req->buf = kmalloc(DBGP_REQ_LEN, GFP_KERNEL);
++      req->buf = kzalloc(DBGP_REQ_LEN, GFP_KERNEL);
+       if (!req->buf) {
+               err = -ENOMEM;
+               stp = 2;
diff --git a/queue-4.14/xhci-remove-config_usb_default_persist-to-prevent-xhci-from-runtime-suspending.patch b/queue-4.14/xhci-remove-config_usb_default_persist-to-prevent-xhci-from-runtime-suspending.patch
new file mode 100644 (file)
index 0000000..d292c49
--- /dev/null
@@ -0,0 +1,62 @@
+From 811ae81320da53a5670c36970cefacca8519f90e Mon Sep 17 00:00:00 2001
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Date: Fri, 10 Dec 2021 16:17:34 +0200
+Subject: xhci: Remove CONFIG_USB_DEFAULT_PERSIST to prevent xHCI from runtime suspending
+
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+
+commit 811ae81320da53a5670c36970cefacca8519f90e upstream.
+
+When the xHCI is quirked with XHCI_RESET_ON_RESUME, runtime resume
+routine also resets the controller.
+
+This is bad for USB drivers without reset_resume callback, because
+there's no subsequent call of usb_dev_complete() ->
+usb_resume_complete() to force rebinding the driver to the device. For
+instance, btusb device stops working after xHCI controller is runtime
+resumed, if the controlled is quirked with XHCI_RESET_ON_RESUME.
+
+So always take XHCI_RESET_ON_RESUME into account to solve the issue.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20211210141735.1384209-2-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci.c |    4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -3627,7 +3627,6 @@ static void xhci_free_dev(struct usb_hcd
+       struct xhci_slot_ctx *slot_ctx;
+       int i, ret;
+-#ifndef CONFIG_USB_DEFAULT_PERSIST
+       /*
+        * We called pm_runtime_get_noresume when the device was attached.
+        * Decrement the counter here to allow controller to runtime suspend
+@@ -3635,7 +3634,6 @@ static void xhci_free_dev(struct usb_hcd
+        */
+       if (xhci->quirks & XHCI_RESET_ON_RESUME)
+               pm_runtime_put_noidle(hcd->self.controller);
+-#endif
+       ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
+       /* If the host is halted due to driver unload, we still need to free the
+@@ -3790,14 +3788,12 @@ int xhci_alloc_dev(struct usb_hcd *hcd,
+       udev->slot_id = slot_id;
+-#ifndef CONFIG_USB_DEFAULT_PERSIST
+       /*
+        * If resetting upon resume, we can't put the controller into runtime
+        * suspend if there is a device attached.
+        */
+       if (xhci->quirks & XHCI_RESET_ON_RESUME)
+               pm_runtime_get_noresume(hcd->self.controller);
+-#endif
+       /* Is this a LS or FS device under a HS hub? */
+       /* Hub or peripherial? */