--- /dev/null
+From 15c0a870dc44ed14e01efbdd319d232234ee639f Mon Sep 17 00:00:00 2001
+From: Xiubo Li <xiubli@redhat.com>
+Date: Wed, 6 Sep 2023 14:22:07 +0800
+Subject: ceph: fix incorrect revoked caps assert in ceph_fill_file_size()
+
+From: Xiubo Li <xiubli@redhat.com>
+
+commit 15c0a870dc44ed14e01efbdd319d232234ee639f upstream.
+
+When truncating the inode the MDS will acquire the xlock for the
+ifile Locker, which will revoke the 'Frwsxl' caps from the clients.
+But when the client just releases and flushes the 'Fw' caps to MDS,
+for exmaple, and once the MDS receives the caps flushing msg it
+just thought the revocation has finished. Then the MDS will continue
+truncating the inode and then issued the truncate notification to
+all the clients. While just before the clients receives the cap
+flushing ack they receive the truncation notification, the clients
+will detecte that the 'issued | dirty' is still holding the 'Fw'
+caps.
+
+Cc: stable@vger.kernel.org
+Link: https://tracker.ceph.com/issues/56693
+Fixes: b0d7c2231015 ("ceph: introduce i_truncate_mutex")
+Signed-off-by: Xiubo Li <xiubli@redhat.com>
+Reviewed-by: Milind Changire <mchangir@redhat.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/inode.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/fs/ceph/inode.c
++++ b/fs/ceph/inode.c
+@@ -619,9 +619,7 @@ int ceph_fill_file_size(struct inode *in
+ ci->i_truncate_seq = truncate_seq;
+
+ /* the MDS should have revoked these caps */
+- WARN_ON_ONCE(issued & (CEPH_CAP_FILE_EXCL |
+- CEPH_CAP_FILE_RD |
+- CEPH_CAP_FILE_WR |
++ WARN_ON_ONCE(issued & (CEPH_CAP_FILE_RD |
+ CEPH_CAP_FILE_LAZYIO));
+ /*
+ * If we hold relevant caps, or in the case where we're
--- /dev/null
+From 1ca0b605150501b7dc59f3016271da4eb3e96fce Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Michal=20Koutn=C3=BD?= <mkoutny@suse.com>
+Date: Mon, 9 Oct 2023 15:58:11 +0200
+Subject: cgroup: Remove duplicates in cgroup v1 tasks file
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Michal Koutný <mkoutny@suse.com>
+
+commit 1ca0b605150501b7dc59f3016271da4eb3e96fce upstream.
+
+One PID may appear multiple times in a preloaded pidlist.
+(Possibly due to PID recycling but we have reports of the same
+task_struct appearing with different PIDs, thus possibly involving
+transfer of PID via de_thread().)
+
+Because v1 seq_file iterator uses PIDs as position, it leads to
+a message:
+> seq_file: buggy .next function kernfs_seq_next did not update position index
+
+Conservative and quick fix consists of removing duplicates from `tasks`
+file (as opposed to removing pidlists altogether). It doesn't affect
+correctness (it's sufficient to show a PID once), performance impact
+would be hidden by unconditional sorting of the pidlist already in place
+(asymptotically).
+
+Link: https://lore.kernel.org/r/20230823174804.23632-1-mkoutny@suse.com/
+Suggested-by: Firo Yang <firo.yang@suse.com>
+Signed-off-by: Michal Koutný <mkoutny@suse.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/cgroup/cgroup-v1.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/kernel/cgroup/cgroup-v1.c
++++ b/kernel/cgroup/cgroup-v1.c
+@@ -367,10 +367,9 @@ static int pidlist_array_load(struct cgr
+ }
+ css_task_iter_end(&it);
+ length = n;
+- /* now sort & (if procs) strip out duplicates */
++ /* now sort & strip out duplicates (tgids or recycled thread PIDs) */
+ sort(array, length, sizeof(pid_t), cmppid, NULL);
+- if (type == CGROUP_FILE_PROCS)
+- length = pidlist_uniq(array, length);
++ length = pidlist_uniq(array, length);
+
+ l = cgroup_pidlist_find_create(cgrp, type);
+ if (!l) {
--- /dev/null
+From 81337b9a72dc58a5fa0ae8a042e8cb59f9bdec4a Mon Sep 17 00:00:00 2001
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Date: Wed, 4 Oct 2023 18:35:28 +0200
+Subject: dmaengine: stm32-mdma: abort resume if no ongoing transfer
+
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+
+commit 81337b9a72dc58a5fa0ae8a042e8cb59f9bdec4a upstream.
+
+chan->desc can be null, if transfer is terminated when resume is called,
+leading to a NULL pointer when retrieving the hwdesc.
+To avoid this case, check that chan->desc is not null and channel is
+disabled (transfer previously paused or terminated).
+
+Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver")
+Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20231004163531.2864160-1-amelie.delaunay@foss.st.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/stm32-mdma.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/dma/stm32-mdma.c
++++ b/drivers/dma/stm32-mdma.c
+@@ -1207,6 +1207,10 @@ static int stm32_mdma_resume(struct dma_
+ unsigned long flags;
+ u32 status, reg;
+
++ /* Transfer can be terminated */
++ if (!chan->desc || (stm32_mdma_read(dmadev, STM32_MDMA_CCR(chan->id)) & STM32_MDMA_CCR_EN))
++ return -EPERM;
++
+ hwdesc = chan->desc->node[chan->curr_hwdesc].hwdesc;
+
+ spin_lock_irqsave(&chan->vchan.lock, flags);
--- /dev/null
+From 85dfb43bf69281adb1f345dfd9a39faf2e5a718d Mon Sep 17 00:00:00 2001
+From: Phil Elwell <phil@raspberrypi.com>
+Date: Fri, 11 Aug 2023 16:58:29 +0100
+Subject: iio: pressure: bmp280: Fix NULL pointer exception
+
+From: Phil Elwell <phil@raspberrypi.com>
+
+commit 85dfb43bf69281adb1f345dfd9a39faf2e5a718d upstream.
+
+The bmp085 EOC IRQ support is optional, but the driver's common probe
+function queries the IRQ properties whether or not it exists, which
+can trigger a NULL pointer exception. Avoid any exception by making
+the query conditional on the possession of a valid IRQ.
+
+Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt")
+Signed-off-by: Phil Elwell <phil@raspberrypi.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/20230811155829.51208-1-phil@raspberrypi.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/pressure/bmp280-core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/pressure/bmp280-core.c
++++ b/drivers/iio/pressure/bmp280-core.c
+@@ -1113,7 +1113,7 @@ int bmp280_common_probe(struct device *d
+ * however as it happens, the BMP085 shares the chip ID of BMP180
+ * so we look for an IRQ if we have that.
+ */
+- if (irq > 0 || (chip_id == BMP180_CHIP_ID)) {
++ if (irq > 0 && (chip_id == BMP180_CHIP_ID)) {
+ ret = bmp085_fetch_eoc_irq(dev, name, irq, data);
+ if (ret)
+ goto out_disable_vdda;
--- /dev/null
+From 901a293fd96fb9bab843ba4cc7be3094a5aa7c94 Mon Sep 17 00:00:00 2001
+From: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
+Date: Tue, 29 Aug 2023 13:02:22 -0500
+Subject: iio: pressure: dps310: Adjust Timeout Settings
+
+From: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
+
+commit 901a293fd96fb9bab843ba4cc7be3094a5aa7c94 upstream.
+
+The DPS310 sensor chip has been encountering intermittent errors while
+reading the sensor device across various system designs. This issue causes
+the chip to become "stuck," preventing the indication of "ready" status
+for pressure and temperature measurements in the MEAS_CFG register.
+
+To address this issue, this commit fixes the timeout settings to improve
+sensor stability:
+- After sending a reset command to the chip, the timeout has been extended
+ from 2.5 ms to 15 ms, aligning with the DPS310 specification.
+- The read timeout value of the MEAS_CFG register has been adjusted from
+ 20ms to 30ms to match the specification.
+
+Signed-off-by: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
+Fixes: 7b4ab4abcea4 ("iio: pressure: dps310: Reset chip after timeout")
+Link: https://lore.kernel.org/r/20230829180222.3431926-2-lakshmiy@us.ibm.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/pressure/dps310.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/pressure/dps310.c
++++ b/drivers/iio/pressure/dps310.c
+@@ -57,8 +57,8 @@
+ #define DPS310_RESET_MAGIC 0x09
+ #define DPS310_COEF_BASE 0x10
+
+-/* Make sure sleep time is <= 20ms for usleep_range */
+-#define DPS310_POLL_SLEEP_US(t) min(20000, (t) / 8)
++/* Make sure sleep time is <= 30ms for usleep_range */
++#define DPS310_POLL_SLEEP_US(t) min(30000, (t) / 8)
+ /* Silently handle error in rate value here */
+ #define DPS310_POLL_TIMEOUT_US(rc) ((rc) <= 0 ? 1000000 : 1000000 / (rc))
+
+@@ -402,8 +402,8 @@ static int dps310_reset_wait(struct dps3
+ if (rc)
+ return rc;
+
+- /* Wait for device chip access: 2.5ms in specification */
+- usleep_range(2500, 12000);
++ /* Wait for device chip access: 15ms in specification */
++ usleep_range(15000, 55000);
+ return 0;
+ }
+
--- /dev/null
+From fd39d9668f2ce9f4b05ad55e8c8d80c098073e0b Mon Sep 17 00:00:00 2001
+From: Alexander Zangerl <az@breathe-safe.com>
+Date: Wed, 20 Sep 2023 10:01:10 +1000
+Subject: iio: pressure: ms5611: ms5611_prom_is_valid false negative bug
+
+From: Alexander Zangerl <az@breathe-safe.com>
+
+commit fd39d9668f2ce9f4b05ad55e8c8d80c098073e0b upstream.
+
+The ms5611 driver falsely rejects lots of MS5607-02BA03-50 chips
+with "PROM integrity check failed" because it doesn't accept a prom crc
+value of zero as legitimate.
+
+According to the datasheet for this chip (and the manufacturer's
+application note about the PROM CRC), none of the possible values for the
+CRC are excluded - but the current code in ms5611_prom_is_valid() ends with
+
+return crc_orig != 0x0000 && crc == crc_orig
+
+Discussed with the driver author (Tomasz Duszynski) and he indicated that
+at that time (2015) he was dealing with some faulty chip samples which
+returned blank data under some circumstances and/or followed example code
+which indicated CRC zero being bad.
+
+As far as I can tell this exception should not be applied anymore; We've
+got a few hundred custom boards here with this chip where large numbers
+of the prom have a legitimate CRC value 0, and do work fine, but which the
+current driver code wrongly rejects.
+
+Signed-off-by: Alexander Zangerl <az@breathe-safe.com>
+Fixes: c0644160a8b5 ("iio: pressure: add support for MS5611 pressure and temperature sensor")
+Link: https://lore.kernel.org/r/2535-1695168070.831792@Ze3y.dhYT.s3fx
+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/pressure/ms5611_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/pressure/ms5611_core.c
++++ b/drivers/iio/pressure/ms5611_core.c
+@@ -76,7 +76,7 @@ static bool ms5611_prom_is_valid(u16 *pr
+
+ crc = (crc >> 12) & 0x000F;
+
+- return crc_orig != 0x0000 && crc == crc_orig;
++ return crc == crc_orig;
+ }
+
+ static int ms5611_read_prom(struct iio_dev *indio_dev)
--- /dev/null
+From 5c15c60e7be615f05a45cd905093a54b11f461bc Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Date: Fri, 13 Oct 2023 20:11:33 -0700
+Subject: Input: powermate - fix use-after-free in powermate_config_complete
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+commit 5c15c60e7be615f05a45cd905093a54b11f461bc upstream.
+
+syzbot has found a use-after-free bug [1] in the powermate driver. This
+happens when the device is disconnected, which leads to a memory free from
+the powermate_device struct. When an asynchronous control message
+completes after the kfree and its callback is invoked, the lock does not
+exist anymore and hence the bug.
+
+Use usb_kill_urb() on pm->config to cancel any in-progress requests upon
+device disconnection.
+
+[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
+
+Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Reported-by: syzbot+0434ac83f907a1dbdd1e@syzkaller.appspotmail.com
+Link: https://lore.kernel.org/r/20230916-topic-powermate_use_after_free-v3-1-64412b81a7a2@gmail.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/misc/powermate.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/input/misc/powermate.c
++++ b/drivers/input/misc/powermate.c
+@@ -425,6 +425,7 @@ static void powermate_disconnect(struct
+ pm->requires_update = 0;
+ usb_kill_urb(pm->irq);
+ input_unregister_device(pm->input);
++ usb_kill_urb(pm->config);
+ usb_free_urb(pm->irq);
+ usb_free_urb(pm->config);
+ powermate_free_buffers(interface_to_usbdev(intf), pm);
--- /dev/null
+From e2cb5cc822b6c9ee72c56ce1d81671b22c05406a Mon Sep 17 00:00:00 2001
+From: Jeffery Miller <jefferymiller@google.com>
+Date: Fri, 13 Oct 2023 15:23:49 -0700
+Subject: Input: psmouse - fix fast_reconnect function for PS/2 mode
+
+From: Jeffery Miller <jefferymiller@google.com>
+
+commit e2cb5cc822b6c9ee72c56ce1d81671b22c05406a upstream.
+
+When the SMBus connection is attempted psmouse_smbus_init() sets
+the fast_reconnect pointer to psmouse_smbus_reconnecti(). If SMBus
+initialization fails, elantech_setup_ps2() and synaptics_init_ps2() will
+fallback to PS/2 mode, replacing the psmouse private data. This can cause
+issues on resume, since psmouse_smbus_reconnect() expects to find an
+instance of struct psmouse_smbus_dev in psmouse->private.
+
+The issue was uncovered when in 92e24e0e57f7 ("Input: psmouse - add
+delay when deactivating for SMBus mode") psmouse_smbus_reconnect()
+started attempting to use more of the data structure. The commit was
+since reverted, not because it was at fault, but because there was found
+a better way of doing what it was attempting to do.
+
+Fix the problem by resetting the fast_reconnect pointer in psmouse
+structure in elantech_setup_ps2() and synaptics_init_ps2() when the PS/2
+mode is used.
+
+Reported-by: Thorsten Leemhuis <linux@leemhuis.info>
+Tested-by: Thorsten Leemhuis <linux@leemhuis.info>
+Signed-off-by: Jeffery Miller <jefferymiller@google.com>
+Fixes: bf232e460a35 ("Input: psmouse-smbus - allow to control psmouse_deactivate")
+Link: https://lore.kernel.org/r/20231005002249.554877-1-jefferymiller@google.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/mouse/elantech.c | 1 +
+ drivers/input/mouse/synaptics.c | 1 +
+ 2 files changed, 2 insertions(+)
+
+--- a/drivers/input/mouse/elantech.c
++++ b/drivers/input/mouse/elantech.c
+@@ -2114,6 +2114,7 @@ static int elantech_setup_ps2(struct psm
+ psmouse->protocol_handler = elantech_process_byte;
+ psmouse->disconnect = elantech_disconnect;
+ psmouse->reconnect = elantech_reconnect;
++ psmouse->fast_reconnect = NULL;
+ psmouse->pktsize = info->hw_version > 1 ? 6 : 4;
+
+ return 0;
+--- a/drivers/input/mouse/synaptics.c
++++ b/drivers/input/mouse/synaptics.c
+@@ -1617,6 +1617,7 @@ static int synaptics_init_ps2(struct psm
+ psmouse->set_rate = synaptics_set_rate;
+ psmouse->disconnect = synaptics_disconnect;
+ psmouse->reconnect = synaptics_reconnect;
++ psmouse->fast_reconnect = NULL;
+ psmouse->cleanup = synaptics_reset;
+ /* Synaptics can usually stay in sync without extra help */
+ psmouse->resync_time = 0;
--- /dev/null
+From a65cd7ef5a864bdbbe037267c327786b7759d4c6 Mon Sep 17 00:00:00 2001
+From: Matthias Berndt <matthias_berndt@gmx.de>
+Date: Fri, 13 Oct 2023 15:04:36 -0700
+Subject: Input: xpad - add PXN V900 support
+
+From: Matthias Berndt <matthias_berndt@gmx.de>
+
+commit a65cd7ef5a864bdbbe037267c327786b7759d4c6 upstream.
+
+Add VID and PID to the xpad_device table to allow driver to use the PXN
+V900 steering wheel, which is XTYPE_XBOX360 compatible in xinput mode.
+
+Signed-off-by: Matthias Berndt <matthias_berndt@gmx.de>
+Link: https://lore.kernel.org/r/4932699.31r3eYUQgx@fedora
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/joystick/xpad.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/input/joystick/xpad.c
++++ b/drivers/input/joystick/xpad.c
+@@ -252,6 +252,7 @@ static const struct xpad_device {
+ { 0x1038, 0x1430, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
+ { 0x1038, 0x1431, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
+ { 0x11c9, 0x55f0, "Nacon GC-100XF", 0, XTYPE_XBOX360 },
++ { 0x11ff, 0x0511, "PXN V900", 0, XTYPE_XBOX360 },
+ { 0x1209, 0x2882, "Ardwiino Controller", 0, XTYPE_XBOX360 },
+ { 0x12ab, 0x0004, "Honey Bee Xbox360 dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
+ { 0x12ab, 0x0301, "PDP AFTERGLOW AX.1", 0, XTYPE_XBOX360 },
+@@ -446,6 +447,7 @@ static const struct usb_device_id xpad_t
+ XPAD_XBOXONE_VENDOR(0x0f0d), /* Hori Controllers */
+ XPAD_XBOX360_VENDOR(0x1038), /* SteelSeries Controllers */
+ XPAD_XBOX360_VENDOR(0x11c9), /* Nacon GC100XF */
++ XPAD_XBOX360_VENDOR(0x11ff), /* PXN V900 */
+ XPAD_XBOX360_VENDOR(0x1209), /* Ardwiino Controllers */
+ XPAD_XBOX360_VENDOR(0x12ab), /* X-Box 360 dance pads */
+ XPAD_XBOX360_VENDOR(0x1430), /* RedOctane X-Box 360 controllers */
--- /dev/null
+From 7563cf17dce0a875ba3d872acdc63a78ea344019 Mon Sep 17 00:00:00 2001
+From: Jordan Rife <jrife@google.com>
+Date: Wed, 4 Oct 2023 18:38:27 -0500
+Subject: libceph: use kernel_connect()
+
+From: Jordan Rife <jrife@google.com>
+
+commit 7563cf17dce0a875ba3d872acdc63a78ea344019 upstream.
+
+Direct calls to ops->connect() can overwrite the address parameter when
+used in conjunction with BPF SOCK_ADDR hooks. Recent changes to
+kernel_connect() ensure that callers are insulated from such side
+effects. This patch wraps the direct call to ops->connect() with
+kernel_connect() to prevent unexpected changes to the address passed to
+ceph_tcp_connect().
+
+This change was originally part of a larger patch targeting the net tree
+addressing all instances of unprotected calls to ops->connect()
+throughout the kernel, but this change was split up into several patches
+targeting various trees.
+
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/netdev/20230821100007.559638-1-jrife@google.com/
+Link: https://lore.kernel.org/netdev/9944248dba1bce861375fcce9de663934d933ba9.camel@redhat.com/
+Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect")
+Signed-off-by: Jordan Rife <jrife@google.com>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/messenger.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/ceph/messenger.c
++++ b/net/ceph/messenger.c
+@@ -477,8 +477,8 @@ static int ceph_tcp_connect(struct ceph_
+ dout("connect %s\n", ceph_pr_addr(&con->peer_addr));
+
+ con_sock_state_connecting(con);
+- ret = sock->ops->connect(sock, (struct sockaddr *)&ss, sizeof(ss),
+- O_NONBLOCK);
++ ret = kernel_connect(sock, (struct sockaddr *)&ss, sizeof(ss),
++ O_NONBLOCK);
+ if (ret == -EINPROGRESS) {
+ dout("connect %s EINPROGRESS sk_state = %u\n",
+ ceph_pr_addr(&con->peer_addr),
--- /dev/null
+From 0f28ada1fbf0054557cddcdb93ad17f767105208 Mon Sep 17 00:00:00 2001
+From: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com>
+Date: Wed, 6 Sep 2023 11:49:26 +0000
+Subject: mcb: remove is_added flag from mcb_device struct
+
+From: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com>
+
+commit 0f28ada1fbf0054557cddcdb93ad17f767105208 upstream.
+
+When calling mcb_bus_add_devices(), both mcb devices and the mcb
+bus will attempt to attach a device to a driver because they share
+the same bus_type. This causes an issue when trying to cast the
+container of the device to mcb_device struct using to_mcb_device(),
+leading to a wrong cast when the mcb_bus is added. A crash occurs
+when freing the ida resources as the bus numbering of mcb_bus gets
+confused with the is_added flag on the mcb_device struct.
+
+The only reason for this cast was to keep an is_added flag on the
+mcb_device struct that does not seem necessary. The function
+device_attach() handles already bound devices and the mcb subsystem
+does nothing special with this is_added flag so remove it completely.
+
+Fixes: 18d288198099 ("mcb: Correctly initialize the bus's device")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com>
+Co-developed-by: Jose Javier Rodriguez Barbarin <JoseJavier.Rodriguez@duagon.com>
+Signed-off-by: Jose Javier Rodriguez Barbarin <JoseJavier.Rodriguez@duagon.com>
+Link: https://lore.kernel.org/r/20230906114901.63174-2-JoseJavier.Rodriguez@duagon.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mcb/mcb-core.c | 10 +++-------
+ drivers/mcb/mcb-parse.c | 2 --
+ include/linux/mcb.h | 1 -
+ 3 files changed, 3 insertions(+), 10 deletions(-)
+
+--- a/drivers/mcb/mcb-core.c
++++ b/drivers/mcb/mcb-core.c
+@@ -389,17 +389,13 @@ EXPORT_SYMBOL_GPL(mcb_free_dev);
+
+ static int __mcb_bus_add_devices(struct device *dev, void *data)
+ {
+- struct mcb_device *mdev = to_mcb_device(dev);
+ int retval;
+
+- if (mdev->is_added)
+- return 0;
+-
+ retval = device_attach(dev);
+- if (retval < 0)
++ if (retval < 0) {
+ dev_err(dev, "Error adding device (%d)\n", retval);
+-
+- mdev->is_added = true;
++ return retval;
++ }
+
+ return 0;
+ }
+--- a/drivers/mcb/mcb-parse.c
++++ b/drivers/mcb/mcb-parse.c
+@@ -99,8 +99,6 @@ static int chameleon_parse_gdd(struct mc
+ mdev->mem.end = mdev->mem.start + size - 1;
+ mdev->mem.flags = IORESOURCE_MEM;
+
+- mdev->is_added = false;
+-
+ ret = mcb_device_register(bus, mdev);
+ if (ret < 0)
+ goto err;
+--- a/include/linux/mcb.h
++++ b/include/linux/mcb.h
+@@ -63,7 +63,6 @@ static inline struct mcb_bus *to_mcb_bus
+ struct mcb_device {
+ struct device dev;
+ struct mcb_bus *bus;
+- bool is_added;
+ struct mcb_driver *driver;
+ u16 id;
+ int inst;
--- /dev/null
+From 8f8abb863fa5a4cc18955c6a0e17af0ded3e4a76 Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Date: Tue, 10 Oct 2023 00:26:14 +0200
+Subject: net: usb: dm9601: fix uninitialized variable use in dm9601_mdio_read
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+commit 8f8abb863fa5a4cc18955c6a0e17af0ded3e4a76 upstream.
+
+syzbot has found an uninit-value bug triggered by the dm9601 driver [1].
+
+This error happens because the variable res is not updated if the call
+to dm_read_shared_word returns an error. In this particular case -EPROTO
+was returned and res stayed uninitialized.
+
+This can be avoided by checking the return value of dm_read_shared_word
+and propagating the error if the read operation failed.
+
+[1] https://syzkaller.appspot.com/bug?extid=1f53a30781af65d2c955
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Reported-and-tested-by: syzbot+1f53a30781af65d2c955@syzkaller.appspotmail.com
+Acked-by: Peter Korsgaard <peter@korsgaard.com>
+Fixes: d0374f4f9c35cdfbee0 ("USB: Davicom DM9601 usbnet driver")
+Link: https://lore.kernel.org/r/20231009-topic-dm9601_uninit_mdio_read-v2-1-f2fe39739b6c@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/usb/dm9601.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/usb/dm9601.c
++++ b/drivers/net/usb/dm9601.c
+@@ -221,13 +221,18 @@ static int dm9601_mdio_read(struct net_d
+ struct usbnet *dev = netdev_priv(netdev);
+
+ __le16 res;
++ int err;
+
+ if (phy_id) {
+ netdev_dbg(dev->net, "Only internal phy supported\n");
+ return 0;
+ }
+
+- dm_read_shared_word(dev, 1, loc, &res);
++ err = dm_read_shared_word(dev, 1, loc, &res);
++ if (err < 0) {
++ netdev_err(dev->net, "MDIO read error: %d\n", err);
++ return err;
++ }
+
+ netdev_dbg(dev->net,
+ "dm9601_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x\n",
--- /dev/null
+From c153a4edff6ab01370fcac8e46f9c89cca1060c2 Mon Sep 17 00:00:00 2001
+From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Date: Wed, 20 Sep 2023 11:09:10 -0700
+Subject: pinctrl: avoid unsafe code pattern in find_pinctrl()
+
+From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+
+commit c153a4edff6ab01370fcac8e46f9c89cca1060c2 upstream.
+
+The code in find_pinctrl() takes a mutex and traverses a list of pinctrl
+structures. Later the caller bumps up reference count on the found
+structure. Such pattern is not safe as pinctrl that was found may get
+deleted before the caller gets around to increasing the reference count.
+
+Fix this by taking the reference count in find_pinctrl(), while it still
+holds the mutex.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Link: https://lore.kernel.org/r/ZQs1RgTKg6VJqmPs@google.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pinctrl/core.c | 16 +++++++++-------
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+--- a/drivers/pinctrl/core.c
++++ b/drivers/pinctrl/core.c
+@@ -1005,17 +1005,20 @@ static int add_setting(struct pinctrl *p
+
+ static struct pinctrl *find_pinctrl(struct device *dev)
+ {
+- struct pinctrl *p;
++ struct pinctrl *entry, *p = NULL;
+
+ mutex_lock(&pinctrl_list_mutex);
+- list_for_each_entry(p, &pinctrl_list, node)
+- if (p->dev == dev) {
+- mutex_unlock(&pinctrl_list_mutex);
+- return p;
++
++ list_for_each_entry(entry, &pinctrl_list, node) {
++ if (entry->dev == dev) {
++ p = entry;
++ kref_get(&p->users);
++ break;
+ }
++ }
+
+ mutex_unlock(&pinctrl_list_mutex);
+- return NULL;
++ return p;
+ }
+
+ static void pinctrl_free(struct pinctrl *p, bool inlist);
+@@ -1124,7 +1127,6 @@ struct pinctrl *pinctrl_get(struct devic
+ p = find_pinctrl(dev);
+ if (p) {
+ dev_dbg(dev, "obtain a copy of previously claimed pinctrl\n");
+- kref_get(&p->users);
+ return p;
+ }
+
nfc-nci-assert-requested-protocol-is-valid.patch
workqueue-override-implicit-ordered-attribute-in-wor.patch
perf-inject-fix-gen_elf_text_offset-for-jit.patch
+dmaengine-stm32-mdma-abort-resume-if-no-ongoing-transfer.patch
+usb-xhci-xhci-ring-use-sysdev-for-mapping-bounce-buffer.patch
+net-usb-dm9601-fix-uninitialized-variable-use-in-dm9601_mdio_read.patch
+usb-dwc3-soft-reset-phy-on-probe-for-host.patch
+usb-musb-get-the-musb_qh-poniter-after-musb_giveback.patch
+usb-musb-modify-the-hwvers-register-address.patch
+iio-pressure-bmp280-fix-null-pointer-exception.patch
+iio-pressure-dps310-adjust-timeout-settings.patch
+iio-pressure-ms5611-ms5611_prom_is_valid-false-negative-bug.patch
+mcb-remove-is_added-flag-from-mcb_device-struct.patch
+libceph-use-kernel_connect.patch
+ceph-fix-incorrect-revoked-caps-assert-in-ceph_fill_file_size.patch
+input-powermate-fix-use-after-free-in-powermate_config_complete.patch
+input-psmouse-fix-fast_reconnect-function-for-ps-2-mode.patch
+input-xpad-add-pxn-v900-support.patch
+cgroup-remove-duplicates-in-cgroup-v1-tasks-file.patch
+pinctrl-avoid-unsafe-code-pattern-in-find_pinctrl.patch
+usb-gadget-udc-xilinx-replace-memcpy-with-memcpy_toio.patch
+usb-gadget-ncm-handle-decoding-of-multiple-ntb-s-in-unwrap-call.patch
--- /dev/null
+From 8bea147dfdf823eaa8d3baeccc7aeb041b41944b Mon Sep 17 00:00:00 2001
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Date: Wed, 13 Sep 2023 00:52:15 +0000
+Subject: usb: dwc3: Soft reset phy on probe for host
+
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+
+commit 8bea147dfdf823eaa8d3baeccc7aeb041b41944b upstream.
+
+When there's phy initialization, we need to initiate a soft-reset
+sequence. That's done through USBCMD.HCRST in the xHCI driver and its
+initialization, However, the dwc3 driver may modify core configs before
+the soft-reset. This may result in some connection instability. So,
+ensure the phy is ready before the controller updates the GCTL.PRTCAPDIR
+or other settings by issuing phy soft-reset.
+
+Note that some host-mode configurations may not expose device registers
+to initiate the controller soft-reset (via DCTL.CoreSftRst). So we reset
+through GUSB3PIPECTL and GUSB2PHYCFG instead.
+
+Cc: stable@vger.kernel.org
+Fixes: e835c0a4e23c ("usb: dwc3: don't reset device side if dwc3 was configured as host-only")
+Reported-by: Kenta Sato <tosainu.maple@gmail.com>
+Closes: https://lore.kernel.org/linux-usb/ZPUciRLUcjDywMVS@debian.me/
+Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Tested-by: Kenta Sato <tosainu.maple@gmail.com>
+Link: https://lore.kernel.org/r/70aea513215d273669152696cc02b20ddcdb6f1a.1694564261.git.Thinh.Nguyen@synopsys.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/dwc3/core.c | 39 ++++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 38 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/dwc3/core.c
++++ b/drivers/usb/dwc3/core.c
+@@ -250,9 +250,46 @@ int dwc3_core_soft_reset(struct dwc3 *dw
+ * XHCI driver will reset the host block. If dwc3 was configured for
+ * host-only mode or current role is host, then we can return early.
+ */
+- if (dwc->dr_mode == USB_DR_MODE_HOST || dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST)
++ if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST)
+ return 0;
+
++ /*
++ * If the dr_mode is host and the dwc->current_dr_role is not the
++ * corresponding DWC3_GCTL_PRTCAP_HOST, then the dwc3_core_init_mode
++ * isn't executed yet. Ensure the phy is ready before the controller
++ * updates the GCTL.PRTCAPDIR or other settings by soft-resetting
++ * the phy.
++ *
++ * Note: GUSB3PIPECTL[n] and GUSB2PHYCFG[n] are port settings where n
++ * is port index. If this is a multiport host, then we need to reset
++ * all active ports.
++ */
++ if (dwc->dr_mode == USB_DR_MODE_HOST) {
++ u32 usb3_port;
++ u32 usb2_port;
++
++ usb3_port = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
++ usb3_port |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
++ dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), usb3_port);
++
++ usb2_port = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
++ usb2_port |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
++ dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), usb2_port);
++
++ /* Small delay for phy reset assertion */
++ usleep_range(1000, 2000);
++
++ usb3_port &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
++ dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), usb3_port);
++
++ usb2_port &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
++ dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), usb2_port);
++
++ /* Wait for clock synchronization */
++ msleep(50);
++ return 0;
++ }
++
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_CSFTRST;
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
--- /dev/null
+From 427694cfaafa565a3db5c5ea71df6bc095dca92f Mon Sep 17 00:00:00 2001
+From: Krishna Kurapati <quic_kriskura@quicinc.com>
+Date: Wed, 27 Sep 2023 16:28:58 +0530
+Subject: usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Krishna Kurapati <quic_kriskura@quicinc.com>
+
+commit 427694cfaafa565a3db5c5ea71df6bc095dca92f upstream.
+
+When NCM is used with hosts like Windows PC, it is observed that there are
+multiple NTB's contained in one usb request giveback. Since the driver
+unwraps the obtained request data assuming only one NTB is present, we
+loose the subsequent NTB's present resulting in data loss.
+
+Fix this by checking the parsed block length with the obtained data
+length in usb request and continue parsing after the last byte of current
+NTB.
+
+Cc: stable@vger.kernel.org
+Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added")
+Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
+Reviewed-by: Maciej Żenczykowski <maze@google.com>
+Link: https://lore.kernel.org/r/20230927105858.12950-1-quic_kriskura@quicinc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/function/f_ncm.c | 26 +++++++++++++++++++-------
+ 1 file changed, 19 insertions(+), 7 deletions(-)
+
+--- a/drivers/usb/gadget/function/f_ncm.c
++++ b/drivers/usb/gadget/function/f_ncm.c
+@@ -1180,7 +1180,8 @@ static int ncm_unwrap_ntb(struct gether
+ struct sk_buff_head *list)
+ {
+ struct f_ncm *ncm = func_to_ncm(&port->func);
+- __le16 *tmp = (void *) skb->data;
++ unsigned char *ntb_ptr = skb->data;
++ __le16 *tmp;
+ unsigned index, index2;
+ int ndp_index;
+ unsigned dg_len, dg_len2;
+@@ -1193,6 +1194,10 @@ static int ncm_unwrap_ntb(struct gether
+ const struct ndp_parser_opts *opts = ncm->parser_opts;
+ unsigned crc_len = ncm->is_crc ? sizeof(uint32_t) : 0;
+ int dgram_counter;
++ int to_process = skb->len;
++
++parse_ntb:
++ tmp = (__le16 *)ntb_ptr;
+
+ /* dwSignature */
+ if (get_unaligned_le32(tmp) != opts->nth_sign) {
+@@ -1239,7 +1244,7 @@ static int ncm_unwrap_ntb(struct gether
+ * walk through NDP
+ * dwSignature
+ */
+- tmp = (void *)(skb->data + ndp_index);
++ tmp = (__le16 *)(ntb_ptr + ndp_index);
+ if (get_unaligned_le32(tmp) != ncm->ndp_sign) {
+ INFO(port->func.config->cdev, "Wrong NDP SIGN\n");
+ goto err;
+@@ -1296,11 +1301,11 @@ static int ncm_unwrap_ntb(struct gether
+ if (ncm->is_crc) {
+ uint32_t crc, crc2;
+
+- crc = get_unaligned_le32(skb->data +
++ crc = get_unaligned_le32(ntb_ptr +
+ index + dg_len -
+ crc_len);
+ crc2 = ~crc32_le(~0,
+- skb->data + index,
++ ntb_ptr + index,
+ dg_len - crc_len);
+ if (crc != crc2) {
+ INFO(port->func.config->cdev,
+@@ -1327,7 +1332,7 @@ static int ncm_unwrap_ntb(struct gether
+ dg_len - crc_len);
+ if (skb2 == NULL)
+ goto err;
+- skb_put_data(skb2, skb->data + index,
++ skb_put_data(skb2, ntb_ptr + index,
+ dg_len - crc_len);
+
+ skb_queue_tail(list, skb2);
+@@ -1340,10 +1345,17 @@ static int ncm_unwrap_ntb(struct gether
+ } while (ndp_len > 2 * (opts->dgram_item_len * 2));
+ } while (ndp_index);
+
+- dev_consume_skb_any(skb);
+-
+ VDBG(port->func.config->cdev,
+ "Parsed NTB with %d frames\n", dgram_counter);
++
++ to_process -= block_len;
++ if (to_process != 0) {
++ ntb_ptr = (unsigned char *)(ntb_ptr + block_len);
++ goto parse_ntb;
++ }
++
++ dev_consume_skb_any(skb);
++
+ return 0;
+ err:
+ skb_queue_purge(list);
--- /dev/null
+From 3061b6491f491197a35e14e49f805d661b02acd4 Mon Sep 17 00:00:00 2001
+From: Piyush Mehta <piyush.mehta@amd.com>
+Date: Fri, 29 Sep 2023 17:45:14 +0530
+Subject: usb: gadget: udc-xilinx: replace memcpy with memcpy_toio
+
+From: Piyush Mehta <piyush.mehta@amd.com>
+
+commit 3061b6491f491197a35e14e49f805d661b02acd4 upstream.
+
+For ARM processor, unaligned access to device memory is not allowed.
+Method memcpy does not take care of alignment.
+
+USB detection failure with the unalingned address of memory, with
+below kernel crash. To fix the unalingned address kernel panic,
+replace memcpy with memcpy_toio method.
+
+Kernel crash:
+Unable to handle kernel paging request at virtual address ffff80000c05008a
+Mem abort info:
+ ESR = 0x96000061
+ EC = 0x25: DABT (current EL), IL = 32 bits
+ SET = 0, FnV = 0
+ EA = 0, S1PTW = 0
+ FSC = 0x21: alignment fault
+Data abort info:
+ ISV = 0, ISS = 0x00000061
+ CM = 0, WnR = 1
+swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000143b000
+[ffff80000c05008a] pgd=100000087ffff003, p4d=100000087ffff003,
+pud=100000087fffe003, pmd=1000000800bcc003, pte=00680000a0010713
+Internal error: Oops: 96000061 [#1] SMP
+Modules linked in:
+CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.19-xilinx-v2022.1 #1
+Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
+pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+pc : __memcpy+0x30/0x260
+lr : __xudc_ep0_queue+0xf0/0x110
+sp : ffff800008003d00
+x29: ffff800008003d00 x28: ffff800009474e80 x27: 00000000000000a0
+x26: 0000000000000100 x25: 0000000000000012 x24: ffff000800bc8080
+x23: 0000000000000001 x22: 0000000000000012 x21: ffff000800bc8080
+x20: 0000000000000012 x19: ffff000800bc8080 x18: 0000000000000000
+x17: ffff800876482000 x16: ffff800008004000 x15: 0000000000004000
+x14: 00001f09785d0400 x13: 0103020101005567 x12: 0781400000000200
+x11: 00000000c5672a10 x10: 00000000000008d0 x9 : ffff800009463cf0
+x8 : ffff8000094757b0 x7 : 0201010055670781 x6 : 4000000002000112
+x5 : ffff80000c05009a x4 : ffff000800a15012 x3 : ffff00080362ad80
+x2 : 0000000000000012 x1 : ffff000800a15000 x0 : ffff80000c050088
+Call trace:
+ __memcpy+0x30/0x260
+ xudc_ep0_queue+0x3c/0x60
+ usb_ep_queue+0x38/0x44
+ composite_ep0_queue.constprop.0+0x2c/0xc0
+ composite_setup+0x8d0/0x185c
+ configfs_composite_setup+0x74/0xb0
+ xudc_irq+0x570/0xa40
+ __handle_irq_event_percpu+0x58/0x170
+ handle_irq_event+0x60/0x120
+ handle_fasteoi_irq+0xc0/0x220
+ handle_domain_irq+0x60/0x90
+ gic_handle_irq+0x74/0xa0
+ call_on_irq_stack+0x2c/0x60
+ do_interrupt_handler+0x54/0x60
+ el1_interrupt+0x30/0x50
+ el1h_64_irq_handler+0x18/0x24
+ el1h_64_irq+0x78/0x7c
+ arch_cpu_idle+0x18/0x2c
+ do_idle+0xdc/0x15c
+ cpu_startup_entry+0x28/0x60
+ rest_init+0xc8/0xe0
+ arch_call_rest_init+0x10/0x1c
+ start_kernel+0x694/0x6d4
+ __primary_switched+0xa4/0xac
+
+Fixes: 1f7c51660034 ("usb: gadget: Add xilinx usb2 device support")
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/all/202209020044.CX2PfZzM-lkp@intel.com/
+Cc: stable@vger.kernel.org
+Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
+Link: https://lore.kernel.org/r/20230929121514.13475-1-piyush.mehta@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/udc/udc-xilinx.c | 20 ++++++++++++--------
+ 1 file changed, 12 insertions(+), 8 deletions(-)
+
+--- a/drivers/usb/gadget/udc/udc-xilinx.c
++++ b/drivers/usb/gadget/udc/udc-xilinx.c
+@@ -496,11 +496,13 @@ static int xudc_eptxrx(struct xusb_ep *e
+ /* Get the Buffer address and copy the transmit data.*/
+ eprambase = (u32 __force *)(udc->addr + ep->rambase);
+ if (ep->is_in) {
+- memcpy(eprambase, bufferptr, bytestosend);
++ memcpy_toio((void __iomem *)eprambase, bufferptr,
++ bytestosend);
+ udc->write_fn(udc->addr, ep->offset +
+ XUSB_EP_BUF0COUNT_OFFSET, bufferlen);
+ } else {
+- memcpy(bufferptr, eprambase, bytestosend);
++ memcpy_toio((void __iomem *)bufferptr, eprambase,
++ bytestosend);
+ }
+ /*
+ * Enable the buffer for transmission.
+@@ -514,11 +516,13 @@ static int xudc_eptxrx(struct xusb_ep *e
+ eprambase = (u32 __force *)(udc->addr + ep->rambase +
+ ep->ep_usb.maxpacket);
+ if (ep->is_in) {
+- memcpy(eprambase, bufferptr, bytestosend);
++ memcpy_toio((void __iomem *)eprambase, bufferptr,
++ bytestosend);
+ udc->write_fn(udc->addr, ep->offset +
+ XUSB_EP_BUF1COUNT_OFFSET, bufferlen);
+ } else {
+- memcpy(bufferptr, eprambase, bytestosend);
++ memcpy_toio((void __iomem *)bufferptr, eprambase,
++ bytestosend);
+ }
+ /*
+ * Enable the buffer for transmission.
+@@ -1020,7 +1024,7 @@ static int __xudc_ep0_queue(struct xusb_
+ udc->addr);
+ length = req->usb_req.actual = min_t(u32, length,
+ EP0_MAX_PACKET);
+- memcpy(corebuf, req->usb_req.buf, length);
++ memcpy_toio((void __iomem *)corebuf, req->usb_req.buf, length);
+ udc->write_fn(udc->addr, XUSB_EP_BUF0COUNT_OFFSET, length);
+ udc->write_fn(udc->addr, XUSB_BUFFREADY_OFFSET, 1);
+ } else {
+@@ -1746,7 +1750,7 @@ static void xudc_handle_setup(struct xus
+
+ /* Load up the chapter 9 command buffer.*/
+ ep0rambase = (u32 __force *) (udc->addr + XUSB_SETUP_PKT_ADDR_OFFSET);
+- memcpy(&setup, ep0rambase, 8);
++ memcpy_toio((void __iomem *)&setup, ep0rambase, 8);
+
+ udc->setup = setup;
+ udc->setup.wValue = cpu_to_le16(setup.wValue);
+@@ -1833,7 +1837,7 @@ static void xudc_ep0_out(struct xusb_udc
+ (ep0->rambase << 2));
+ buffer = req->usb_req.buf + req->usb_req.actual;
+ req->usb_req.actual = req->usb_req.actual + bytes_to_rx;
+- memcpy(buffer, ep0rambase, bytes_to_rx);
++ memcpy_toio((void __iomem *)buffer, ep0rambase, bytes_to_rx);
+
+ if (req->usb_req.length == req->usb_req.actual) {
+ /* Data transfer completed get ready for Status stage */
+@@ -1909,7 +1913,7 @@ static void xudc_ep0_in(struct xusb_udc
+ (ep0->rambase << 2));
+ buffer = req->usb_req.buf + req->usb_req.actual;
+ req->usb_req.actual = req->usb_req.actual + length;
+- memcpy(ep0rambase, buffer, length);
++ memcpy_toio((void __iomem *)ep0rambase, buffer, length);
+ }
+ udc->write_fn(udc->addr, XUSB_EP_BUF0COUNT_OFFSET, count);
+ udc->write_fn(udc->addr, XUSB_BUFFREADY_OFFSET, 1);
--- /dev/null
+From 33d7e37232155aadebe4145dcc592f00dabd7a2b Mon Sep 17 00:00:00 2001
+From: Xingxing Luo <xingxing.luo@unisoc.com>
+Date: Tue, 19 Sep 2023 11:30:55 +0800
+Subject: usb: musb: Get the musb_qh poniter after musb_giveback
+
+From: Xingxing Luo <xingxing.luo@unisoc.com>
+
+commit 33d7e37232155aadebe4145dcc592f00dabd7a2b upstream.
+
+When multiple threads are performing USB transmission, musb->lock will be
+unlocked when musb_giveback is executed. At this time, qh may be released
+in the dequeue process in other threads, resulting in a wild pointer, so
+it needs to be here get qh again, and judge whether qh is NULL, and when
+dequeue, you need to set qh to NULL.
+
+Fixes: dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed")
+Cc: stable@vger.kernel.org
+Signed-off-by: Xingxing Luo <xingxing.luo@unisoc.com>
+Link: https://lore.kernel.org/r/20230919033055.14085-1-xingxing.luo@unisoc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/musb/musb_host.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/musb/musb_host.c
++++ b/drivers/usb/musb/musb_host.c
+@@ -339,10 +339,16 @@ static void musb_advance_schedule(struct
+ musb_giveback(musb, urb, status);
+ qh->is_ready = ready;
+
++ /*
++ * musb->lock had been unlocked in musb_giveback, so qh may
++ * be freed, need to get it again
++ */
++ qh = musb_ep_get_qh(hw_ep, is_in);
++
+ /* reclaim resources (and bandwidth) ASAP; deschedule it, and
+ * invalidate qh as soon as list_empty(&hep->urb_list)
+ */
+- if (list_empty(&qh->hep->urb_list)) {
++ if (qh && list_empty(&qh->hep->urb_list)) {
+ struct list_head *head;
+ struct dma_controller *dma = musb->dma_controller;
+
+@@ -2424,6 +2430,7 @@ static int musb_urb_dequeue(struct usb_h
+ * and its URB list has emptied, recycle this qh.
+ */
+ if (ready && list_empty(&qh->hep->urb_list)) {
++ musb_ep_set_qh(qh->hw_ep, is_in, NULL);
+ qh->hep->hcpriv = NULL;
+ list_del(&qh->ring);
+ kfree(qh);
--- /dev/null
+From 6658a62e1ddf726483cb2d8bf45ea3f9bd533074 Mon Sep 17 00:00:00 2001
+From: Xingxing Luo <xingxing.luo@unisoc.com>
+Date: Fri, 22 Sep 2023 15:59:29 +0800
+Subject: usb: musb: Modify the "HWVers" register address
+
+From: Xingxing Luo <xingxing.luo@unisoc.com>
+
+commit 6658a62e1ddf726483cb2d8bf45ea3f9bd533074 upstream.
+
+musb HWVers rgister address is not 0x69, if we operate the
+wrong address 0x69, it will cause a kernel crash, because
+there is no register corresponding to this address in the
+additional control register of musb. In fact, HWVers has
+been defined in musb_register.h, and the name is
+"MUSB_HWVERS", so We need to use this macro instead of 0x69.
+
+Fixes: c2365ce5d5a0 ("usb: musb: replace hard coded registers with defines")
+Cc: stable@vger.kernel.org
+Signed-off-by: Xingxing Luo <xingxing.luo@unisoc.com>
+Link: https://lore.kernel.org/r/20230922075929.31074-1-xingxing.luo@unisoc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/musb/musb_debugfs.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/musb/musb_debugfs.c
++++ b/drivers/usb/musb/musb_debugfs.c
+@@ -39,7 +39,7 @@ static const struct musb_register_map mu
+ { "IntrUsbE", MUSB_INTRUSBE, 8 },
+ { "DevCtl", MUSB_DEVCTL, 8 },
+ { "VControl", 0x68, 32 },
+- { "HWVers", 0x69, 16 },
++ { "HWVers", MUSB_HWVERS, 16 },
+ { "LinkInfo", MUSB_LINKINFO, 8 },
+ { "VPLen", MUSB_VPLEN, 8 },
+ { "HS_EOF1", MUSB_HS_EOF1, 8 },
--- /dev/null
+From 41a43013d2366db5b88b42bbcd8e8f040b6ccf21 Mon Sep 17 00:00:00 2001
+From: Wesley Cheng <quic_wcheng@quicinc.com>
+Date: Fri, 15 Sep 2023 17:31:05 +0300
+Subject: usb: xhci: xhci-ring: Use sysdev for mapping bounce buffer
+
+From: Wesley Cheng <quic_wcheng@quicinc.com>
+
+commit 41a43013d2366db5b88b42bbcd8e8f040b6ccf21 upstream.
+
+As mentioned in:
+ commit 474ed23a6257 ("xhci: align the last trb before link if it is
+easily splittable.")
+
+A bounce buffer is utilized for ensuring that transfers that span across
+ring segments are aligned to the EP's max packet size. However, the device
+that is used to map the DMA buffer to is currently using the XHCI HCD,
+which does not carry any DMA operations in certain configrations.
+Migration to using the sysdev entry was introduced for DWC3 based
+implementations where the IOMMU operations are present.
+
+Replace the reference to the controller device to sysdev instead. This
+allows the bounce buffer to be properly mapped to any implementations that
+have an IOMMU involved.
+
+cc: stable@vger.kernel.org
+Fixes: 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration")
+Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20230915143108.1532163-2-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-ring.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -714,7 +714,7 @@ static void xhci_giveback_urb_in_irq(str
+ static void xhci_unmap_td_bounce_buffer(struct xhci_hcd *xhci,
+ struct xhci_ring *ring, struct xhci_td *td)
+ {
+- struct device *dev = xhci_to_hcd(xhci)->self.controller;
++ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
+ struct xhci_segment *seg = td->bounce_seg;
+ struct urb *urb = td->urb;
+ size_t len;
+@@ -3283,7 +3283,7 @@ static u32 xhci_td_remainder(struct xhci
+ static int xhci_align_td(struct xhci_hcd *xhci, struct urb *urb, u32 enqd_len,
+ u32 *trb_buff_len, struct xhci_segment *seg)
+ {
+- struct device *dev = xhci_to_hcd(xhci)->self.controller;
++ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
+ unsigned int unalign;
+ unsigned int max_pkt;
+ u32 new_buff_len;
projects / thirdparty / kernel / stable-queue.git / commitdiff
