]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.14-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 23 Jan 2022 14:37:38 +0000 (15:37 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 23 Jan 2022 14:37:38 +0000 (15:37 +0100)
added patches:
can-softing_cs-softingcs_probe-fix-memleak-on-registration-failure.patch
iio-trigger-fix-a-scheduling-whilst-atomic-issue-seen-on-tsc2046.patch
media-cpia2-fix-control-message-timeouts.patch
media-dib0700-fix-undefined-behavior-in-tuner-shutdown.patch
media-em28xx-fix-control-message-timeouts.patch
media-flexcop-usb-fix-control-message-timeouts.patch
media-mceusb-fix-control-message-timeouts.patch
media-pvrusb2-fix-control-message-timeouts.patch
media-redrat3-fix-control-message-timeouts.patch
media-s2255-fix-control-message-timeouts.patch
media-stk1160-fix-control-message-timeouts.patch
nfc-llcp-fix-null-error-pointer-dereference-on-sendmsg-after-failed-bind.patch
pci-add-function-1-dma-alias-quirk-for-marvell-88se9125-sata-controller.patch
rtc-cmos-take-rtc_lock-while-reading-from-cmos.patch

15 files changed:
queue-4.14/can-softing_cs-softingcs_probe-fix-memleak-on-registration-failure.patch [new file with mode: 0644]
queue-4.14/iio-trigger-fix-a-scheduling-whilst-atomic-issue-seen-on-tsc2046.patch [new file with mode: 0644]
queue-4.14/media-cpia2-fix-control-message-timeouts.patch [new file with mode: 0644]
queue-4.14/media-dib0700-fix-undefined-behavior-in-tuner-shutdown.patch [new file with mode: 0644]
queue-4.14/media-em28xx-fix-control-message-timeouts.patch [new file with mode: 0644]
queue-4.14/media-flexcop-usb-fix-control-message-timeouts.patch [new file with mode: 0644]
queue-4.14/media-mceusb-fix-control-message-timeouts.patch [new file with mode: 0644]
queue-4.14/media-pvrusb2-fix-control-message-timeouts.patch [new file with mode: 0644]
queue-4.14/media-redrat3-fix-control-message-timeouts.patch [new file with mode: 0644]
queue-4.14/media-s2255-fix-control-message-timeouts.patch [new file with mode: 0644]
queue-4.14/media-stk1160-fix-control-message-timeouts.patch [new file with mode: 0644]
queue-4.14/nfc-llcp-fix-null-error-pointer-dereference-on-sendmsg-after-failed-bind.patch [new file with mode: 0644]
queue-4.14/pci-add-function-1-dma-alias-quirk-for-marvell-88se9125-sata-controller.patch [new file with mode: 0644]
queue-4.14/rtc-cmos-take-rtc_lock-while-reading-from-cmos.patch [new file with mode: 0644]
queue-4.14/series

diff --git a/queue-4.14/can-softing_cs-softingcs_probe-fix-memleak-on-registration-failure.patch b/queue-4.14/can-softing_cs-softingcs_probe-fix-memleak-on-registration-failure.patch
new file mode 100644 (file)
index 0000000..e9b0009
--- /dev/null
@@ -0,0 +1,36 @@
+From ced4913efb0acc844ed65cc01d091a85d83a2082 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Wed, 22 Dec 2021 11:48:43 +0100
+Subject: can: softing_cs: softingcs_probe(): fix memleak on registration failure
+
+From: Johan Hovold <johan@kernel.org>
+
+commit ced4913efb0acc844ed65cc01d091a85d83a2082 upstream.
+
+In case device registration fails during probe, the driver state and
+the embedded platform device structure needs to be freed using
+platform_device_put() to properly free all resources (e.g. the device
+name).
+
+Fixes: 0a0b7a5f7a04 ("can: add driver for Softing card")
+Link: https://lore.kernel.org/all/20211222104843.6105-1-johan@kernel.org
+Cc: stable@vger.kernel.org # 2.6.38
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/can/softing/softing_cs.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/can/softing/softing_cs.c
++++ b/drivers/net/can/softing/softing_cs.c
+@@ -304,7 +304,7 @@ static int softingcs_probe(struct pcmcia
+       return 0;
+ platform_failed:
+-      kfree(dev);
++      platform_device_put(pdev);
+ mem_failed:
+ pcmcia_bad:
+ pcmcia_failed:
diff --git a/queue-4.14/iio-trigger-fix-a-scheduling-whilst-atomic-issue-seen-on-tsc2046.patch b/queue-4.14/iio-trigger-fix-a-scheduling-whilst-atomic-issue-seen-on-tsc2046.patch
new file mode 100644 (file)
index 0000000..b35ac77
--- /dev/null
@@ -0,0 +1,121 @@
+From 9020ef659885f2622cfb386cc229b6d618362895 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Sun, 17 Oct 2021 18:22:09 +0100
+Subject: iio: trigger: Fix a scheduling whilst atomic issue seen on tsc2046
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 9020ef659885f2622cfb386cc229b6d618362895 upstream.
+
+IIO triggers are software IRQ chips that split an incoming IRQ into
+separate IRQs routed to all devices using the trigger.
+When all consumers are done then a trigger callback reenable() is
+called.  There are a few circumstances under which this can happen
+in atomic context.
+
+1) A single user of the trigger that calls the iio_trigger_done()
+function from interrupt context.
+2) A race between disconnecting the last device from a trigger and
+the trigger itself sucessfully being disabled.
+
+To avoid a resulting scheduling whilst atomic, close this second corner
+by using schedule_work() to ensure the reenable is not done in atomic
+context.
+
+Note that drivers must be careful to manage the interaction of
+set_state() and reenable() callbacks to ensure appropriate reference
+counting if they are relying on the same hardware controls.
+
+Deliberately taking this the slow path rather than via a fixes tree
+because the error has hard to hit and I would like it to soak for a while
+before hitting a release kernel.
+
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
+Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Tested-by: Oleksij Rempel <o.rempel@pengutronix.de>
+Cc: <Stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20211017172209.112387-1-jic23@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/industrialio-trigger.c |   36 +++++++++++++++++++++++++++++++++++-
+ include/linux/iio/trigger.h        |    2 ++
+ 2 files changed, 37 insertions(+), 1 deletion(-)
+
+--- a/drivers/iio/industrialio-trigger.c
++++ b/drivers/iio/industrialio-trigger.c
+@@ -163,6 +163,39 @@ static struct iio_trigger *iio_trigger_a
+       return trig;
+ }
++static void iio_reenable_work_fn(struct work_struct *work)
++{
++      struct iio_trigger *trig = container_of(work, struct iio_trigger,
++                                              reenable_work);
++
++      /*
++       * This 'might' occur after the trigger state is set to disabled -
++       * in that case the driver should skip reenabling.
++       */
++      trig->ops->reenable(trig);
++}
++
++/*
++ * In general, reenable callbacks may need to sleep and this path is
++ * not performance sensitive, so just queue up a work item
++ * to reneable the trigger for us.
++ *
++ * Races that can cause this.
++ * 1) A handler occurs entirely in interrupt context so the counter
++ *    the final decrement is still in this interrupt.
++ * 2) The trigger has been removed, but one last interrupt gets through.
++ *
++ * For (1) we must call reenable, but not in atomic context.
++ * For (2) it should be safe to call reenanble, if drivers never blindly
++ * reenable after state is off.
++ */
++static void iio_trigger_notify_done_atomic(struct iio_trigger *trig)
++{
++      if (atomic_dec_and_test(&trig->use_count) && trig->ops &&
++          trig->ops->reenable)
++              schedule_work(&trig->reenable_work);
++}
++
+ void iio_trigger_poll(struct iio_trigger *trig)
+ {
+       int i;
+@@ -174,7 +207,7 @@ void iio_trigger_poll(struct iio_trigger
+                       if (trig->subirqs[i].enabled)
+                               generic_handle_irq(trig->subirq_base + i);
+                       else
+-                              iio_trigger_notify_done(trig);
++                              iio_trigger_notify_done_atomic(trig);
+               }
+       }
+ }
+@@ -528,6 +561,7 @@ static struct iio_trigger *viio_trigger_
+       trig->dev.type = &iio_trig_type;
+       trig->dev.bus = &iio_bus_type;
+       device_initialize(&trig->dev);
++      INIT_WORK(&trig->reenable_work, iio_reenable_work_fn);
+       mutex_init(&trig->pool_lock);
+       trig->subirq_base = irq_alloc_descs(-1, 0,
+--- a/include/linux/iio/trigger.h
++++ b/include/linux/iio/trigger.h
+@@ -59,6 +59,7 @@ struct iio_trigger_ops {
+  * @attached_own_device:[INTERN] if we are using our own device as trigger,
+  *                    i.e. if we registered a poll function to the same
+  *                    device as the one providing the trigger.
++ * @reenable_work:    [INTERN] work item used to ensure reenable can sleep.
+  **/
+ struct iio_trigger {
+       const struct iio_trigger_ops    *ops;
+@@ -77,6 +78,7 @@ struct iio_trigger {
+       unsigned long pool[BITS_TO_LONGS(CONFIG_IIO_CONSUMERS_PER_TRIGGER)];
+       struct mutex                    pool_lock;
+       bool                            attached_own_device;
++      struct work_struct              reenable_work;
+ };
diff --git a/queue-4.14/media-cpia2-fix-control-message-timeouts.patch b/queue-4.14/media-cpia2-fix-control-message-timeouts.patch
new file mode 100644 (file)
index 0000000..182d8cb
--- /dev/null
@@ -0,0 +1,42 @@
+From 10729be03327f53258cb196362015ad5c6eabe02 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 25 Oct 2021 13:16:37 +0100
+Subject: media: cpia2: fix control-message timeouts
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 10729be03327f53258cb196362015ad5c6eabe02 upstream.
+
+USB control-message timeouts are specified in milliseconds and should
+specifically not vary with CONFIG_HZ.
+
+Fixes: ab33d5071de7 ("V4L/DVB (3376): Add cpia2 camera support")
+Cc: stable@vger.kernel.org      # 2.6.17
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/cpia2/cpia2_usb.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/usb/cpia2/cpia2_usb.c
++++ b/drivers/media/usb/cpia2/cpia2_usb.c
+@@ -559,7 +559,7 @@ static int write_packet(struct usb_devic
+                              0,       /* index */
+                              buf,     /* buffer */
+                              size,
+-                             HZ);
++                             1000);
+       kfree(buf);
+       return ret;
+@@ -591,7 +591,7 @@ static int read_packet(struct usb_device
+                              0,       /* index */
+                              buf,     /* buffer */
+                              size,
+-                             HZ);
++                             1000);
+       if (ret >= 0)
+               memcpy(registers, buf, size);
diff --git a/queue-4.14/media-dib0700-fix-undefined-behavior-in-tuner-shutdown.patch b/queue-4.14/media-dib0700-fix-undefined-behavior-in-tuner-shutdown.patch
new file mode 100644 (file)
index 0000000..0c1a467
--- /dev/null
@@ -0,0 +1,51 @@
+From f7b77ebe6d2f49c7747b2d619586d1aa33f9ea91 Mon Sep 17 00:00:00 2001
+From: Michael Kuron <michael.kuron@gmail.com>
+Date: Sun, 26 Sep 2021 21:51:26 +0100
+Subject: media: dib0700: fix undefined behavior in tuner shutdown
+
+From: Michael Kuron <michael.kuron@gmail.com>
+
+commit f7b77ebe6d2f49c7747b2d619586d1aa33f9ea91 upstream.
+
+This fixes a problem where closing the tuner would leave it in a state
+where it would not tune to any channel when reopened. This problem was
+discovered as part of https://github.com/hselasky/webcamd/issues/16.
+
+Since adap->id is 0 or 1, this bit-shift overflows, which is undefined
+behavior. The driver still worked in practice as the overflow would in
+most environments result in 0, which rendered the line a no-op. When
+running the driver as part of webcamd however, the overflow could lead
+to 0xff due to optimizations by the compiler, which would, in the end,
+improperly shut down the tuner.
+
+The bug is a regression introduced in the commit referenced below. The
+present patch causes identical behavior to before that commit for
+adap->id equal to 0 or 1. The driver does not contain support for
+dib0700 devices with more adapters, assuming such even exist.
+
+Tests have been performed with the Xbox One Digital TV Tuner on amd64.
+Not all dib0700 devices are expected to be affected by the regression;
+this code path is only taken by those with incorrect endpoint numbers.
+
+Link: https://lore.kernel.org/linux-media/1d2fc36d94ced6f67c7cc21dcc469d5e5bdd8201.1632689033.git.mchehab+huawei@kernel.org
+
+Cc: stable@vger.kernel.org
+Fixes: 7757ddda6f4f ("[media] DiB0700: add function to change I2C-speed")
+Signed-off-by: Michael Kuron <michael.kuron@gmail.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/dvb-usb/dib0700_core.c |    2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/media/usb/dvb-usb/dib0700_core.c
++++ b/drivers/media/usb/dvb-usb/dib0700_core.c
+@@ -619,8 +619,6 @@ int dib0700_streaming_ctrl(struct dvb_us
+               deb_info("the endpoint number (%i) is not correct, use the adapter id instead", adap->fe_adap[0].stream.props.endpoint);
+               if (onoff)
+                       st->channel_state |=    1 << (adap->id);
+-              else
+-                      st->channel_state |=    1 << ~(adap->id);
+       } else {
+               if (onoff)
+                       st->channel_state |=    1 << (adap->fe_adap[0].stream.props.endpoint-2);
diff --git a/queue-4.14/media-em28xx-fix-control-message-timeouts.patch b/queue-4.14/media-em28xx-fix-control-message-timeouts.patch
new file mode 100644 (file)
index 0000000..6f5ff1b
--- /dev/null
@@ -0,0 +1,42 @@
+From d9b7e8df3aa9b8c10708aab60e72e79ac08237e4 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 25 Oct 2021 13:16:38 +0100
+Subject: media: em28xx: fix control-message timeouts
+
+From: Johan Hovold <johan@kernel.org>
+
+commit d9b7e8df3aa9b8c10708aab60e72e79ac08237e4 upstream.
+
+USB control-message timeouts are specified in milliseconds and should
+specifically not vary with CONFIG_HZ.
+
+Fixes: a6c2ba283565 ("[PATCH] v4l: 716: support for em28xx board family")
+Cc: stable@vger.kernel.org      # 2.6.16
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/em28xx/em28xx-core.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/usb/em28xx/em28xx-core.c
++++ b/drivers/media/usb/em28xx/em28xx-core.c
+@@ -94,7 +94,7 @@ int em28xx_read_reg_req_len(struct em28x
+       mutex_lock(&dev->ctrl_urb_lock);
+       ret = usb_control_msg(udev, pipe, req,
+                             USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+-                            0x0000, reg, dev->urb_buf, len, HZ);
++                            0x0000, reg, dev->urb_buf, len, 1000);
+       if (ret < 0) {
+               em28xx_regdbg("(pipe 0x%08x): IN:  %02x %02x %02x %02x %02x %02x %02x %02x  failed with error %i\n",
+                            pipe, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+@@ -162,7 +162,7 @@ int em28xx_write_regs_req(struct em28xx
+       memcpy(dev->urb_buf, buf, len);
+       ret = usb_control_msg(udev, pipe, req,
+                             USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+-                            0x0000, reg, dev->urb_buf, len, HZ);
++                            0x0000, reg, dev->urb_buf, len, 1000);
+       mutex_unlock(&dev->ctrl_urb_lock);
+       if (ret < 0) {
diff --git a/queue-4.14/media-flexcop-usb-fix-control-message-timeouts.patch b/queue-4.14/media-flexcop-usb-fix-control-message-timeouts.patch
new file mode 100644 (file)
index 0000000..a6c8204
--- /dev/null
@@ -0,0 +1,95 @@
+From cd1798a387825cc4a51282f5a611ad05bb1ad75f Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 25 Oct 2021 13:16:36 +0100
+Subject: media: flexcop-usb: fix control-message timeouts
+
+From: Johan Hovold <johan@kernel.org>
+
+commit cd1798a387825cc4a51282f5a611ad05bb1ad75f upstream.
+
+USB control-message timeouts are specified in milliseconds and should
+specifically not vary with CONFIG_HZ.
+
+Note that the driver was multiplying some of the timeout values with HZ
+twice resulting in 3000-second timeouts with HZ=1000.
+
+Also note that two of the timeout defines are currently unused.
+
+Fixes: 2154be651b90 ("[media] redrat3: new rc-core IR transceiver device driver")
+Cc: stable@vger.kernel.org      # 3.0
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/b2c2/flexcop-usb.c |   10 +++++-----
+ drivers/media/usb/b2c2/flexcop-usb.h |   12 ++++++------
+ 2 files changed, 11 insertions(+), 11 deletions(-)
+
+--- a/drivers/media/usb/b2c2/flexcop-usb.c
++++ b/drivers/media/usb/b2c2/flexcop-usb.c
+@@ -86,7 +86,7 @@ static int flexcop_usb_readwrite_dw(stru
+                       0,
+                       fc_usb->data,
+                       sizeof(u32),
+-                      B2C2_WAIT_FOR_OPERATION_RDW * HZ);
++                      B2C2_WAIT_FOR_OPERATION_RDW);
+       if (ret != sizeof(u32)) {
+               err("error while %s dword from %d (%d).", read ? "reading" :
+@@ -154,7 +154,7 @@ static int flexcop_usb_v8_memory_req(str
+                       wIndex,
+                       fc_usb->data,
+                       buflen,
+-                      nWaitTime * HZ);
++                      nWaitTime);
+       if (ret != buflen)
+               ret = -EIO;
+@@ -248,13 +248,13 @@ static int flexcop_usb_i2c_req(struct fl
+               /* DKT 020208 - add this to support special case of DiSEqC */
+       case USB_FUNC_I2C_CHECKWRITE:
+               pipe = B2C2_USB_CTRL_PIPE_OUT;
+-              nWaitTime = 2;
++              nWaitTime = 2000;
+               request_type |= USB_DIR_OUT;
+               break;
+       case USB_FUNC_I2C_READ:
+       case USB_FUNC_I2C_REPEATREAD:
+               pipe = B2C2_USB_CTRL_PIPE_IN;
+-              nWaitTime = 2;
++              nWaitTime = 2000;
+               request_type |= USB_DIR_IN;
+               break;
+       default:
+@@ -281,7 +281,7 @@ static int flexcop_usb_i2c_req(struct fl
+                       wIndex,
+                       fc_usb->data,
+                       buflen,
+-                      nWaitTime * HZ);
++                      nWaitTime);
+       if (ret != buflen)
+               ret = -EIO;
+--- a/drivers/media/usb/b2c2/flexcop-usb.h
++++ b/drivers/media/usb/b2c2/flexcop-usb.h
+@@ -91,13 +91,13 @@ typedef enum {
+       UTILITY_SRAM_TESTVERIFY     = 0x16,
+ } flexcop_usb_utility_function_t;
+-#define B2C2_WAIT_FOR_OPERATION_RW (1*HZ)
+-#define B2C2_WAIT_FOR_OPERATION_RDW (3*HZ)
+-#define B2C2_WAIT_FOR_OPERATION_WDW (1*HZ)
++#define B2C2_WAIT_FOR_OPERATION_RW 1000
++#define B2C2_WAIT_FOR_OPERATION_RDW 3000
++#define B2C2_WAIT_FOR_OPERATION_WDW 1000
+-#define B2C2_WAIT_FOR_OPERATION_V8READ (3*HZ)
+-#define B2C2_WAIT_FOR_OPERATION_V8WRITE (3*HZ)
+-#define B2C2_WAIT_FOR_OPERATION_V8FLASH (3*HZ)
++#define B2C2_WAIT_FOR_OPERATION_V8READ 3000
++#define B2C2_WAIT_FOR_OPERATION_V8WRITE 3000
++#define B2C2_WAIT_FOR_OPERATION_V8FLASH 3000
+ typedef enum {
+       V8_MEMORY_PAGE_DVB_CI = 0x20,
diff --git a/queue-4.14/media-mceusb-fix-control-message-timeouts.patch b/queue-4.14/media-mceusb-fix-control-message-timeouts.patch
new file mode 100644 (file)
index 0000000..ba7ef01
--- /dev/null
@@ -0,0 +1,57 @@
+From 16394e998cbb050730536bdf7e89f5a70efbd974 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 25 Oct 2021 13:16:34 +0100
+Subject: media: mceusb: fix control-message timeouts
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 16394e998cbb050730536bdf7e89f5a70efbd974 upstream.
+
+USB control-message timeouts are specified in milliseconds and should
+specifically not vary with CONFIG_HZ.
+
+Fixes: 66e89522aff7 ("V4L/DVB: IR: add mceusb IR receiver driver")
+Cc: stable@vger.kernel.org      # 2.6.36
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/rc/mceusb.c |    8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/media/rc/mceusb.c
++++ b/drivers/media/rc/mceusb.c
+@@ -1124,7 +1124,7 @@ static void mceusb_gen1_init(struct mceu
+        */
+       ret = usb_control_msg(ir->usbdev, usb_rcvctrlpipe(ir->usbdev, 0),
+                             USB_REQ_SET_ADDRESS, USB_TYPE_VENDOR, 0, 0,
+-                            data, USB_CTRL_MSG_SZ, HZ * 3);
++                            data, USB_CTRL_MSG_SZ, 3000);
+       dev_dbg(dev, "set address - ret = %d", ret);
+       dev_dbg(dev, "set address - data[0] = %d, data[1] = %d",
+                                               data[0], data[1]);
+@@ -1132,20 +1132,20 @@ static void mceusb_gen1_init(struct mceu
+       /* set feature: bit rate 38400 bps */
+       ret = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0),
+                             USB_REQ_SET_FEATURE, USB_TYPE_VENDOR,
+-                            0xc04e, 0x0000, NULL, 0, HZ * 3);
++                            0xc04e, 0x0000, NULL, 0, 3000);
+       dev_dbg(dev, "set feature - ret = %d", ret);
+       /* bRequest 4: set char length to 8 bits */
+       ret = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0),
+                             4, USB_TYPE_VENDOR,
+-                            0x0808, 0x0000, NULL, 0, HZ * 3);
++                            0x0808, 0x0000, NULL, 0, 3000);
+       dev_dbg(dev, "set char length - retB = %d", ret);
+       /* bRequest 2: set handshaking to use DTR/DSR */
+       ret = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0),
+                             2, USB_TYPE_VENDOR,
+-                            0x0000, 0x0100, NULL, 0, HZ * 3);
++                            0x0000, 0x0100, NULL, 0, 3000);
+       dev_dbg(dev, "set handshake  - retC = %d", ret);
+       /* device resume */
diff --git a/queue-4.14/media-pvrusb2-fix-control-message-timeouts.patch b/queue-4.14/media-pvrusb2-fix-control-message-timeouts.patch
new file mode 100644 (file)
index 0000000..2a084be
--- /dev/null
@@ -0,0 +1,60 @@
+From b82bf9b9dc305d7d3d93eab106d70dbf2171b43e Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 25 Oct 2021 13:16:39 +0100
+Subject: media: pvrusb2: fix control-message timeouts
+
+From: Johan Hovold <johan@kernel.org>
+
+commit b82bf9b9dc305d7d3d93eab106d70dbf2171b43e upstream.
+
+USB control-message timeouts are specified in milliseconds and should
+specifically not vary with CONFIG_HZ.
+
+Fixes: d855497edbfb ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18")
+Cc: stable@vger.kernel.org      # 2.6.18
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/pvrusb2/pvrusb2-hdw.c |    8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
++++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+@@ -1476,7 +1476,7 @@ static int pvr2_upload_firmware1(struct
+       for (address = 0; address < fwsize; address += 0x800) {
+               memcpy(fw_ptr, fw_entry->data + address, 0x800);
+               ret += usb_control_msg(hdw->usb_dev, pipe, 0xa0, 0x40, address,
+-                                     0, fw_ptr, 0x800, HZ);
++                                     0, fw_ptr, 0x800, 1000);
+       }
+       trace_firmware("Upload done, releasing device's CPU");
+@@ -1614,7 +1614,7 @@ int pvr2_upload_firmware2(struct pvr2_hd
+                       ((u32 *)fw_ptr)[icnt] = swab32(((u32 *)fw_ptr)[icnt]);
+               ret |= usb_bulk_msg(hdw->usb_dev, pipe, fw_ptr,bcnt,
+-                                  &actual_length, HZ);
++                                  &actual_length, 1000);
+               ret |= (actual_length != bcnt);
+               if (ret) break;
+               fw_done += bcnt;
+@@ -3433,7 +3433,7 @@ void pvr2_hdw_cpufw_set_enabled(struct p
+                                                     0xa0,0xc0,
+                                                     address,0,
+                                                     hdw->fw_buffer+address,
+-                                                    0x800,HZ);
++                                                    0x800,1000);
+                               if (ret < 0) break;
+                       }
+@@ -3961,7 +3961,7 @@ void pvr2_hdw_cpureset_assert(struct pvr
+       /* Write the CPUCS register on the 8051.  The lsb of the register
+          is the reset bit; a 1 asserts reset while a 0 clears it. */
+       pipe = usb_sndctrlpipe(hdw->usb_dev, 0);
+-      ret = usb_control_msg(hdw->usb_dev,pipe,0xa0,0x40,0xe600,0,da,1,HZ);
++      ret = usb_control_msg(hdw->usb_dev,pipe,0xa0,0x40,0xe600,0,da,1,1000);
+       if (ret < 0) {
+               pvr2_trace(PVR2_TRACE_ERROR_LEGS,
+                          "cpureset_assert(%d) error=%d",val,ret);
diff --git a/queue-4.14/media-redrat3-fix-control-message-timeouts.patch b/queue-4.14/media-redrat3-fix-control-message-timeouts.patch
new file mode 100644 (file)
index 0000000..5254c90
--- /dev/null
@@ -0,0 +1,115 @@
+From 2adc965c8bfa224e11ecccf9c92fd458c4236428 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 25 Oct 2021 13:16:35 +0100
+Subject: media: redrat3: fix control-message timeouts
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 2adc965c8bfa224e11ecccf9c92fd458c4236428 upstream.
+
+USB control-message timeouts are specified in milliseconds and should
+specifically not vary with CONFIG_HZ.
+
+Fixes: 2154be651b90 ("[media] redrat3: new rc-core IR transceiver device driver")
+Cc: stable@vger.kernel.org      # 3.0
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/rc/redrat3.c |   22 +++++++++++-----------
+ 1 file changed, 11 insertions(+), 11 deletions(-)
+
+--- a/drivers/media/rc/redrat3.c
++++ b/drivers/media/rc/redrat3.c
+@@ -415,7 +415,7 @@ static int redrat3_send_cmd(int cmd, str
+       udev = rr3->udev;
+       res = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), cmd,
+                             USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
+-                            0x0000, 0x0000, data, sizeof(u8), HZ * 10);
++                            0x0000, 0x0000, data, sizeof(u8), 10000);
+       if (res < 0) {
+               dev_err(rr3->dev, "%s: Error sending rr3 cmd res %d, data %d",
+@@ -491,7 +491,7 @@ static u32 redrat3_get_timeout(struct re
+       pipe = usb_rcvctrlpipe(rr3->udev, 0);
+       ret = usb_control_msg(rr3->udev, pipe, RR3_GET_IR_PARAM,
+                             USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
+-                            RR3_IR_IO_SIG_TIMEOUT, 0, tmp, len, HZ * 5);
++                            RR3_IR_IO_SIG_TIMEOUT, 0, tmp, len, 5000);
+       if (ret != len)
+               dev_warn(rr3->dev, "Failed to read timeout from hardware\n");
+       else {
+@@ -521,7 +521,7 @@ static int redrat3_set_timeout(struct rc
+       ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), RR3_SET_IR_PARAM,
+                    USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+                    RR3_IR_IO_SIG_TIMEOUT, 0, timeout, sizeof(*timeout),
+-                   HZ * 25);
++                   25000);
+       dev_dbg(dev, "set ir parm timeout %d ret 0x%02x\n",
+                                               be32_to_cpu(*timeout), ret);
+@@ -553,32 +553,32 @@ static void redrat3_reset(struct redrat3
+       *val = 0x01;
+       rc = usb_control_msg(udev, rxpipe, RR3_RESET,
+                            USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
+-                           RR3_CPUCS_REG_ADDR, 0, val, len, HZ * 25);
++                           RR3_CPUCS_REG_ADDR, 0, val, len, 25000);
+       dev_dbg(dev, "reset returned 0x%02x\n", rc);
+       *val = length_fuzz;
+       rc = usb_control_msg(udev, txpipe, RR3_SET_IR_PARAM,
+                            USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+-                           RR3_IR_IO_LENGTH_FUZZ, 0, val, len, HZ * 25);
++                           RR3_IR_IO_LENGTH_FUZZ, 0, val, len, 25000);
+       dev_dbg(dev, "set ir parm len fuzz %d rc 0x%02x\n", *val, rc);
+       *val = (65536 - (minimum_pause * 2000)) / 256;
+       rc = usb_control_msg(udev, txpipe, RR3_SET_IR_PARAM,
+                            USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+-                           RR3_IR_IO_MIN_PAUSE, 0, val, len, HZ * 25);
++                           RR3_IR_IO_MIN_PAUSE, 0, val, len, 25000);
+       dev_dbg(dev, "set ir parm min pause %d rc 0x%02x\n", *val, rc);
+       *val = periods_measure_carrier;
+       rc = usb_control_msg(udev, txpipe, RR3_SET_IR_PARAM,
+                            USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+-                           RR3_IR_IO_PERIODS_MF, 0, val, len, HZ * 25);
++                           RR3_IR_IO_PERIODS_MF, 0, val, len, 25000);
+       dev_dbg(dev, "set ir parm periods measure carrier %d rc 0x%02x", *val,
+                                                                       rc);
+       *val = RR3_DRIVER_MAXLENS;
+       rc = usb_control_msg(udev, txpipe, RR3_SET_IR_PARAM,
+                            USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+-                           RR3_IR_IO_MAX_LENGTHS, 0, val, len, HZ * 25);
++                           RR3_IR_IO_MAX_LENGTHS, 0, val, len, 25000);
+       dev_dbg(dev, "set ir parm max lens %d rc 0x%02x\n", *val, rc);
+       kfree(val);
+@@ -596,7 +596,7 @@ static void redrat3_get_firmware_rev(str
+       rc = usb_control_msg(rr3->udev, usb_rcvctrlpipe(rr3->udev, 0),
+                            RR3_FW_VERSION,
+                            USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
+-                           0, 0, buffer, RR3_FW_VERSION_LEN, HZ * 5);
++                           0, 0, buffer, RR3_FW_VERSION_LEN, 5000);
+       if (rc >= 0)
+               dev_info(rr3->dev, "Firmware rev: %s", buffer);
+@@ -836,14 +836,14 @@ static int redrat3_transmit_ir(struct rc
+       pipe = usb_sndbulkpipe(rr3->udev, rr3->ep_out->bEndpointAddress);
+       ret = usb_bulk_msg(rr3->udev, pipe, irdata,
+-                          sendbuf_len, &ret_len, 10 * HZ);
++                          sendbuf_len, &ret_len, 10000);
+       dev_dbg(dev, "sent %d bytes, (ret %d)\n", ret_len, ret);
+       /* now tell the hardware to transmit what we sent it */
+       pipe = usb_rcvctrlpipe(rr3->udev, 0);
+       ret = usb_control_msg(rr3->udev, pipe, RR3_TX_SEND_SIGNAL,
+                             USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
+-                            0, 0, irdata, 2, HZ * 10);
++                            0, 0, irdata, 2, 10000);
+       if (ret < 0)
+               dev_err(dev, "Error: control msg send failed, rc %d\n", ret);
diff --git a/queue-4.14/media-s2255-fix-control-message-timeouts.patch b/queue-4.14/media-s2255-fix-control-message-timeouts.patch
new file mode 100644 (file)
index 0000000..767c58a
--- /dev/null
@@ -0,0 +1,45 @@
+From f71d272ad4e354097020a4e6b1dc6e4b59feb50f Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 25 Oct 2021 13:16:40 +0100
+Subject: media: s2255: fix control-message timeouts
+
+From: Johan Hovold <johan@kernel.org>
+
+commit f71d272ad4e354097020a4e6b1dc6e4b59feb50f upstream.
+
+USB control-message timeouts are specified in milliseconds and should
+specifically not vary with CONFIG_HZ.
+
+Use the common control-message timeout define for the five-second
+timeouts.
+
+Fixes: 38f993ad8b1f ("V4L/DVB (8125): This driver adds support for the Sensoray 2255 devices.")
+Cc: stable@vger.kernel.org      # 2.6.27
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/s2255/s2255drv.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/usb/s2255/s2255drv.c
++++ b/drivers/media/usb/s2255/s2255drv.c
+@@ -1911,7 +1911,7 @@ static long s2255_vendor_req(struct s225
+                                   USB_TYPE_VENDOR | USB_RECIP_DEVICE |
+                                   USB_DIR_IN,
+                                   Value, Index, buf,
+-                                  TransferBufferLength, HZ * 5);
++                                  TransferBufferLength, USB_CTRL_SET_TIMEOUT);
+               if (r >= 0)
+                       memcpy(TransferBuffer, buf, TransferBufferLength);
+@@ -1920,7 +1920,7 @@ static long s2255_vendor_req(struct s225
+               r = usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0),
+                                   Request, USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+                                   Value, Index, buf,
+-                                  TransferBufferLength, HZ * 5);
++                                  TransferBufferLength, USB_CTRL_SET_TIMEOUT);
+       }
+       kfree(buf);
+       return r;
diff --git a/queue-4.14/media-stk1160-fix-control-message-timeouts.patch b/queue-4.14/media-stk1160-fix-control-message-timeouts.patch
new file mode 100644 (file)
index 0000000..af746dc
--- /dev/null
@@ -0,0 +1,42 @@
+From 6aa6e70cdb5b863a57bad61310bf89b6617a5d2d Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 25 Oct 2021 13:16:41 +0100
+Subject: media: stk1160: fix control-message timeouts
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 6aa6e70cdb5b863a57bad61310bf89b6617a5d2d upstream.
+
+USB control-message timeouts are specified in milliseconds and should
+specifically not vary with CONFIG_HZ.
+
+Fixes: 9cb2173e6ea8 ("[media] media: Add stk1160 new driver (easycap replacement)")
+Cc: stable@vger.kernel.org      # 3.7
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/stk1160/stk1160-core.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/usb/stk1160/stk1160-core.c
++++ b/drivers/media/usb/stk1160/stk1160-core.c
+@@ -75,7 +75,7 @@ int stk1160_read_reg(struct stk1160 *dev
+               return -ENOMEM;
+       ret = usb_control_msg(dev->udev, pipe, 0x00,
+                       USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+-                      0x00, reg, buf, sizeof(u8), HZ);
++                      0x00, reg, buf, sizeof(u8), 1000);
+       if (ret < 0) {
+               stk1160_err("read failed on reg 0x%x (%d)\n",
+                       reg, ret);
+@@ -95,7 +95,7 @@ int stk1160_write_reg(struct stk1160 *de
+       ret =  usb_control_msg(dev->udev, pipe, 0x01,
+                       USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+-                      value, reg, NULL, 0, HZ);
++                      value, reg, NULL, 0, 1000);
+       if (ret < 0) {
+               stk1160_err("write failed on reg 0x%x (%d)\n",
+                       reg, ret);
diff --git a/queue-4.14/nfc-llcp-fix-null-error-pointer-dereference-on-sendmsg-after-failed-bind.patch b/queue-4.14/nfc-llcp-fix-null-error-pointer-dereference-on-sendmsg-after-failed-bind.patch
new file mode 100644 (file)
index 0000000..6c2e0e7
--- /dev/null
@@ -0,0 +1,102 @@
+From dded08927ca3c31a5c37f8e7f95fe98770475dd4 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
+Date: Wed, 19 Jan 2022 08:48:16 +0100
+Subject: nfc: llcp: fix NULL error pointer dereference on sendmsg() after failed bind()
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
+
+commit dded08927ca3c31a5c37f8e7f95fe98770475dd4 upstream.
+
+Syzbot detected a NULL pointer dereference of nfc_llcp_sock->dev pointer
+(which is a 'struct nfc_dev *') with calls to llcp_sock_sendmsg() after
+a failed llcp_sock_bind(). The message being sent is a SOCK_DGRAM.
+
+KASAN report:
+
+  BUG: KASAN: null-ptr-deref in nfc_alloc_send_skb+0x2d/0xc0
+  Read of size 4 at addr 00000000000005c8 by task llcp_sock_nfc_a/899
+
+  CPU: 5 PID: 899 Comm: llcp_sock_nfc_a Not tainted 5.16.0-rc6-next-20211224-00001-gc6437fbf18b0 #125
+  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
+  Call Trace:
+   <TASK>
+   dump_stack_lvl+0x45/0x59
+   ? nfc_alloc_send_skb+0x2d/0xc0
+   __kasan_report.cold+0x117/0x11c
+   ? mark_lock+0x480/0x4f0
+   ? nfc_alloc_send_skb+0x2d/0xc0
+   kasan_report+0x38/0x50
+   nfc_alloc_send_skb+0x2d/0xc0
+   nfc_llcp_send_ui_frame+0x18c/0x2a0
+   ? nfc_llcp_send_i_frame+0x230/0x230
+   ? __local_bh_enable_ip+0x86/0xe0
+   ? llcp_sock_connect+0x470/0x470
+   ? llcp_sock_connect+0x470/0x470
+   sock_sendmsg+0x8e/0xa0
+   ____sys_sendmsg+0x253/0x3f0
+   ...
+
+The issue was visible only with multiple simultaneous calls to bind() and
+sendmsg(), which resulted in most of the bind() calls to fail.  The
+bind() was failing on checking if there is available WKS/SDP/SAP
+(respective bit in 'struct nfc_llcp_local' fields).  When there was no
+available WKS/SDP/SAP, the bind returned error but the sendmsg() to such
+socket was able to trigger mentioned NULL pointer dereference of
+nfc_llcp_sock->dev.
+
+The code looks simply racy and currently it protects several paths
+against race with checks for (!nfc_llcp_sock->local) which is NULL-ified
+in error paths of bind().  The llcp_sock_sendmsg() did not have such
+check but called function nfc_llcp_send_ui_frame() had, although not
+protected with lock_sock().
+
+Therefore the race could look like (same socket is used all the time):
+  CPU0                                     CPU1
+  ====                                     ====
+  llcp_sock_bind()
+  - lock_sock()
+    - success
+  - release_sock()
+  - return 0
+                                           llcp_sock_sendmsg()
+                                           - lock_sock()
+                                           - release_sock()
+  llcp_sock_bind(), same socket
+  - lock_sock()
+    - error
+                                           - nfc_llcp_send_ui_frame()
+                                             - if (!llcp_sock->local)
+    - llcp_sock->local = NULL
+    - nfc_put_device(dev)
+                                             - dereference llcp_sock->dev
+  - release_sock()
+  - return -ERRNO
+
+The nfc_llcp_send_ui_frame() checked llcp_sock->local outside of the
+lock, which is racy and ineffective check.  Instead, its caller
+llcp_sock_sendmsg(), should perform the check inside lock_sock().
+
+Reported-and-tested-by: syzbot+7f23bcddf626e0593a39@syzkaller.appspotmail.com
+Fixes: b874dec21d1c ("NFC: Implement LLCP connection less Tx path")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/nfc/llcp_sock.c |    5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/net/nfc/llcp_sock.c
++++ b/net/nfc/llcp_sock.c
+@@ -797,6 +797,11 @@ static int llcp_sock_sendmsg(struct sock
+       lock_sock(sk);
++      if (!llcp_sock->local) {
++              release_sock(sk);
++              return -ENODEV;
++      }
++
+       if (sk->sk_type == SOCK_DGRAM) {
+               DECLARE_SOCKADDR(struct sockaddr_nfc_llcp *, addr,
+                                msg->msg_name);
diff --git a/queue-4.14/pci-add-function-1-dma-alias-quirk-for-marvell-88se9125-sata-controller.patch b/queue-4.14/pci-add-function-1-dma-alias-quirk-for-marvell-88se9125-sata-controller.patch
new file mode 100644 (file)
index 0000000..2ea1a67
--- /dev/null
@@ -0,0 +1,57 @@
+From e445375882883f69018aa669b67cbb37ec873406 Mon Sep 17 00:00:00 2001
+From: Yifeng Li <tomli@tomli.me>
+Date: Thu, 2 Dec 2021 06:35:21 +0000
+Subject: PCI: Add function 1 DMA alias quirk for Marvell 88SE9125 SATA controller
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Yifeng Li <tomli@tomli.me>
+
+commit e445375882883f69018aa669b67cbb37ec873406 upstream.
+
+Like other SATA controller chips in the Marvell 88SE91xx series, the
+Marvell 88SE9125 has the same DMA requester ID hardware bug that prevents
+it from working under IOMMU.  Add it to the list of devices that need the
+quirk.
+
+Without this patch, device initialization fails with DMA errors:
+
+  ata8: softreset failed (1st FIS failed)
+  DMAR: DRHD: handling fault status reg 2
+  DMAR: [DMA Write NO_PASID] Request device [03:00.1] fault addr 0xfffc0000 [fault reason 0x02] Present bit in context entry is clear
+  DMAR: DRHD: handling fault status reg 2
+  DMAR: [DMA Read NO_PASID] Request device [03:00.1] fault addr 0xfffc0000 [fault reason 0x02] Present bit in context entry is clear
+
+After applying the patch, the controller can be successfully initialized:
+
+  ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 330)
+  ata8.00: ATAPI: PIONEER BD-RW   BDR-207M, 1.21, max UDMA/100
+  ata8.00: configured for UDMA/100
+  scsi 7:0:0:0: CD-ROM            PIONEER  BD-RW   BDR-207M 1.21 PQ: 0 ANSI: 5
+
+Link: https://lore.kernel.org/r/YahpKVR+McJVDdkD@work
+Reported-by: Sam Bingner <sam@bingner.com>
+Tested-by: Sam Bingner <sam@bingner.com>
+Tested-by: Yifeng Li <tomli@tomli.me>
+Signed-off-by: Yifeng Li <tomli@tomli.me>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/quirks.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -4004,6 +4004,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_M
+                        quirk_dma_func1_alias);
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9123,
+                        quirk_dma_func1_alias);
++/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c136 */
++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9125,
++                       quirk_dma_func1_alias);
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9128,
+                        quirk_dma_func1_alias);
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c14 */
diff --git a/queue-4.14/rtc-cmos-take-rtc_lock-while-reading-from-cmos.patch b/queue-4.14/rtc-cmos-take-rtc_lock-while-reading-from-cmos.patch
new file mode 100644 (file)
index 0000000..0510f45
--- /dev/null
@@ -0,0 +1,49 @@
+From 454f47ff464325223129b9b5b8d0b61946ec704d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= <mat.jonczyk@o2.pl>
+Date: Fri, 10 Dec 2021 21:01:23 +0100
+Subject: rtc: cmos: take rtc_lock while reading from CMOS
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mateusz Jończyk <mat.jonczyk@o2.pl>
+
+commit 454f47ff464325223129b9b5b8d0b61946ec704d upstream.
+
+Reading from the CMOS involves writing to the index register and then
+reading from the data register. Therefore access to the CMOS has to be
+serialized with rtc_lock. This invocation of CMOS_READ was not
+serialized, which could cause trouble when other code is accessing CMOS
+at the same time.
+
+Use spin_lock_irq() like the rest of the function.
+
+Nothing in kernel modifies the RTC_DM_BINARY bit, so there could be a
+separate pair of spin_lock_irq() / spin_unlock_irq() before doing the
+math.
+
+Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
+Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+Cc: Alessandro Zummo <a.zummo@towertech.it>
+Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Link: https://lore.kernel.org/r/20211210200131.153887-2-mat.jonczyk@o2.pl
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/rtc/rtc-cmos.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/rtc/rtc-cmos.c
++++ b/drivers/rtc/rtc-cmos.c
+@@ -421,7 +421,10 @@ static int cmos_set_alarm(struct device
+       min = t->time.tm_min;
+       sec = t->time.tm_sec;
++      spin_lock_irq(&rtc_lock);
+       rtc_control = CMOS_READ(RTC_CONTROL);
++      spin_unlock_irq(&rtc_lock);
++
+       if (!(rtc_control & RTC_DM_BINARY) || RTC_ALWAYS_BCD) {
+               /* Writing 0xff means "don't care" or "match all".  */
+               mon = (mon <= 12) ? bin2bcd(mon) : 0xff;
index bf54c7535f5dca948a52b103c46432b00e1bbe93..8715a7391df741e9b1f53a1df406285b12b448ca 100644 (file)
@@ -16,3 +16,17 @@ bluetooth-fix-init-and-cleanup-of-sco_conn.timeout_work.patch
 hid-uhid-fix-worker-destroying-device-without-any-protection.patch
 hid-wacom-ignore-the-confidence-flag-when-a-touch-is-removed.patch
 hid-wacom-avoid-using-stale-array-indicies-to-read-contact-count.patch
+nfc-llcp-fix-null-error-pointer-dereference-on-sendmsg-after-failed-bind.patch
+rtc-cmos-take-rtc_lock-while-reading-from-cmos.patch
+media-flexcop-usb-fix-control-message-timeouts.patch
+media-mceusb-fix-control-message-timeouts.patch
+media-em28xx-fix-control-message-timeouts.patch
+media-cpia2-fix-control-message-timeouts.patch
+media-s2255-fix-control-message-timeouts.patch
+media-dib0700-fix-undefined-behavior-in-tuner-shutdown.patch
+media-redrat3-fix-control-message-timeouts.patch
+media-pvrusb2-fix-control-message-timeouts.patch
+media-stk1160-fix-control-message-timeouts.patch
+can-softing_cs-softingcs_probe-fix-memleak-on-registration-failure.patch
+iio-trigger-fix-a-scheduling-whilst-atomic-issue-seen-on-tsc2046.patch
+pci-add-function-1-dma-alias-quirk-for-marvell-88se9125-sata-controller.patch