--- /dev/null
+From 41d4ca6e71a001bc1a9b0aaf2a2ce9dccda26642 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 28 Jun 2023 02:13:32 +0200
+Subject: Add MODULE_FIRMWARE() for FIRMWARE_TG357766.
+
+From: Tobias Heider <me@tobhe.de>
+
+[ Upstream commit 046f753da6143ee16452966915087ec8b0de3c70 ]
+
+Fixes a bug where on the M1 mac mini initramfs-tools fails to
+include the necessary firmware into the initrd.
+
+Fixes: c4dab50697ff ("tg3: Download 57766 EEE service patch firmware")
+Signed-off-by: Tobias Heider <me@tobhe.de>
+Reviewed-by: Michael Chan <michael.chan@broadcom.com>
+Link: https://lore.kernel.org/r/ZJt7LKzjdz8+dClx@tobhe.de
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/broadcom/tg3.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
+index e0eacfc46dd4a..bc046153edee4 100644
+--- a/drivers/net/ethernet/broadcom/tg3.c
++++ b/drivers/net/ethernet/broadcom/tg3.c
+@@ -228,6 +228,7 @@ MODULE_DESCRIPTION("Broadcom Tigon3 ethernet driver");
+ MODULE_LICENSE("GPL");
+ MODULE_VERSION(DRV_MODULE_VERSION);
+ MODULE_FIRMWARE(FIRMWARE_TG3);
++MODULE_FIRMWARE(FIRMWARE_TG357766);
+ MODULE_FIRMWARE(FIRMWARE_TG3TSO);
+ MODULE_FIRMWARE(FIRMWARE_TG3TSO5);
+
+--
+2.39.2
+
--- /dev/null
+From c534a7a160fe7c1dbd4480dc17dbad949c9d8ee8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 22 Mar 2023 16:39:53 +0200
+Subject: extcon: Fix kernel doc of property capability fields to avoid
+ warnings
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+[ Upstream commit 73346b9965ebda2feb7fef8629e9b28baee820e3 ]
+
+Kernel documentation has to be synchronized with a code, otherwise
+the validator is not happy:
+
+ Function parameter or member 'usb_bits' not described in 'extcon_cable'
+ Function parameter or member 'chg_bits' not described in 'extcon_cable'
+ Function parameter or member 'jack_bits' not described in 'extcon_cable'
+ Function parameter or member 'disp_bits' not described in 'extcon_cable'
+
+Describe the fields added in the past.
+
+Fixes: ceaa98f442cf ("extcon: Add the support for the capability of each property")
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/extcon/extcon.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
+index e131d3287c5d0..e6e3e404052bb 100644
+--- a/drivers/extcon/extcon.c
++++ b/drivers/extcon/extcon.c
+@@ -208,6 +208,10 @@ struct __extcon_info {
+ * @chg_propval: the array of charger connector properties
+ * @jack_propval: the array of jack connector properties
+ * @disp_propval: the array of display connector properties
++ * @usb_bits: the bit array of the USB connector property capabilities
++ * @chg_bits: the bit array of the charger connector property capabilities
++ * @jack_bits: the bit array of the jack connector property capabilities
++ * @disp_bits: the bit array of the display connector property capabilities
+ */
+ struct extcon_cable {
+ struct extcon_dev *edev;
+--
+2.39.2
+
--- /dev/null
+From 7837041fdd17930f68752148589e35c6cae28a2d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 22 Mar 2023 16:39:52 +0200
+Subject: extcon: Fix kernel doc of property fields to avoid warnings
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+[ Upstream commit 7e77e0b7a9f4cdf91cb0950749b40c840ea63efc ]
+
+Kernel documentation has to be synchronized with a code, otherwise
+the validator is not happy:
+
+ Function parameter or member 'usb_propval' not described in 'extcon_cable'
+ Function parameter or member 'chg_propval' not described in 'extcon_cable'
+ Function parameter or member 'jack_propval' not described in 'extcon_cable'
+ Function parameter or member 'disp_propval' not described in 'extcon_cable'
+
+Describe the fields added in the past.
+
+Fixes: 067c1652e7a7 ("extcon: Add the support for extcon property according to extcon type")
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/extcon/extcon.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
+index 81a552654cc7f..e131d3287c5d0 100644
+--- a/drivers/extcon/extcon.c
++++ b/drivers/extcon/extcon.c
+@@ -204,6 +204,10 @@ struct __extcon_info {
+ * @attr_name: "name" sysfs entry
+ * @attr_state: "state" sysfs entry
+ * @attrs: the array pointing to attr_name and attr_state for attr_g
++ * @usb_propval: the array of USB connector properties
++ * @chg_propval: the array of charger connector properties
++ * @jack_propval: the array of jack connector properties
++ * @disp_propval: the array of display connector properties
+ */
+ struct extcon_cable {
+ struct extcon_dev *edev;
+--
+2.39.2
+
--- /dev/null
+From 13ea593c06c30c463e5f6f57d1f8894ad05de064 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 20 Jun 2023 20:00:22 -0500
+Subject: mailbox: ti-msgmgr: Fill non-message tx data fields with 0x0
+
+From: Nishanth Menon <nm@ti.com>
+
+[ Upstream commit 1b712f18c461bd75f018033a15cf381e712806b5 ]
+
+Sec proxy/message manager data buffer is 60 bytes with the last of the
+registers indicating transmission completion. This however poses a bit
+of a challenge.
+
+The backing memory for sec_proxy / message manager is regular memory,
+and all sec proxy does is to trigger a burst of all 60 bytes of data
+over to the target thread backing ring accelerator. It doesn't do a
+memory scrub when it moves data out in the burst. When we transmit
+multiple messages, remnants of previous message is also transmitted
+which results in some random data being set in TISCI fields of
+messages that have been expanded forward.
+
+The entire concept of backward compatibility hinges on the fact that
+the unused message fields remain 0x0 allowing for 0x0 value to be
+specially considered when backward compatibility of message extension
+is done.
+
+So, instead of just writing the completion register, we continue
+to fill the message buffer up with 0x0 (note: for partial message
+involving completion, we already do this).
+
+This allows us to scale and introduce ABI changes back also work with
+other boot stages that may have left data in the internal memory.
+
+While at this, be consistent and explicit with the data_reg pointer
+increment.
+
+Fixes: aace66b170ce ("mailbox: Introduce TI message manager driver")
+Signed-off-by: Nishanth Menon <nm@ti.com>
+Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mailbox/ti-msgmgr.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
+index 54b9e4cb4cfa0..0c4d3640fcbf4 100644
+--- a/drivers/mailbox/ti-msgmgr.c
++++ b/drivers/mailbox/ti-msgmgr.c
+@@ -310,14 +310,20 @@ static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data)
+ /* Ensure all unused data is 0 */
+ data_trail &= 0xFFFFFFFF >> (8 * (sizeof(u32) - trail_bytes));
+ writel(data_trail, data_reg);
+- data_reg++;
++ data_reg += sizeof(u32);
+ }
++
+ /*
+ * 'data_reg' indicates next register to write. If we did not already
+ * write on tx complete reg(last reg), we must do so for transmit
++ * In addition, we also need to make sure all intermediate data
++ * registers(if any required), are reset to 0 for TISCI backward
++ * compatibility to be maintained.
+ */
+- if (data_reg <= qinst->queue_buff_end)
+- writel(0, qinst->queue_buff_end);
++ while (data_reg <= qinst->queue_buff_end) {
++ writel(0, data_reg);
++ data_reg += sizeof(u32);
++ }
+
+ return 0;
+ }
+--
+2.39.2
+
--- /dev/null
+From 117c5b91f0eaf145c14332b65f21a7f073b0619a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Mar 2023 10:04:49 -0700
+Subject: media: usb: Check az6007_read() return value
+
+From: Daniil Dulov <d.dulov@aladdin.ru>
+
+[ Upstream commit fdaca63186f59fc664b346c45b76576624b48e57 ]
+
+If az6007_read() returns error, there is no sence to continue.
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE.
+
+Fixes: 3af2f4f15a61 ("[media] az6007: Change the az6007 read/write routine parameter")
+Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/usb/dvb-usb-v2/az6007.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/media/usb/dvb-usb-v2/az6007.c b/drivers/media/usb/dvb-usb-v2/az6007.c
+index 1414d59e85ba7..1830badb180d8 100644
+--- a/drivers/media/usb/dvb-usb-v2/az6007.c
++++ b/drivers/media/usb/dvb-usb-v2/az6007.c
+@@ -210,7 +210,8 @@ static int az6007_rc_query(struct dvb_usb_device *d)
+ unsigned code;
+ enum rc_proto proto;
+
+- az6007_read(d, AZ6007_READ_IR, 0, 0, st->data, 10);
++ if (az6007_read(d, AZ6007_READ_IR, 0, 0, st->data, 10) < 0)
++ return -EIO;
+
+ if (st->data[1] == 0x44)
+ return 0;
+--
+2.39.2
+
--- /dev/null
+From 6f4ed5a85843333003cfcf1d4d46c629070442d0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 May 2023 07:59:32 +0800
+Subject: media: usb: siano: Fix warning due to null work_func_t function
+ pointer
+
+From: Duoming Zhou <duoming@zju.edu.cn>
+
+[ Upstream commit 6f489a966fbeb0da63d45c2c66a8957eab604bf6 ]
+
+The previous commit ebad8e731c1c ("media: usb: siano: Fix use after
+free bugs caused by do_submit_urb") adds cancel_work_sync() in
+smsusb_stop_streaming(). But smsusb_stop_streaming() may be called,
+even if the work_struct surb->wq has not been initialized. As a result,
+the warning will occur. One of the processes that could lead to warning
+is shown below:
+
+smsusb_probe()
+ smsusb_init_device()
+ if (!dev->in_ep || !dev->out_ep || align < 0) {
+ smsusb_term_device(intf);
+ smsusb_stop_streaming()
+ cancel_work_sync(&dev->surbs[i].wq);
+ __cancel_work_timer()
+ __flush_work()
+ if (WARN_ON(!work->func)) // work->func is null
+
+The log reported by syzbot is shown below:
+
+WARNING: CPU: 0 PID: 897 at kernel/workqueue.c:3066 __flush_work+0x798/0xa80 kernel/workqueue.c:3063
+Modules linked in:
+CPU: 0 PID: 897 Comm: kworker/0:2 Not tainted 6.2.0-rc1-syzkaller #0
+RIP: 0010:__flush_work+0x798/0xa80 kernel/workqueue.c:3066
+...
+RSP: 0018:ffffc9000464ebf8 EFLAGS: 00010246
+RAX: 1ffff11002dbb420 RBX: 0000000000000021 RCX: 1ffffffff204fa4e
+RDX: dffffc0000000000 RSI: 0000000000000001 RDI: ffff888016dda0e8
+RBP: ffffc9000464ed98 R08: 0000000000000001 R09: ffffffff90253b2f
+R10: 0000000000000001 R11: 0000000000000000 R12: ffff888016dda0e8
+R13: ffff888016dda0e8 R14: ffff888016dda100 R15: 0000000000000001
+FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00007ffd4331efe8 CR3: 000000000b48e000 CR4: 00000000003506f0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+ <TASK>
+ __cancel_work_timer+0x315/0x460 kernel/workqueue.c:3160
+ smsusb_stop_streaming drivers/media/usb/siano/smsusb.c:182 [inline]
+ smsusb_term_device+0xda/0x2d0 drivers/media/usb/siano/smsusb.c:344
+ smsusb_init_device+0x400/0x9ce drivers/media/usb/siano/smsusb.c:419
+ smsusb_probe+0xbbd/0xc55 drivers/media/usb/siano/smsusb.c:567
+...
+
+This patch adds check before cancel_work_sync(). If surb->wq has not
+been initialized, the cancel_work_sync() will not be executed.
+
+Reported-by: syzbot+27b0b464864741b18b99@syzkaller.appspotmail.com
+Fixes: ebad8e731c1c ("media: usb: siano: Fix use after free bugs caused by do_submit_urb")
+Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/usb/siano/smsusb.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/media/usb/siano/smsusb.c b/drivers/media/usb/siano/smsusb.c
+index cdbc636e8ff88..92a6192f9ab2b 100644
+--- a/drivers/media/usb/siano/smsusb.c
++++ b/drivers/media/usb/siano/smsusb.c
+@@ -191,7 +191,8 @@ static void smsusb_stop_streaming(struct smsusb_device_t *dev)
+
+ for (i = 0; i < MAX_URBS; i++) {
+ usb_kill_urb(&dev->surbs[i].urb);
+- cancel_work_sync(&dev->surbs[i].wq);
++ if (dev->surbs[i].wq.func)
++ cancel_work_sync(&dev->surbs[i].wq);
+
+ if (dev->surbs[i].cb) {
+ smscore_putbuffer(dev->coredev, dev->surbs[i].cb);
+--
+2.39.2
+
--- /dev/null
+From 087e59ea36f63634cab45df5cc8791102baeca50 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 May 2023 15:36:49 +0200
+Subject: media: videodev2.h: Fix struct v4l2_input tuner index comment
+
+From: Marek Vasut <marex@denx.de>
+
+[ Upstream commit 26ae58f65e64fa7ba61d64bae752e59e08380c6a ]
+
+VIDIOC_ENUMINPUT documentation describes the tuner field of
+struct v4l2_input as index:
+
+Documentation/userspace-api/media/v4l/vidioc-enuminput.rst
+"
+* - __u32
+ - ``tuner``
+ - Capture devices can have zero or more tuners (RF demodulators).
+ When the ``type`` is set to ``V4L2_INPUT_TYPE_TUNER`` this is an
+ RF connector and this field identifies the tuner. It corresponds
+ to struct :c:type:`v4l2_tuner` field ``index``. For
+ details on tuners see :ref:`tuner`.
+"
+
+Drivers I could find also use the 'tuner' field as an index, e.g.:
+drivers/media/pci/bt8xx/bttv-driver.c bttv_enum_input()
+drivers/media/usb/go7007/go7007-v4l2.c vidioc_enum_input()
+
+However, the UAPI comment claims this field is 'enum v4l2_tuner_type':
+include/uapi/linux/videodev2.h
+
+This field being 'enum v4l2_tuner_type' is unlikely as it seems to be
+never used that way in drivers, and documentation confirms it. It seem
+this comment got in accidentally in the commit which this patch fixes.
+Fix the UAPI comment to stop confusion.
+
+This was pointed out by Dmitry while reviewing VIDIOC_ENUMINPUT
+support for strace.
+
+Fixes: 6016af82eafc ("[media] v4l2: use __u32 rather than enums in ioctl() structs")
+Signed-off-by: Marek Vasut <marex@denx.de>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/uapi/linux/videodev2.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
+index b8fd2c303ed04..2ada2122d2743 100644
+--- a/include/uapi/linux/videodev2.h
++++ b/include/uapi/linux/videodev2.h
+@@ -1484,7 +1484,7 @@ struct v4l2_input {
+ __u8 name[32]; /* Label */
+ __u32 type; /* Type of input */
+ __u32 audioset; /* Associated audios (bitfield) */
+- __u32 tuner; /* enum v4l2_tuner_type */
++ __u32 tuner; /* Tuner index */
+ v4l2_std_id std;
+ __u32 status;
+ __u32 capabilities;
+--
+2.39.2
+
--- /dev/null
+From 56a194c41112b2b03506681915912f6a5fd7c354 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 9 Jun 2023 09:48:18 +0800
+Subject: mfd: intel-lpss: Add missing check for platform_get_resource
+
+From: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+
+[ Upstream commit d918e0d5824495a75d00b879118b098fcab36fdb ]
+
+Add the missing check for platform_get_resource and return error
+if it fails.
+
+Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices")
+Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+Signed-off-by: Lee Jones <lee@kernel.org>
+Link: https://lore.kernel.org/r/20230609014818.28475-1-jiasheng@iscas.ac.cn
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mfd/intel-lpss-acpi.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/mfd/intel-lpss-acpi.c b/drivers/mfd/intel-lpss-acpi.c
+index fc44fb7c595bc..281ef5f52eb55 100644
+--- a/drivers/mfd/intel-lpss-acpi.c
++++ b/drivers/mfd/intel-lpss-acpi.c
+@@ -92,6 +92,9 @@ static int intel_lpss_acpi_probe(struct platform_device *pdev)
+ return -ENOMEM;
+
+ info->mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
++ if (!info->mem)
++ return -ENODEV;
++
+ info->irq = platform_get_irq(pdev, 0);
+
+ ret = intel_lpss_probe(&pdev->dev, info);
+--
+2.39.2
+
--- /dev/null
+From cb05221347c0dea9489a502b0dac9939f5d2b96c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 15 May 2023 22:57:10 +0200
+Subject: mfd: rt5033: Drop rt5033-battery sub-device
+
+From: Stephan Gerhold <stephan@gerhold.net>
+
+[ Upstream commit 43db1344e0f8c1eb687a1d6cd5b0de3009ab66cb ]
+
+The fuel gauge in the RT5033 PMIC (rt5033-battery) has its own I2C bus
+and interrupt lines. Therefore, it is not part of the MFD device
+and needs to be specified separately in the device tree.
+
+Fixes: 0b271258544b ("mfd: rt5033: Add Richtek RT5033 driver core.")
+Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
+Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Lee Jones <lee@kernel.org>
+Link: https://lore.kernel.org/r/6a8a19bc67b5be3732882e8131ad2ffcb546ac03.1684182964.git.jahau@rocketmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mfd/rt5033.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
+index 9bd089c563753..94cdad91c0657 100644
+--- a/drivers/mfd/rt5033.c
++++ b/drivers/mfd/rt5033.c
+@@ -44,9 +44,6 @@ static const struct mfd_cell rt5033_devs[] = {
+ {
+ .name = "rt5033-charger",
+ .of_compatible = "richtek,rt5033-charger",
+- }, {
+- .name = "rt5033-battery",
+- .of_compatible = "richtek,rt5033-battery",
+ }, {
+ .name = "rt5033-led",
+ .of_compatible = "richtek,rt5033-led",
+--
+2.39.2
+
--- /dev/null
+From 111c9bf4e819ed485859ca9c646680dd121b0733 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 17 Jun 2023 12:43:16 +0200
+Subject: mfd: stmpe: Only disable the regulators if they are enabled
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+[ Upstream commit 104d32bd81f620bb9f67fbf7d1159c414e89f05f ]
+
+In stmpe_probe(), if some regulator_enable() calls fail, probing continues
+and there is only a dev_warn().
+
+So, if stmpe_probe() is called the regulator may not be enabled. It is
+cleaner to test it before calling regulator_disable() in the remove
+function.
+
+Fixes: 9c9e321455fb ("mfd: stmpe: add optional regulators")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/8de3aaf297931d655b9ad6aed548f4de8b85425a.1686998575.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mfd/stmpe.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
+index 722ad2c368a56..d752c56d60e42 100644
+--- a/drivers/mfd/stmpe.c
++++ b/drivers/mfd/stmpe.c
+@@ -1428,9 +1428,9 @@ int stmpe_probe(struct stmpe_client_info *ci, enum stmpe_partnum partnum)
+
+ int stmpe_remove(struct stmpe *stmpe)
+ {
+- if (!IS_ERR(stmpe->vio))
++ if (!IS_ERR(stmpe->vio) && regulator_is_enabled(stmpe->vio))
+ regulator_disable(stmpe->vio);
+- if (!IS_ERR(stmpe->vcc))
++ if (!IS_ERR(stmpe->vcc) && regulator_is_enabled(stmpe->vcc))
+ regulator_disable(stmpe->vcc);
+
+ mfd_remove_devices(stmpe->dev);
+--
+2.39.2
+
--- /dev/null
+From 1f0f43b871591760ec6760d6fc75794d2d9c8319 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 30 Jun 2023 19:41:18 +0300
+Subject: net: bridge: keep ports without IFF_UNICAST_FLT in BR_PROMISC mode
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit 6ca3c005d0604e8d2b439366e3923ea58db99641 ]
+
+According to the synchronization rules for .ndo_get_stats() as seen in
+Documentation/networking/netdevices.rst, acquiring a plain spin_lock()
+should not be illegal, but the bridge driver implementation makes it so.
+
+After running these commands, I am being faced with the following
+lockdep splat:
+
+$ ip link add link swp0 name macsec0 type macsec encrypt on && ip link set swp0 up
+$ ip link add dev br0 type bridge vlan_filtering 1 && ip link set br0 up
+$ ip link set macsec0 master br0 && ip link set macsec0 up
+
+ ========================================================
+ WARNING: possible irq lock inversion dependency detected
+ 6.4.0-04295-g31b577b4bd4a #603 Not tainted
+ --------------------------------------------------------
+ swapper/1/0 just changed the state of lock:
+ ffff6bd348724cd8 (&br->lock){+.-.}-{3:3}, at: br_forward_delay_timer_expired+0x34/0x198
+ but this lock took another, SOFTIRQ-unsafe lock in the past:
+ (&ocelot->stats_lock){+.+.}-{3:3}
+
+ and interrupts could create inverse lock ordering between them.
+
+ other info that might help us debug this:
+ Chain exists of:
+ &br->lock --> &br->hash_lock --> &ocelot->stats_lock
+
+ Possible interrupt unsafe locking scenario:
+
+ CPU0 CPU1
+ ---- ----
+ lock(&ocelot->stats_lock);
+ local_irq_disable();
+ lock(&br->lock);
+ lock(&br->hash_lock);
+ <Interrupt>
+ lock(&br->lock);
+
+ *** DEADLOCK ***
+
+(details about the 3 locks skipped)
+
+swp0 is instantiated by drivers/net/dsa/ocelot/felix.c, and this
+only matters to the extent that its .ndo_get_stats64() method calls
+spin_lock(&ocelot->stats_lock).
+
+Documentation/locking/lockdep-design.rst says:
+
+| A lock is irq-safe means it was ever used in an irq context, while a lock
+| is irq-unsafe means it was ever acquired with irq enabled.
+
+(...)
+
+| Furthermore, the following usage based lock dependencies are not allowed
+| between any two lock-classes::
+|
+| <hardirq-safe> -> <hardirq-unsafe>
+| <softirq-safe> -> <softirq-unsafe>
+
+Lockdep marks br->hash_lock as softirq-safe, because it is sometimes
+taken in softirq context (for example br_fdb_update() which runs in
+NET_RX softirq), and when it's not in softirq context it blocks softirqs
+by using spin_lock_bh().
+
+Lockdep marks ocelot->stats_lock as softirq-unsafe, because it never
+blocks softirqs from running, and it is never taken from softirq
+context. So it can always be interrupted by softirqs.
+
+There is a call path through which a function that holds br->hash_lock:
+fdb_add_hw_addr() will call a function that acquires ocelot->stats_lock:
+ocelot_port_get_stats64(). This can be seen below:
+
+ocelot_port_get_stats64+0x3c/0x1e0
+felix_get_stats64+0x20/0x38
+dsa_slave_get_stats64+0x3c/0x60
+dev_get_stats+0x74/0x2c8
+rtnl_fill_stats+0x4c/0x150
+rtnl_fill_ifinfo+0x5cc/0x7b8
+rtmsg_ifinfo_build_skb+0xe4/0x150
+rtmsg_ifinfo+0x5c/0xb0
+__dev_notify_flags+0x58/0x200
+__dev_set_promiscuity+0xa0/0x1f8
+dev_set_promiscuity+0x30/0x70
+macsec_dev_change_rx_flags+0x68/0x88
+__dev_set_promiscuity+0x1a8/0x1f8
+__dev_set_rx_mode+0x74/0xa8
+dev_uc_add+0x74/0xa0
+fdb_add_hw_addr+0x68/0xd8
+fdb_add_local+0xc4/0x110
+br_fdb_add_local+0x54/0x88
+br_add_if+0x338/0x4a0
+br_add_slave+0x20/0x38
+do_setlink+0x3a4/0xcb8
+rtnl_newlink+0x758/0x9d0
+rtnetlink_rcv_msg+0x2f0/0x550
+netlink_rcv_skb+0x128/0x148
+rtnetlink_rcv+0x24/0x38
+
+the plain English explanation for it is:
+
+The macsec0 bridge port is created without p->flags & BR_PROMISC,
+because it is what br_manage_promisc() decides for a VLAN filtering
+bridge with a single auto port.
+
+As part of the br_add_if() procedure, br_fdb_add_local() is called for
+the MAC address of the device, and this results in a call to
+dev_uc_add() for macsec0 while the softirq-safe br->hash_lock is taken.
+
+Because macsec0 does not have IFF_UNICAST_FLT, dev_uc_add() ends up
+calling __dev_set_promiscuity() for macsec0, which is propagated by its
+implementation, macsec_dev_change_rx_flags(), to the lower device: swp0.
+This triggers the call path:
+
+dev_set_promiscuity(swp0)
+-> rtmsg_ifinfo()
+ -> dev_get_stats()
+ -> ocelot_port_get_stats64()
+
+with a calling context that lockdep doesn't like (br->hash_lock held).
+
+Normally we don't see this, because even though many drivers that can be
+bridge ports don't support IFF_UNICAST_FLT, we need a driver that
+
+(a) doesn't support IFF_UNICAST_FLT, *and*
+(b) it forwards the IFF_PROMISC flag to another driver, and
+(c) *that* driver implements ndo_get_stats64() using a softirq-unsafe
+ spinlock.
+
+Condition (b) is necessary because the first __dev_set_rx_mode() calls
+__dev_set_promiscuity() with "bool notify=false", and thus, the
+rtmsg_ifinfo() code path won't be entered.
+
+The same criteria also hold true for DSA switches which don't report
+IFF_UNICAST_FLT. When the DSA master uses a spin_lock() in its
+ndo_get_stats64() method, the same lockdep splat can be seen.
+
+I think the deadlock possibility is real, even though I didn't reproduce
+it, and I'm thinking of the following situation to support that claim:
+
+fdb_add_hw_addr() runs on a CPU A, in a context with softirqs locally
+disabled and br->hash_lock held, and may end up attempting to acquire
+ocelot->stats_lock.
+
+In parallel, ocelot->stats_lock is currently held by a thread B (say,
+ocelot_check_stats_work()), which is interrupted while holding it by a
+softirq which attempts to lock br->hash_lock.
+
+Thread B cannot make progress because br->hash_lock is held by A. Whereas
+thread A cannot make progress because ocelot->stats_lock is held by B.
+
+When taking the issue at face value, the bridge can avoid that problem
+by simply making the ports promiscuous from a code path with a saner
+calling context (br->hash_lock not held). A bridge port without
+IFF_UNICAST_FLT is going to become promiscuous as soon as we call
+dev_uc_add() on it (which we do unconditionally), so why not be
+preemptive and make it promiscuous right from the beginning, so as to
+not be taken by surprise.
+
+With this, we've broken the links between code that holds br->hash_lock
+or br->lock and code that calls into the ndo_change_rx_flags() or
+ndo_get_stats64() ops of the bridge port.
+
+Fixes: 2796d0c648c9 ("bridge: Automatically manage port promiscuous mode.")
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Reviewed-by: Ido Schimmel <idosch@nvidia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bridge/br_if.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
+index c8bf044ab5346..7229524b4448b 100644
+--- a/net/bridge/br_if.c
++++ b/net/bridge/br_if.c
+@@ -155,8 +155,9 @@ void br_manage_promisc(struct net_bridge *br)
+ * This lets us disable promiscuous mode and write
+ * this config to hw.
+ */
+- if (br->auto_cnt == 0 ||
+- (br->auto_cnt == 1 && br_auto_port(p)))
++ if ((p->dev->priv_flags & IFF_UNICAST_FLT) &&
++ (br->auto_cnt == 0 ||
++ (br->auto_cnt == 1 && br_auto_port(p))))
+ br_port_clear_promisc(p);
+ else
+ br_port_set_promisc(p);
+--
+2.39.2
+
--- /dev/null
+From 50e18871ec30ace165631a3bbad9c7a1179105f1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 3 Jul 2023 19:08:42 +0800
+Subject: net/sched: act_pedit: Add size check for TCA_PEDIT_PARMS_EX
+
+From: Lin Ma <linma@zju.edu.cn>
+
+[ Upstream commit 30c45b5361d39b4b793780ffac5538090b9e2eb1 ]
+
+The attribute TCA_PEDIT_PARMS_EX is not be included in pedit_policy and
+one malicious user could fake a TCA_PEDIT_PARMS_EX whose length is
+smaller than the intended sizeof(struct tc_pedit). Hence, the
+dereference in tcf_pedit_init() could access dirty heap data.
+
+static int tcf_pedit_init(...)
+{
+ // ...
+ pattr = tb[TCA_PEDIT_PARMS]; // TCA_PEDIT_PARMS is included
+ if (!pattr)
+ pattr = tb[TCA_PEDIT_PARMS_EX]; // but this is not
+
+ // ...
+ parm = nla_data(pattr);
+
+ index = parm->index; // parm is able to be smaller than 4 bytes
+ // and this dereference gets dirty skb_buff
+ // data created in netlink_sendmsg
+}
+
+This commit adds TCA_PEDIT_PARMS_EX length in pedit_policy which avoid
+the above case, just like the TCA_PEDIT_PARMS.
+
+Fixes: 71d0ed7079df ("net/act_pedit: Support using offset relative to the conventional network headers")
+Signed-off-by: Lin Ma <linma@zju.edu.cn>
+Reviewed-by: Pedro Tammela <pctammela@mojatatu.com>
+Link: https://lore.kernel.org/r/20230703110842.590282-1-linma@zju.edu.cn
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sched/act_pedit.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c
+index fb0caa500ac88..d14c31129e083 100644
+--- a/net/sched/act_pedit.c
++++ b/net/sched/act_pedit.c
+@@ -29,6 +29,7 @@ static struct tc_action_ops act_pedit_ops;
+
+ static const struct nla_policy pedit_policy[TCA_PEDIT_MAX + 1] = {
+ [TCA_PEDIT_PARMS] = { .len = sizeof(struct tc_pedit) },
++ [TCA_PEDIT_PARMS_EX] = { .len = sizeof(struct tc_pedit) },
+ [TCA_PEDIT_KEYS_EX] = { .type = NLA_NESTED },
+ };
+
+--
+2.39.2
+
--- /dev/null
+From fac48d94011693fd8645bf97d0b7a3bbc2fbdbe0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 30 Jun 2023 22:47:12 -0700
+Subject: powerpc: allow PPC_EARLY_DEBUG_CPM only when SERIAL_CPM=y
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Randy Dunlap <rdunlap@infradead.org>
+
+[ Upstream commit 39f49684036d24af800ff194c33c7b2653c591d7 ]
+
+In a randconfig with CONFIG_SERIAL_CPM=m and
+CONFIG_PPC_EARLY_DEBUG_CPM=y, there is a build error:
+ERROR: modpost: "udbg_putc" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined!
+
+Prevent the build error by allowing PPC_EARLY_DEBUG_CPM only when
+SERIAL_CPM=y.
+
+Fixes: c374e00e17f1 ("[POWERPC] Add early debug console for CPM serial ports.")
+Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
+Reviewed-by: Pali Rohár <pali@kernel.org>
+Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://msgid.link/20230701054714.30512-1-rdunlap@infradead.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/Kconfig.debug | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
+index 762bb08b0f59f..6c60cc03a53c2 100644
+--- a/arch/powerpc/Kconfig.debug
++++ b/arch/powerpc/Kconfig.debug
+@@ -231,7 +231,7 @@ config PPC_EARLY_DEBUG_40x
+
+ config PPC_EARLY_DEBUG_CPM
+ bool "Early serial debugging for Freescale CPM-based serial ports"
+- depends on SERIAL_CPM
++ depends on SERIAL_CPM=y
+ help
+ Select this to enable early debugging for Freescale chips
+ using a CPM-based serial port. This assumes that the bootwrapper
+--
+2.39.2
+
--- /dev/null
+From 01d90e3374729d2e3f05b5fda3b1f7d6198ad9ae Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 8 Jun 2023 21:11:42 +0200
+Subject: rtc: st-lpc: Release some resources in st_rtc_probe() in case of
+ error
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+[ Upstream commit 06c6e1b01d9261f03629cefd1f3553503291e6cf ]
+
+If an error occurs after clk_get(), the corresponding resources should be
+released.
+
+Use devm_clk_get() to fix it.
+
+Fixes: b5b2bdfc2893 ("rtc: st: Add new driver for ST's LPC RTC")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Link: https://lore.kernel.org/r/866af6adbc7454a7b4505eb6c28fbdc86ccff39e.1686251455.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/rtc/rtc-st-lpc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/rtc/rtc-st-lpc.c b/drivers/rtc/rtc-st-lpc.c
+index 6f33e705928f4..9044c2851a1f2 100644
+--- a/drivers/rtc/rtc-st-lpc.c
++++ b/drivers/rtc/rtc-st-lpc.c
+@@ -236,7 +236,7 @@ static int st_rtc_probe(struct platform_device *pdev)
+ enable_irq_wake(rtc->irq);
+ disable_irq(rtc->irq);
+
+- rtc->clk = clk_get(&pdev->dev, NULL);
++ rtc->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(rtc->clk)) {
+ dev_err(&pdev->dev, "Unable to request clock\n");
+ return PTR_ERR(rtc->clk);
+--
+2.39.2
+
--- /dev/null
+From 3aa4910380312f5aa08b6c8acf153213b806362b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 27 Jun 2023 12:03:40 +0000
+Subject: sctp: fix potential deadlock on &net->sctp.addr_wq_lock
+
+From: Chengfeng Ye <dg573847474@gmail.com>
+
+[ Upstream commit 6feb37b3b06e9049e20dcf7e23998f92c9c5be9a ]
+
+As &net->sctp.addr_wq_lock is also acquired by the timer
+sctp_addr_wq_timeout_handler() in protocal.c, the same lock acquisition
+at sctp_auto_asconf_init() seems should disable irq since it is called
+from sctp_accept() under process context.
+
+Possible deadlock scenario:
+sctp_accept()
+ -> sctp_sock_migrate()
+ -> sctp_auto_asconf_init()
+ -> spin_lock(&net->sctp.addr_wq_lock)
+ <timer interrupt>
+ -> sctp_addr_wq_timeout_handler()
+ -> spin_lock_bh(&net->sctp.addr_wq_lock); (deadlock here)
+
+This flaw was found using an experimental static analysis tool we are
+developing for irq-related deadlock.
+
+The tentative patch fix the potential deadlock by spin_lock_bh().
+
+Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
+Fixes: 34e5b0118685 ("sctp: delay auto_asconf init until binding the first addr")
+Acked-by: Xin Long <lucien.xin@gmail.com>
+Link: https://lore.kernel.org/r/20230627120340.19432-1-dg573847474@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sctp/socket.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/sctp/socket.c b/net/sctp/socket.c
+index 8dd368168a84a..9414dcb376d26 100644
+--- a/net/sctp/socket.c
++++ b/net/sctp/socket.c
+@@ -374,9 +374,9 @@ static void sctp_auto_asconf_init(struct sctp_sock *sp)
+ struct net *net = sock_net(&sp->inet.sk);
+
+ if (net->sctp.default_auto_asconf) {
+- spin_lock(&net->sctp.addr_wq_lock);
++ spin_lock_bh(&net->sctp.addr_wq_lock);
+ list_add_tail(&sp->auto_asconf_list, &net->sctp.auto_asconf_splist);
+- spin_unlock(&net->sctp.addr_wq_lock);
++ spin_unlock_bh(&net->sctp.addr_wq_lock);
+ sp->do_auto_asconf = 1;
+ }
+ }
+--
+2.39.2
+
modpost-fix-off-by-one-in-is_executable_section.patch
usb-serial-option-add-lara-r6-01b-pids.patch
block-change-all-__u32-annotations-to-__be32-in-affs_hardblocks.h.patch
+w1-fix-loop-in-w1_fini.patch
+sh-j2-use-ioremap-to-translate-device-tree-address-i.patch
+media-usb-check-az6007_read-return-value.patch
+media-videodev2.h-fix-struct-v4l2_input-tuner-index-.patch
+media-usb-siano-fix-warning-due-to-null-work_func_t-.patch
+extcon-fix-kernel-doc-of-property-fields-to-avoid-wa.patch
+extcon-fix-kernel-doc-of-property-capability-fields-.patch
+usb-phy-phy-tahvo-fix-memory-leak-in-tahvo_usb_probe.patch
+mfd-rt5033-drop-rt5033-battery-sub-device.patch
+mfd-intel-lpss-add-missing-check-for-platform_get_re.patch
+mfd-stmpe-only-disable-the-regulators-if-they-are-en.patch
+rtc-st-lpc-release-some-resources-in-st_rtc_probe-in.patch
+sctp-fix-potential-deadlock-on-net-sctp.addr_wq_lock.patch
+add-module_firmware-for-firmware_tg357766.patch
+spi-bcm-qspi-return-error-if-neither-hif_mspi-nor-ms.patch
+mailbox-ti-msgmgr-fill-non-message-tx-data-fields-wi.patch
+powerpc-allow-ppc_early_debug_cpm-only-when-serial_c.patch
+net-bridge-keep-ports-without-iff_unicast_flt-in-br_.patch
+tcp-annotate-data-races-in-__tcp_oow_rate_limited.patch
+net-sched-act_pedit-add-size-check-for-tca_pedit_par.patch
+sh-dma-fix-dma-channel-offset-calculation.patch
--- /dev/null
+From 380452e650d23ba0ea533e6b4622e018ba77d5a3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 27 May 2023 18:44:50 +0200
+Subject: sh: dma: Fix DMA channel offset calculation
+
+From: Artur Rojek <contact@artur-rojek.eu>
+
+[ Upstream commit e82e47584847129a20b8c9f4a1dcde09374fb0e0 ]
+
+Various SoCs of the SH3, SH4 and SH4A family, which use this driver,
+feature a differing number of DMA channels, which can be distributed
+between up to two DMAC modules. The existing implementation fails to
+correctly accommodate for all those variations, resulting in wrong
+channel offset calculations and leading to kernel panics.
+
+Rewrite dma_base_addr() in order to properly calculate channel offsets
+in a DMAC module. Fix dmaor_read_reg() and dmaor_write_reg(), so that
+the correct DMAC module base is selected for the DMAOR register.
+
+Fixes: 7f47c7189b3e8f19 ("sh: dma: More legacy cpu dma chainsawing.")
+Signed-off-by: Artur Rojek <contact@artur-rojek.eu>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Link: https://lore.kernel.org/r/20230527164452.64797-2-contact@artur-rojek.eu
+Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/sh/drivers/dma/dma-sh.c | 37 +++++++++++++++++++++++-------------
+ 1 file changed, 24 insertions(+), 13 deletions(-)
+
+diff --git a/arch/sh/drivers/dma/dma-sh.c b/arch/sh/drivers/dma/dma-sh.c
+index afde2a7d3eb35..e0679d8a9b34b 100644
+--- a/arch/sh/drivers/dma/dma-sh.c
++++ b/arch/sh/drivers/dma/dma-sh.c
+@@ -21,6 +21,18 @@
+ #include <cpu/dma-register.h>
+ #include <cpu/dma.h>
+
++/*
++ * Some of the SoCs feature two DMAC modules. In such a case, the channels are
++ * distributed equally among them.
++ */
++#ifdef SH_DMAC_BASE1
++#define SH_DMAC_NR_MD_CH (CONFIG_NR_ONCHIP_DMA_CHANNELS / 2)
++#else
++#define SH_DMAC_NR_MD_CH CONFIG_NR_ONCHIP_DMA_CHANNELS
++#endif
++
++#define SH_DMAC_CH_SZ 0x10
++
+ /*
+ * Define the default configuration for dual address memory-memory transfer.
+ * The 0x400 value represents auto-request, external->external.
+@@ -32,7 +44,7 @@ static unsigned long dma_find_base(unsigned int chan)
+ unsigned long base = SH_DMAC_BASE0;
+
+ #ifdef SH_DMAC_BASE1
+- if (chan >= 6)
++ if (chan >= SH_DMAC_NR_MD_CH)
+ base = SH_DMAC_BASE1;
+ #endif
+
+@@ -43,13 +55,13 @@ static unsigned long dma_base_addr(unsigned int chan)
+ {
+ unsigned long base = dma_find_base(chan);
+
+- /* Normalize offset calculation */
+- if (chan >= 9)
+- chan -= 6;
+- if (chan >= 4)
+- base += 0x10;
++ chan = (chan % SH_DMAC_NR_MD_CH) * SH_DMAC_CH_SZ;
++
++ /* DMAOR is placed inside the channel register space. Step over it. */
++ if (chan >= DMAOR)
++ base += SH_DMAC_CH_SZ;
+
+- return base + (chan * 0x10);
++ return base + chan;
+ }
+
+ #ifdef CONFIG_SH_DMA_IRQ_MULTI
+@@ -253,12 +265,11 @@ static int sh_dmac_get_dma_residue(struct dma_channel *chan)
+ #define NR_DMAOR 1
+ #endif
+
+-/*
+- * DMAOR bases are broken out amongst channel groups. DMAOR0 manages
+- * channels 0 - 5, DMAOR1 6 - 11 (optional).
+- */
+-#define dmaor_read_reg(n) __raw_readw(dma_find_base((n)*6))
+-#define dmaor_write_reg(n, data) __raw_writew(data, dma_find_base(n)*6)
++#define dmaor_read_reg(n) __raw_readw(dma_find_base((n) * \
++ SH_DMAC_NR_MD_CH) + DMAOR)
++#define dmaor_write_reg(n, data) __raw_writew(data, \
++ dma_find_base((n) * \
++ SH_DMAC_NR_MD_CH) + DMAOR)
+
+ static inline int dmaor_reset(int no)
+ {
+--
+2.39.2
+
--- /dev/null
+From c4d5c72b323e24dd713d1414e43238c49c01ed70 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 3 May 2023 14:57:41 +0200
+Subject: sh: j2: Use ioremap() to translate device tree address into kernel
+ memory
+
+From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+
+[ Upstream commit bc9d1f0cecd2407cfb2364a7d4be2f52d1d46a9d ]
+
+Addresses the following warning when building j2_defconfig:
+
+arch/sh/kernel/cpu/sh2/probe.c: In function 'scan_cache':
+arch/sh/kernel/cpu/sh2/probe.c:24:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
+ 24 | j2_ccr_base = (u32 __iomem *)of_flat_dt_translate_address(node);
+ |
+
+Fixes: 5a846abad07f ("sh: add support for J-Core J2 processor")
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Tested-by: Rob Landley <rob@landley.net>
+Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Link: https://lore.kernel.org/r/20230503125746.331835-1-glaubitz@physik.fu-berlin.de
+Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/sh/kernel/cpu/sh2/probe.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/sh/kernel/cpu/sh2/probe.c b/arch/sh/kernel/cpu/sh2/probe.c
+index a5bd036426789..75dcb1d6bc62f 100644
+--- a/arch/sh/kernel/cpu/sh2/probe.c
++++ b/arch/sh/kernel/cpu/sh2/probe.c
+@@ -24,7 +24,7 @@ static int __init scan_cache(unsigned long node, const char *uname,
+ if (!of_flat_dt_is_compatible(node, "jcore,cache"))
+ return 0;
+
+- j2_ccr_base = (u32 __iomem *)of_flat_dt_translate_address(node);
++ j2_ccr_base = ioremap(of_flat_dt_translate_address(node), 4);
+
+ return 1;
+ }
+--
+2.39.2
+
--- /dev/null
+From 0100ffe7c1c1b46d263a116d7ad455345dddecfb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Jun 2023 15:43:05 +0200
+Subject: spi: bcm-qspi: return error if neither hif_mspi nor mspi is available
+
+From: Jonas Gorski <jonas.gorski@gmail.com>
+
+[ Upstream commit 7c1f23ad34fcdace50275a6aa1e1969b41c6233f ]
+
+If neither a "hif_mspi" nor "mspi" resource is present, the driver will
+just early exit in probe but still return success. Apart from not doing
+anything meaningful, this would then also lead to a null pointer access
+on removal, as platform_get_drvdata() would return NULL, which it would
+then try to dereference when trying to unregister the spi master.
+
+Fix this by unconditionally calling devm_ioremap_resource(), as it can
+handle a NULL res and will then return a viable ERR_PTR() if we get one.
+
+The "return 0;" was previously a "goto qspi_resource_err;" where then
+ret was returned, but since ret was still initialized to 0 at this place
+this was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fix
+use-after-free on unbind"). The issue was not introduced by this commit,
+only made more obvious.
+
+Fixes: fa236a7ef240 ("spi: bcm-qspi: Add Broadcom MSPI driver")
+Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
+Reviewed-by: Kamal Dasu <kamal.dasu@broadcom.com>
+Link: https://lore.kernel.org/r/20230629134306.95823-1-jonas.gorski@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-bcm-qspi.c | 10 +++-------
+ 1 file changed, 3 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/spi/spi-bcm-qspi.c b/drivers/spi/spi-bcm-qspi.c
+index 0321ac531df7f..cebc06759eeea 100644
+--- a/drivers/spi/spi-bcm-qspi.c
++++ b/drivers/spi/spi-bcm-qspi.c
+@@ -1251,13 +1251,9 @@ int bcm_qspi_probe(struct platform_device *pdev,
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "mspi");
+
+- if (res) {
+- qspi->base[MSPI] = devm_ioremap_resource(dev, res);
+- if (IS_ERR(qspi->base[MSPI]))
+- return PTR_ERR(qspi->base[MSPI]);
+- } else {
+- return 0;
+- }
++ qspi->base[MSPI] = devm_ioremap_resource(dev, res);
++ if (IS_ERR(qspi->base[MSPI]))
++ return PTR_ERR(qspi->base[MSPI]);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "bspi");
+ if (res) {
+--
+2.39.2
+
--- /dev/null
+From fabc6a037bfcf617d85a0ff10452f381dafab0e0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Jun 2023 16:41:50 +0000
+Subject: tcp: annotate data races in __tcp_oow_rate_limited()
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit 998127cdb4699b9d470a9348ffe9f1154346be5f ]
+
+request sockets are lockless, __tcp_oow_rate_limited() could be called
+on the same object from different cpus. This is harmless.
+
+Add READ_ONCE()/WRITE_ONCE() annotations to avoid a KCSAN report.
+
+Fixes: 4ce7e93cb3fe ("tcp: rate limit ACK sent by SYN_RECV request sockets")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/tcp_input.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
+index 87095d5ecf952..444ad17289277 100644
+--- a/net/ipv4/tcp_input.c
++++ b/net/ipv4/tcp_input.c
+@@ -3447,8 +3447,11 @@ static int tcp_ack_update_window(struct sock *sk, const struct sk_buff *skb, u32
+ static bool __tcp_oow_rate_limited(struct net *net, int mib_idx,
+ u32 *last_oow_ack_time)
+ {
+- if (*last_oow_ack_time) {
+- s32 elapsed = (s32)(tcp_jiffies32 - *last_oow_ack_time);
++ /* Paired with the WRITE_ONCE() in this function. */
++ u32 val = READ_ONCE(*last_oow_ack_time);
++
++ if (val) {
++ s32 elapsed = (s32)(tcp_jiffies32 - val);
+
+ if (0 <= elapsed && elapsed < sysctl_tcp_invalid_ratelimit) {
+ NET_INC_STATS(net, mib_idx);
+@@ -3456,7 +3459,10 @@ static bool __tcp_oow_rate_limited(struct net *net, int mib_idx,
+ }
+ }
+
+- *last_oow_ack_time = tcp_jiffies32;
++ /* Paired with the prior READ_ONCE() and with itself,
++ * as we might be lockless.
++ */
++ WRITE_ONCE(*last_oow_ack_time, tcp_jiffies32);
+
+ return false; /* not rate-limited: go ahead, send dupack now! */
+ }
+--
+2.39.2
+
--- /dev/null
+From 1c9344ce689a5dea5d1b4a33e603e0105a8493d0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Apr 2023 22:08:31 +0800
+Subject: usb: phy: phy-tahvo: fix memory leak in tahvo_usb_probe()
+
+From: Li Yang <lidaxian@hust.edu.cn>
+
+[ Upstream commit 342161c11403ea00e9febc16baab1d883d589d04 ]
+
+Smatch reports:
+drivers/usb/phy/phy-tahvo.c: tahvo_usb_probe()
+warn: missing unwind goto?
+
+After geting irq, if ret < 0, it will return without error handling to
+free memory.
+Just add error handling to fix this problem.
+
+Fixes: 0d45a1373e66 ("usb: phy: tahvo: add IRQ check")
+Signed-off-by: Li Yang <lidaxian@hust.edu.cn>
+Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
+Link: https://lore.kernel.org/r/20230420140832.9110-1-lidaxian@hust.edu.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/phy/phy-tahvo.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
+index e4fc73bf6ee9b..c156c051df990 100644
+--- a/drivers/usb/phy/phy-tahvo.c
++++ b/drivers/usb/phy/phy-tahvo.c
+@@ -406,7 +406,7 @@ static int tahvo_usb_probe(struct platform_device *pdev)
+
+ tu->irq = ret = platform_get_irq(pdev, 0);
+ if (ret < 0)
+- return ret;
++ goto err_remove_phy;
+ ret = request_threaded_irq(tu->irq, NULL, tahvo_usb_vbus_interrupt,
+ IRQF_ONESHOT,
+ "tahvo-vbus", tu);
+--
+2.39.2
+
--- /dev/null
+From 8345cf86707f04ae1ee711c9f6a7227cc0804457 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 19 May 2021 17:17:45 +0300
+Subject: w1: fix loop in w1_fini()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+[ Upstream commit 83f3fcf96fcc7e5405b37d9424c7ef26bfa203f8 ]
+
+The __w1_remove_master_device() function calls:
+
+ list_del(&dev->w1_master_entry);
+
+So presumably this can cause an endless loop.
+
+Fixes: 7785925dd8e0 ("[PATCH] w1: cleanups.")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/w1/w1.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
+index 4d43c373e5c64..cfba277bfd57f 100644
+--- a/drivers/w1/w1.c
++++ b/drivers/w1/w1.c
+@@ -1233,10 +1233,10 @@ static int __init w1_init(void)
+
+ static void __exit w1_fini(void)
+ {
+- struct w1_master *dev;
++ struct w1_master *dev, *n;
+
+ /* Set netlink removal messages and some cleanup */
+- list_for_each_entry(dev, &w1_masters, w1_master_entry)
++ list_for_each_entry_safe(dev, n, &w1_masters, w1_master_entry)
+ __w1_remove_master_device(dev);
+
+ w1_fini_netlink();
+--
+2.39.2
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
