--- /dev/null
+From 7b7bc6e6b4065be710de7be625fd830ccfc71ee7 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 d0cd86af29d9f..b16517d162cfd 100644
+--- a/drivers/net/ethernet/broadcom/tg3.c
++++ b/drivers/net/ethernet/broadcom/tg3.c
+@@ -230,6 +230,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 234d6d4113c2a9a2386a02cd48ec6a8b75209ee4 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 00ad8b637749b..12f9ae2aac113 100644
+--- a/drivers/extcon/extcon.c
++++ b/drivers/extcon/extcon.c
+@@ -200,6 +200,10 @@ static const 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 e3ec1522ffa67dce0b89287b5e4869daae394ad1 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 6b905c3d30f4f..00ad8b637749b 100644
+--- a/drivers/extcon/extcon.c
++++ b/drivers/extcon/extcon.c
+@@ -196,6 +196,10 @@ static const 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 a0996a6d79039d5b6f0692dd35faa2cef61e28c6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Jun 2023 09:41:02 +0800
+Subject: f2fs: fix error path handling in truncate_dnode()
+
+From: Chao Yu <chao@kernel.org>
+
+[ Upstream commit 0135c482fa97e2fd8245cb462784112a00ed1211 ]
+
+If truncate_node() fails in truncate_dnode(), it missed to call
+f2fs_put_page(), fix it.
+
+Fixes: 7735730d39d7 ("f2fs: fix to propagate error from __get_meta_page()")
+Signed-off-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/node.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
+index b080d5c58f6cb..8256a2dedae8c 100644
+--- a/fs/f2fs/node.c
++++ b/fs/f2fs/node.c
+@@ -889,8 +889,10 @@ static int truncate_dnode(struct dnode_of_data *dn)
+ dn->ofs_in_node = 0;
+ f2fs_truncate_data_blocks(dn);
+ err = truncate_node(dn);
+- if (err)
++ if (err) {
++ f2fs_put_page(page, 1);
+ return err;
++ }
+
+ return 1;
+ }
+--
+2.39.2
+
--- /dev/null
+From 55e0d2495f220a9481e73f0e53e8223c51ae11e2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Aug 2021 23:41:42 +0200
+Subject: i2c: xiic: Defer xiic_wakeup() and __xiic_start_xfer() in
+ xiic_process()
+
+From: Marek Vasut <marex@denx.de>
+
+[ Upstream commit 743e227a895923c37a333eb2ebf3e391f00c406d ]
+
+The __xiic_start_xfer() manipulates the interrupt flags, xiic_wakeup()
+may result in return from xiic_xfer() early. Defer both to the end of
+the xiic_process() interrupt thread, so that they are executed after
+all the other interrupt bits handling completed and once it completely
+safe to perform changes to the interrupt bits in the hardware.
+
+Signed-off-by: Marek Vasut <marex@denx.de>
+Acked-by: Michal Simek <michal.simek@xilinx.com>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Stable-dep-of: cb6e45c9a0ad ("i2c: xiic: Don't try to handle more interrupt events after error")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/busses/i2c-xiic.c | 37 ++++++++++++++++++++++++-----------
+ 1 file changed, 26 insertions(+), 11 deletions(-)
+
+diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
+index c92ea6990ec69..c3fcaf5decc74 100644
+--- a/drivers/i2c/busses/i2c-xiic.c
++++ b/drivers/i2c/busses/i2c-xiic.c
+@@ -353,6 +353,9 @@ static irqreturn_t xiic_process(int irq, void *dev_id)
+ struct xiic_i2c *i2c = dev_id;
+ u32 pend, isr, ier;
+ u32 clr = 0;
++ int xfer_more = 0;
++ int wakeup_req = 0;
++ int wakeup_code = 0;
+
+ /* Get the interrupt Status from the IPIF. There is no clearing of
+ * interrupts in the IPIF. Interrupts must be cleared at the source.
+@@ -389,10 +392,14 @@ static irqreturn_t xiic_process(int irq, void *dev_id)
+ */
+ xiic_reinit(i2c);
+
+- if (i2c->rx_msg)
+- xiic_wakeup(i2c, STATE_ERROR);
+- if (i2c->tx_msg)
+- xiic_wakeup(i2c, STATE_ERROR);
++ if (i2c->rx_msg) {
++ wakeup_req = 1;
++ wakeup_code = STATE_ERROR;
++ }
++ if (i2c->tx_msg) {
++ wakeup_req = 1;
++ wakeup_code = STATE_ERROR;
++ }
+ }
+ if (pend & XIIC_INTR_RX_FULL_MASK) {
+ /* Receive register/FIFO is full */
+@@ -426,8 +433,7 @@ static irqreturn_t xiic_process(int irq, void *dev_id)
+ i2c->tx_msg++;
+ dev_dbg(i2c->adap.dev.parent,
+ "%s will start next...\n", __func__);
+-
+- __xiic_start_xfer(i2c);
++ xfer_more = 1;
+ }
+ }
+ }
+@@ -441,11 +447,13 @@ static irqreturn_t xiic_process(int irq, void *dev_id)
+ if (!i2c->tx_msg)
+ goto out;
+
+- if ((i2c->nmsgs == 1) && !i2c->rx_msg &&
+- xiic_tx_space(i2c) == 0)
+- xiic_wakeup(i2c, STATE_DONE);
++ wakeup_req = 1;
++
++ if (i2c->nmsgs == 1 && !i2c->rx_msg &&
++ xiic_tx_space(i2c) == 0)
++ wakeup_code = STATE_DONE;
+ else
+- xiic_wakeup(i2c, STATE_ERROR);
++ wakeup_code = STATE_ERROR;
+ }
+ if (pend & (XIIC_INTR_TX_EMPTY_MASK | XIIC_INTR_TX_HALF_MASK)) {
+ /* Transmit register/FIFO is empty or ½ empty */
+@@ -469,7 +477,7 @@ static irqreturn_t xiic_process(int irq, void *dev_id)
+ if (i2c->nmsgs > 1) {
+ i2c->nmsgs--;
+ i2c->tx_msg++;
+- __xiic_start_xfer(i2c);
++ xfer_more = 1;
+ } else {
+ xiic_irq_dis(i2c, XIIC_INTR_TX_HALF_MASK);
+
+@@ -487,6 +495,13 @@ static irqreturn_t xiic_process(int irq, void *dev_id)
+ dev_dbg(i2c->adap.dev.parent, "%s clr: 0x%x\n", __func__, clr);
+
+ xiic_setreg32(i2c, XIIC_IISR_OFFSET, clr);
++ if (xfer_more)
++ __xiic_start_xfer(i2c);
++ if (wakeup_req)
++ xiic_wakeup(i2c, wakeup_code);
++
++ WARN_ON(xfer_more && wakeup_req);
++
+ mutex_unlock(&i2c->lock);
+ return IRQ_HANDLED;
+ }
+--
+2.39.2
+
--- /dev/null
+From d7a67b251fc7714cdcc0a35f0488138fc6a21c3d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 6 Jun 2023 12:25:58 -0600
+Subject: i2c: xiic: Don't try to handle more interrupt events after error
+
+From: Robert Hancock <robert.hancock@calian.com>
+
+[ Upstream commit cb6e45c9a0ad9e0f8664fd06db0227d185dc76ab ]
+
+In xiic_process, it is possible that error events such as arbitration
+lost or TX error can be raised in conjunction with other interrupt flags
+such as TX FIFO empty or bus not busy. Error events result in the
+controller being reset and the error returned to the calling request,
+but the function could potentially try to keep handling the other
+events, such as by writing more messages into the TX FIFO. Since the
+transaction has already failed, this is not helpful and will just cause
+issues.
+
+This problem has been present ever since:
+
+commit 7f9906bd7f72 ("i2c: xiic: Service all interrupts in isr")
+
+which allowed non-error events to be handled after errors, but became
+more obvious after:
+
+commit 743e227a8959 ("i2c: xiic: Defer xiic_wakeup() and
+__xiic_start_xfer() in xiic_process()")
+
+which reworked the code to add a WARN_ON which triggers if both the
+xfer_more and wakeup_req flags were set, since this combination is
+not supposed to happen, but was occurring in this scenario.
+
+Skip further interrupt handling after error flags are detected to avoid
+this problem.
+
+Fixes: 7f9906bd7f72 ("i2c: xiic: Service all interrupts in isr")
+Signed-off-by: Robert Hancock <robert.hancock@calian.com>
+Acked-by: Andi Shyti <andi.shyti@kernel.org>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/busses/i2c-xiic.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
+index c3fcaf5decc74..6bcb46cc28cdf 100644
+--- a/drivers/i2c/busses/i2c-xiic.c
++++ b/drivers/i2c/busses/i2c-xiic.c
+@@ -400,6 +400,8 @@ static irqreturn_t xiic_process(int irq, void *dev_id)
+ wakeup_req = 1;
+ wakeup_code = STATE_ERROR;
+ }
++ /* don't try to handle other events */
++ goto out;
+ }
+ if (pend & XIIC_INTR_RX_FULL_MASK) {
+ /* Receive register/FIFO is full */
+--
+2.39.2
+
--- /dev/null
+From cb77bd4b66fc12acc2a600a8707bcb76709d84d9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 24 Mar 2023 15:54:23 +0100
+Subject: KVM: s390: fix KVM_S390_GET_CMMA_BITS for GFNs in memslot holes
+
+From: Nico Boehr <nrb@linux.ibm.com>
+
+[ Upstream commit 285cff4c0454340a4dc53f46e67f2cb1c293bd74 ]
+
+The KVM_S390_GET_CMMA_BITS ioctl may return incorrect values when userspace
+specifies a start_gfn outside of memslots.
+
+This can occur when a VM has multiple memslots with a hole in between:
+
++-----+----------+--------+--------+
+| ... | Slot N-1 | <hole> | Slot N |
++-----+----------+--------+--------+
+ ^ ^ ^ ^
+ | | | |
+GFN A A+B | |
+ A+B+C |
+ A+B+C+D
+
+When userspace specifies a GFN in [A+B, A+B+C), it would expect to get the
+CMMA values of the first dirty page in Slot N. However, userspace may get a
+start_gfn of A+B+C+D with a count of 0, hence completely skipping over any
+dirty pages in slot N.
+
+The error is in kvm_s390_next_dirty_cmma(), which assumes
+gfn_to_memslot_approx() will return the memslot _below_ the specified GFN
+when the specified GFN lies outside a memslot. In reality it may return
+either the memslot below or above the specified GFN.
+
+When a memslot above the specified GFN is returned this happens:
+
+- ofs is calculated, but since the memslot's base_gfn is larger than the
+ specified cur_gfn, ofs will underflow to a huge number.
+- ofs is passed to find_next_bit(). Since ofs will exceed the memslot's
+ number of pages, the number of pages in the memslot is returned,
+ completely skipping over all bits in the memslot userspace would be
+ interested in.
+
+Fix this by resetting ofs to zero when a memslot _above_ cur_gfn is
+returned (cur_gfn < ms->base_gfn).
+
+Signed-off-by: Nico Boehr <nrb@linux.ibm.com>
+Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
+Fixes: afdad61615cc ("KVM: s390: Fix storage attributes migration with memory slots")
+Message-Id: <20230324145424.293889-2-nrb@linux.ibm.com>
+Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
+Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/s390/kvm/kvm-s390.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
+index 9ade970b4232c..b11eb11e2f499 100644
+--- a/arch/s390/kvm/kvm-s390.c
++++ b/arch/s390/kvm/kvm-s390.c
+@@ -1982,6 +1982,10 @@ static unsigned long kvm_s390_next_dirty_cmma(struct kvm_memslots *slots,
+ ms = slots->memslots + slotidx;
+ ofs = 0;
+ }
++
++ if (cur_gfn < ms->base_gfn)
++ ofs = 0;
++
+ ofs = find_next_bit(kvm_second_dirty_bitmap(ms), ms->npages, ofs);
+ while ((slotidx > 0) && (ofs >= ms->npages)) {
+ slotidx--;
+--
+2.39.2
+
--- /dev/null
+From c4264d6cc6f7858a46495b03a0db4ec4a29c4037 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 10 May 2023 17:42:58 +0200
+Subject: KVM: s390: vsie: fix the length of APCB bitmap
+
+From: Pierre Morel <pmorel@linux.ibm.com>
+
+[ Upstream commit 246be7d2720ea9a795b576067ecc5e5c7a1e7848 ]
+
+bit_and() uses the count of bits as the woking length.
+Fix the previous implementation and effectively use
+the right bitmap size.
+
+Fixes: 19fd83a64718 ("KVM: s390: vsie: allow CRYCB FORMAT-1")
+Fixes: 56019f9aca22 ("KVM: s390: vsie: Allow CRYCB FORMAT-2")
+
+Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
+Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
+Link: https://lore.kernel.org/kvm/20230511094719.9691-1-pmorel@linux.ibm.com/
+Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/s390/kvm/vsie.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
+index 2021946176de8..596b2a2cd837d 100644
+--- a/arch/s390/kvm/vsie.c
++++ b/arch/s390/kvm/vsie.c
+@@ -168,7 +168,8 @@ static int setup_apcb00(struct kvm_vcpu *vcpu, unsigned long *apcb_s,
+ sizeof(struct kvm_s390_apcb0)))
+ return -EFAULT;
+
+- bitmap_and(apcb_s, apcb_s, apcb_h, sizeof(struct kvm_s390_apcb0));
++ bitmap_and(apcb_s, apcb_s, apcb_h,
++ BITS_PER_BYTE * sizeof(struct kvm_s390_apcb0));
+
+ return 0;
+ }
+@@ -190,7 +191,8 @@ static int setup_apcb11(struct kvm_vcpu *vcpu, unsigned long *apcb_s,
+ sizeof(struct kvm_s390_apcb1)))
+ return -EFAULT;
+
+- bitmap_and(apcb_s, apcb_s, apcb_h, sizeof(struct kvm_s390_apcb1));
++ bitmap_and(apcb_s, apcb_s, apcb_h,
++ BITS_PER_BYTE * sizeof(struct kvm_s390_apcb1));
+
+ return 0;
+ }
+--
+2.39.2
+
--- /dev/null
+From a8083ee00dc4d6595c0a634260449f797bcdd366 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 88047d835211c..75f14b624ca22 100644
+--- a/drivers/mailbox/ti-msgmgr.c
++++ b/drivers/mailbox/ti-msgmgr.c
+@@ -385,14 +385,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 54ce570329203390e86373b3875d5bf0938dafc4 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 62ee09f28a0bc..7524c90f5da61 100644
+--- a/drivers/media/usb/dvb-usb-v2/az6007.c
++++ b/drivers/media/usb/dvb-usb-v2/az6007.c
+@@ -202,7 +202,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 057ff1636f13fca736945002ddf4cfb43fe34455 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 1db232a1063b9..0358cd1043877 100644
+--- a/drivers/media/usb/siano/smsusb.c
++++ b/drivers/media/usb/siano/smsusb.c
+@@ -179,7 +179,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 fb57ae911c10a867ad28a6a7a06a71d090d2743e 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 9c89429f31130..895c5ba8b6ac2 100644
+--- a/include/uapi/linux/videodev2.h
++++ b/include/uapi/linux/videodev2.h
+@@ -1588,7 +1588,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 af1c829097481553d8ee46d138ffa2d5092f1853 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 045cbf0cbe53a..993e305a232c5 100644
+--- a/drivers/mfd/intel-lpss-acpi.c
++++ b/drivers/mfd/intel-lpss-acpi.c
+@@ -114,6 +114,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 e483912baac0162b153ccacef1795deddba084b3 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 48381d9bf7403..302115dabff4b 100644
+--- a/drivers/mfd/rt5033.c
++++ b/drivers/mfd/rt5033.c
+@@ -41,9 +41,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 cd60fdba993d9121829a5c238c770ac00059be33 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 9 Jun 2023 11:28:03 +0200
+Subject: mfd: stmfx: Fix error path in stmfx_chip_init
+
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+
+[ Upstream commit f592cf624531286f8b52e40dcfc157a5a7fb115c ]
+
+In error path, disable vdd regulator if it exists, but don't overload ret.
+Because if regulator_disable() is successful, stmfx_chip_init will exit
+successfully while chip init failed.
+
+Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver")
+Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Link: https://lore.kernel.org/r/20230609092804.793100-1-amelie.delaunay@foss.st.com
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mfd/stmfx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/mfd/stmfx.c b/drivers/mfd/stmfx.c
+index 711979afd90a0..887c92342b7f1 100644
+--- a/drivers/mfd/stmfx.c
++++ b/drivers/mfd/stmfx.c
+@@ -389,7 +389,7 @@ static int stmfx_chip_init(struct i2c_client *client)
+
+ err:
+ if (stmfx->vdd)
+- return regulator_disable(stmfx->vdd);
++ regulator_disable(stmfx->vdd);
+
+ return ret;
+ }
+--
+2.39.2
+
--- /dev/null
+From 4cced9c67cdd53f56e8dc8831dfa79e533aabac0 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 508349399f8af..7f758fb60c1fa 100644
+--- a/drivers/mfd/stmpe.c
++++ b/drivers/mfd/stmpe.c
+@@ -1494,9 +1494,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);
+
+ __stmpe_disable(stmpe, STMPE_BLOCK_ADC);
+--
+2.39.2
+
--- /dev/null
+From cb8c2d1ecf895f8c6b83f645391b1b44b542dd28 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 e2a999890d05e..6b650dfc084dc 100644
+--- a/net/bridge/br_if.c
++++ b/net/bridge/br_if.c
+@@ -157,8 +157,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 a257ddee39cf9408c9cb6c4787c307bb85880c66 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 4 Jul 2023 01:05:44 +0300
+Subject: net: dsa: tag_sja1105: fix MAC DA patching from meta frames
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit 1dcf6efd5f0c1f4496b3ef7ec5a7db104a53b38c ]
+
+The SJA1105 manual says that at offset 4 into the meta frame payload we
+have "MAC destination byte 2" and at offset 5 we have "MAC destination
+byte 1". These are counted from the LSB, so byte 1 is h_dest[ETH_HLEN-2]
+aka h_dest[4] and byte 2 is h_dest[ETH_HLEN-3] aka h_dest[3].
+
+The sja1105_meta_unpack() function decodes these the other way around,
+so a frame with MAC DA 01:80:c2:11:22:33 is received by the network
+stack as having 01:80:c2:22:11:33.
+
+Fixes: e53e18a6fe4d ("net: dsa: sja1105: Receive and decode meta frames")
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Reviewed-by: Simon Horman <simon.horman@corigine.com>
+Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/dsa/tag_sja1105.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/dsa/tag_sja1105.c b/net/dsa/tag_sja1105.c
+index 12f3ce52e62eb..836a75030a520 100644
+--- a/net/dsa/tag_sja1105.c
++++ b/net/dsa/tag_sja1105.c
+@@ -48,8 +48,8 @@ static void sja1105_meta_unpack(const struct sk_buff *skb,
+ * a unified unpacking command for both device series.
+ */
+ packing(buf, &meta->tstamp, 31, 0, 4, UNPACK, 0);
+- packing(buf + 4, &meta->dmac_byte_4, 7, 0, 1, UNPACK, 0);
+- packing(buf + 5, &meta->dmac_byte_3, 7, 0, 1, UNPACK, 0);
++ packing(buf + 4, &meta->dmac_byte_3, 7, 0, 1, UNPACK, 0);
++ packing(buf + 5, &meta->dmac_byte_4, 7, 0, 1, UNPACK, 0);
+ packing(buf + 6, &meta->source_port, 7, 0, 1, UNPACK, 0);
+ packing(buf + 7, &meta->switch_id, 7, 0, 1, UNPACK, 0);
+ }
+--
+2.39.2
+
--- /dev/null
+From c6d4942bfabd5aa6bc717e23b0f0fa6a5fd3166f 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 f095a0fb75c6d..bf74f3f4c7522 100644
+--- a/net/sched/act_pedit.c
++++ b/net/sched/act_pedit.c
+@@ -26,6 +26,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 6a3c1b16314d82eaae596f572e79085f899c7632 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 2ca9114fcf002..0c8436b06c494 100644
+--- a/arch/powerpc/Kconfig.debug
++++ b/arch/powerpc/Kconfig.debug
+@@ -234,7 +234,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 a92b7ac7410e183bb2f6e41d0f3746d835de0c68 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 5 May 2023 14:58:39 +0800
+Subject: pwm: imx-tpm: force 'real_period' to be zero in suspend
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Fancy Fang <chen.fang@nxp.com>
+
+[ Upstream commit 661dfb7f46298e53f6c3deaa772fa527aae86193 ]
+
+During suspend, all the tpm registers will lose values.
+So the 'real_period' value of struct 'imx_tpm_pwm_chip'
+should be forced to be zero to force the period update
+code can be executed after system resume back.
+
+Signed-off-by: Fancy Fang <chen.fang@nxp.com>
+Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
+Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Fixes: 738a1cfec2ed ("pwm: Add i.MX TPM PWM driver support")
+Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pwm/pwm-imx-tpm.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c
+index 9145f61606497..85aad55b7a8f0 100644
+--- a/drivers/pwm/pwm-imx-tpm.c
++++ b/drivers/pwm/pwm-imx-tpm.c
+@@ -405,6 +405,13 @@ static int __maybe_unused pwm_imx_tpm_suspend(struct device *dev)
+ if (tpm->enable_count > 0)
+ return -EBUSY;
+
++ /*
++ * Force 'real_period' to be zero to force period update code
++ * can be executed after system resume back, since suspend causes
++ * the period related registers to become their reset values.
++ */
++ tpm->real_period = 0;
++
+ clk_disable_unprepare(tpm->clk);
+
+ return 0;
+--
+2.39.2
+
--- /dev/null
+From fa6912a8dd82c69bf7e1b9dda0dc7ce9cc0170fe Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 12 May 2023 18:47:36 +0200
+Subject: pwm: sysfs: Do not apply state to already disabled PWMs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marek Vasut <marex@denx.de>
+
+[ Upstream commit 38ba83598633373f47951384cfc389181c8d1bed ]
+
+If the PWM is exported but not enabled, do not call pwm_class_apply_state().
+First of all, in this case, period may still be unconfigured and this would
+make pwm_class_apply_state() return -EINVAL, and then suspend would fail.
+Second, it makes little sense to apply state onto PWM that is not enabled
+before suspend.
+
+Failing case:
+"
+$ echo 1 > /sys/class/pwm/pwmchip4/export
+$ echo mem > /sys/power/state
+...
+pwm pwmchip4: PM: dpm_run_callback(): pwm_class_suspend+0x1/0xa8 returns -22
+pwm pwmchip4: PM: failed to suspend: error -22
+PM: Some devices failed to suspend, or early wake event detected
+"
+
+Working case:
+"
+$ echo 1 > /sys/class/pwm/pwmchip4/export
+$ echo 100 > /sys/class/pwm/pwmchip4/pwm1/period
+$ echo 10 > /sys/class/pwm/pwmchip4/pwm1/duty_cycle
+$ echo mem > /sys/power/state
+...
+"
+
+Do not call pwm_class_apply_state() in case the PWM is disabled
+to fix this issue.
+
+Fixes: 7fd4edc57bbae ("pwm: sysfs: Add suspend/resume support")
+Signed-off-by: Marek Vasut <marex@denx.de>
+Fixes: ef2bf4997f7d ("pwm: Improve args checking in pwm_apply_state()")
+Reviewed-by: Brian Norris <briannorris@chromium.org>
+Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pwm/sysfs.c | 17 +++++++++++++++++
+ 1 file changed, 17 insertions(+)
+
+diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
+index 2389b86698468..986f3a29a13d5 100644
+--- a/drivers/pwm/sysfs.c
++++ b/drivers/pwm/sysfs.c
+@@ -424,6 +424,13 @@ static int pwm_class_resume_npwm(struct device *parent, unsigned int npwm)
+ if (!export)
+ continue;
+
++ /* If pwmchip was not enabled before suspend, do nothing. */
++ if (!export->suspend.enabled) {
++ /* release lock taken in pwm_class_get_state */
++ mutex_unlock(&export->lock);
++ continue;
++ }
++
+ state.enabled = export->suspend.enabled;
+ ret = pwm_class_apply_state(export, pwm, &state);
+ if (ret < 0)
+@@ -448,7 +455,17 @@ static int __maybe_unused pwm_class_suspend(struct device *parent)
+ if (!export)
+ continue;
+
++ /*
++ * If pwmchip was not enabled before suspend, save
++ * state for resume time and do nothing else.
++ */
+ export->suspend = state;
++ if (!state.enabled) {
++ /* release lock taken in pwm_class_get_state */
++ mutex_unlock(&export->lock);
++ continue;
++ }
++
+ state.enabled = false;
+ ret = pwm_class_apply_state(export, pwm, &state);
+ if (ret < 0) {
+--
+2.39.2
+
--- /dev/null
+From 8c82f084a7d7497bc68e19dd0dba3712c6515447 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 27261b020f8dd..2031d042c5e44 100644
+--- a/drivers/rtc/rtc-st-lpc.c
++++ b/drivers/rtc/rtc-st-lpc.c
+@@ -231,7 +231,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 a6f7a997392fb2d43f8c55c7b2bda3e3cfc93ba0 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 bf3fed5b91d2b..7cff1a031f761 100644
+--- a/net/sctp/socket.c
++++ b/net/sctp/socket.c
+@@ -362,9 +362,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
+
--- /dev/null
+From 80745984ddc2e5e98f17784c2a91d4af61ddeca5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 14 Jun 2023 07:59:19 +0300
+Subject: serial: 8250_omap: Use force_suspend and resume for system suspend
+
+From: Tony Lindgren <tony@atomide.com>
+
+[ Upstream commit 20a41a62618df85f3a2981008edec5cadd785e0a ]
+
+We should not rely on autosuspend timeout for system suspend. Instead,
+let's use force_suspend and force_resume functions. Otherwise the serial
+port controller device may not be idled on suspend.
+
+As we are doing a register write on suspend to configure the serial port,
+we still need to runtime PM resume the port on suspend.
+
+While at it, let's switch to pm_runtime_resume_and_get() and check for
+errors returned. And let's add the missing line break before return to the
+suspend function while at it.
+
+Fixes: 09d8b2bdbc5c ("serial: 8250: omap: Provide ability to enable/disable UART as wakeup source")
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Tested-by: Dhruva Gole <d-gole@ti.com>
+Message-ID: <20230614045922.4798-1-tony@atomide.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/8250/8250_omap.c | 20 +++++++++++++++-----
+ 1 file changed, 15 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
+index 928b35b87dcf3..a2db055278a17 100644
+--- a/drivers/tty/serial/8250/8250_omap.c
++++ b/drivers/tty/serial/8250/8250_omap.c
+@@ -1314,25 +1314,35 @@ static int omap8250_suspend(struct device *dev)
+ {
+ struct omap8250_priv *priv = dev_get_drvdata(dev);
+ struct uart_8250_port *up = serial8250_get_port(priv->line);
++ int err;
+
+ serial8250_suspend_port(priv->line);
+
+- pm_runtime_get_sync(dev);
++ err = pm_runtime_resume_and_get(dev);
++ if (err)
++ return err;
+ if (!device_may_wakeup(dev))
+ priv->wer = 0;
+ serial_out(up, UART_OMAP_WER, priv->wer);
+- pm_runtime_mark_last_busy(dev);
+- pm_runtime_put_autosuspend(dev);
+-
++ err = pm_runtime_force_suspend(dev);
+ flush_work(&priv->qos_work);
+- return 0;
++
++ return err;
+ }
+
+ static int omap8250_resume(struct device *dev)
+ {
+ struct omap8250_priv *priv = dev_get_drvdata(dev);
++ int err;
+
++ err = pm_runtime_force_resume(dev);
++ if (err)
++ return err;
+ serial8250_resume_port(priv->line);
++ /* Paired with pm_runtime_resume_and_get() in omap8250_suspend() */
++ pm_runtime_mark_last_busy(dev);
++ pm_runtime_put_autosuspend(dev);
++
+ return 0;
+ }
+ #else
+--
+2.39.2
+
usb-dwc3-gadget-propagate-core-init-errors-to-udc-during-pullup.patch
block-fix-signed-int-overflow-in-amiga-partition-support.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
+usb-dwc3-qcom-fix-potential-memory-leak.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
+usb-hide-unused-usbfs_notify_suspend-resume-function.patch
+mfd-rt5033-drop-rt5033-battery-sub-device.patch
+kvm-s390-fix-kvm_s390_get_cmma_bits-for-gfns-in-mems.patch
+software-node-introduce-device_add_software_node.patch
+usb-dwc3-qcom-constify-the-software-node.patch
+usb-dwc3-qcom-release-the-correct-resources-in-dwc3_.patch
+mfd-intel-lpss-add-missing-check-for-platform_get_re.patch
+serial-8250_omap-use-force_suspend-and-resume-for-sy.patch
+mfd-stmfx-fix-error-path-in-stmfx_chip_init.patch
+kvm-s390-vsie-fix-the-length-of-apcb-bitmap.patch
+mfd-stmpe-only-disable-the-regulators-if-they-are-en.patch
+pwm-imx-tpm-force-real_period-to-be-zero-in-suspend.patch
+pwm-sysfs-do-not-apply-state-to-already-disabled-pwm.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
+f2fs-fix-error-path-handling-in-truncate_dnode.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
+xsk-improve-documentation-for-af_xdp.patch
+xsk-honor-so_bindtodevice-on-bind.patch
+net-sched-act_pedit-add-size-check-for-tca_pedit_par.patch
+net-dsa-tag_sja1105-fix-mac-da-patching-from-meta-fr.patch
+sh-dma-fix-dma-channel-offset-calculation.patch
+i2c-xiic-defer-xiic_wakeup-and-__xiic_start_xfer-in-.patch
+i2c-xiic-don-t-try-to-handle-more-interrupt-events-a.patch
--- /dev/null
+From 0b15731deafacf13c37fa4409c56568222978b95 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 96c626c2cd0a4..306fba1564e5e 100644
+--- a/arch/sh/drivers/dma/dma-sh.c
++++ b/arch/sh/drivers/dma/dma-sh.c
+@@ -18,6 +18,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.
+@@ -29,7 +41,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
+
+@@ -40,13 +52,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
+@@ -250,12 +262,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 5e5c6c3b152e912c822ba227130d0d57b0b214b4 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 d342ea08843f6..70a07f4f2142f 100644
+--- a/arch/sh/kernel/cpu/sh2/probe.c
++++ b/arch/sh/kernel/cpu/sh2/probe.c
+@@ -21,7 +21,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 77739841c2046e7a2820af8201754478ddbe4686 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 15 Jan 2021 12:49:11 +0300
+Subject: software node: Introduce device_add_software_node()
+
+From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+
+[ Upstream commit e68d0119e3284334de5650a1ac42ef4e179f895e ]
+
+This helper will register a software node and then assign
+it to device at the same time. The function will also make
+sure that the device can't have more than one software node.
+
+Acked-by: Felipe Balbi <balbi@kernel.org>
+Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20210115094914.88401-2-heikki.krogerus@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Stable-dep-of: 8fd95da2cfb5 ("usb: dwc3: qcom: Release the correct resources in dwc3_qcom_remove()")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/base/swnode.c | 71 +++++++++++++++++++++++++++++++++++-----
+ include/linux/property.h | 3 ++
+ 2 files changed, 65 insertions(+), 9 deletions(-)
+
+diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
+index 4c3b9813b2843..4f9c6898e86e8 100644
+--- a/drivers/base/swnode.c
++++ b/drivers/base/swnode.c
+@@ -48,6 +48,19 @@ EXPORT_SYMBOL_GPL(is_software_node);
+ struct swnode, fwnode) : NULL; \
+ })
+
++static inline struct swnode *dev_to_swnode(struct device *dev)
++{
++ struct fwnode_handle *fwnode = dev_fwnode(dev);
++
++ if (!fwnode)
++ return NULL;
++
++ if (!is_software_node(fwnode))
++ fwnode = fwnode->secondary;
++
++ return to_swnode(fwnode);
++}
++
+ static struct swnode *
+ software_node_to_swnode(const struct software_node *node)
+ {
+@@ -862,22 +875,62 @@ void fwnode_remove_software_node(struct fwnode_handle *fwnode)
+ }
+ EXPORT_SYMBOL_GPL(fwnode_remove_software_node);
+
++/**
++ * device_add_software_node - Assign software node to a device
++ * @dev: The device the software node is meant for.
++ * @swnode: The software node.
++ *
++ * This function will register @swnode and make it the secondary firmware node
++ * pointer of @dev. If @dev has no primary node, then @swnode will become the primary
++ * node.
++ */
++int device_add_software_node(struct device *dev, const struct software_node *swnode)
++{
++ int ret;
++
++ /* Only one software node per device. */
++ if (dev_to_swnode(dev))
++ return -EBUSY;
++
++ ret = software_node_register(swnode);
++ if (ret)
++ return ret;
++
++ set_secondary_fwnode(dev, software_node_fwnode(swnode));
++
++ return 0;
++}
++EXPORT_SYMBOL_GPL(device_add_software_node);
++
++/**
++ * device_remove_software_node - Remove device's software node
++ * @dev: The device with the software node.
++ *
++ * This function will unregister the software node of @dev.
++ */
++void device_remove_software_node(struct device *dev)
++{
++ struct swnode *swnode;
++
++ swnode = dev_to_swnode(dev);
++ if (!swnode)
++ return;
++
++ software_node_notify(dev, KOBJ_REMOVE);
++ set_secondary_fwnode(dev, NULL);
++ kobject_put(&swnode->kobj);
++}
++EXPORT_SYMBOL_GPL(device_remove_software_node);
++
+ int software_node_notify(struct device *dev, unsigned long action)
+ {
+- struct fwnode_handle *fwnode = dev_fwnode(dev);
+ struct swnode *swnode;
+ int ret;
+
+- if (!fwnode)
+- return 0;
+-
+- if (!is_software_node(fwnode))
+- fwnode = fwnode->secondary;
+- if (!is_software_node(fwnode))
++ swnode = dev_to_swnode(dev);
++ if (!swnode)
+ return 0;
+
+- swnode = to_swnode(fwnode);
+-
+ switch (action) {
+ case KOBJ_ADD:
+ ret = sysfs_create_link(&dev->kobj, &swnode->kobj,
+diff --git a/include/linux/property.h b/include/linux/property.h
+index 9b3d4ca3a73a9..99fdafa20cd1d 100644
+--- a/include/linux/property.h
++++ b/include/linux/property.h
+@@ -437,4 +437,7 @@ fwnode_create_software_node(const struct property_entry *properties,
+ const struct fwnode_handle *parent);
+ void fwnode_remove_software_node(struct fwnode_handle *fwnode);
+
++int device_add_software_node(struct device *dev, const struct software_node *swnode);
++void device_remove_software_node(struct device *dev);
++
+ #endif /* _LINUX_PROPERTY_H_ */
+--
+2.39.2
+
--- /dev/null
+From 5eac33d10c2667b17f978abbd37d508c4a697e90 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 d933a6eda5fdc..118d9161a7886 100644
+--- a/drivers/spi/spi-bcm-qspi.c
++++ b/drivers/spi/spi-bcm-qspi.c
+@@ -1250,13 +1250,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 18c2a5a44f150dbf7f29d80f288aeb6d5c6d88bc 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 44398317f033a..8308c3c3a6e46 100644
+--- a/net/ipv4/tcp_input.c
++++ b/net/ipv4/tcp_input.c
+@@ -3445,8 +3445,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 < READ_ONCE(net->ipv4.sysctl_tcp_invalid_ratelimit)) {
+@@ -3455,7 +3458,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 69665dbcb9e352a15bab2cf25306e6f1c7addaa4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 4 Feb 2021 17:17:09 +0300
+Subject: usb: dwc3: qcom: Constify the software node
+
+From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+
+[ Upstream commit 8dc6e6dd1bee39cd65a232a17d51240fc65a0f4a ]
+
+What platform_device_add_properties() does is it allocates
+dynamically a software node that will contain the device
+properties supplied to it, and then couples that node with
+the device. If the properties are constant, the node can be
+constant as well.
+
+Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20210204141711.53775-5-heikki.krogerus@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Stable-dep-of: 8fd95da2cfb5 ("usb: dwc3: qcom: Release the correct resources in dwc3_qcom_remove()")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/dwc3/dwc3-qcom.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
+index 7d3de23147fd5..3662565642120 100644
+--- a/drivers/usb/dwc3/dwc3-qcom.c
++++ b/drivers/usb/dwc3/dwc3-qcom.c
+@@ -467,6 +467,10 @@ static const struct property_entry dwc3_qcom_acpi_properties[] = {
+ {}
+ };
+
++static const struct software_node dwc3_qcom_swnode = {
++ .properties = dwc3_qcom_acpi_properties,
++};
++
+ static int dwc3_qcom_acpi_register_core(struct platform_device *pdev)
+ {
+ struct dwc3_qcom *qcom = platform_get_drvdata(pdev);
+@@ -511,16 +515,17 @@ static int dwc3_qcom_acpi_register_core(struct platform_device *pdev)
+ goto out;
+ }
+
+- ret = platform_device_add_properties(qcom->dwc3,
+- dwc3_qcom_acpi_properties);
++ ret = device_add_software_node(&qcom->dwc3->dev, &dwc3_qcom_swnode);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to add properties\n");
+ goto out;
+ }
+
+ ret = platform_device_add(qcom->dwc3);
+- if (ret)
++ if (ret) {
+ dev_err(&pdev->dev, "failed to add device\n");
++ device_remove_software_node(&qcom->dwc3->dev);
++ }
+
+ out:
+ kfree(child_res);
+@@ -707,6 +712,7 @@ static int dwc3_qcom_remove(struct platform_device *pdev)
+ struct device *dev = &pdev->dev;
+ int i;
+
++ device_remove_software_node(&qcom->dwc3->dev);
+ of_platform_depopulate(dev);
+
+ for (i = qcom->num_clocks - 1; i >= 0; i--) {
+--
+2.39.2
+
--- /dev/null
+From 0d77c20807fb276e36370300c4c66cda0f328b23 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 17 May 2023 20:25:18 +0300
+Subject: usb: dwc3: qcom: Fix potential memory leak
+
+From: Vladislav Efanov <VEfanov@ispras.ru>
+
+[ Upstream commit 097fb3ee710d4de83b8d4f5589e8ee13e0f0541e ]
+
+Function dwc3_qcom_probe() allocates memory for resource structure
+which is pointed by parent_res pointer. This memory is not
+freed. This leads to memory leak. Use stack memory to prevent
+memory leak.
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE.
+
+Fixes: 2bc02355f8ba ("usb: dwc3: qcom: Add support for booting with ACPI")
+Signed-off-by: Vladislav Efanov <VEfanov@ispras.ru>
+Acked-by: Shawn Guo <shawn.guo@linaro.org>
+Link: https://lore.kernel.org/r/20230517172518.442591-1-VEfanov@ispras.ru
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/dwc3/dwc3-qcom.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
+index 2dcdeb52fc293..7d3de23147fd5 100644
+--- a/drivers/usb/dwc3/dwc3-qcom.c
++++ b/drivers/usb/dwc3/dwc3-qcom.c
+@@ -574,6 +574,7 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
+ struct device *dev = &pdev->dev;
+ struct dwc3_qcom *qcom;
+ struct resource *res, *parent_res = NULL;
++ struct resource local_res;
+ int ret, i;
+ bool ignore_pipe_clk;
+
+@@ -624,9 +625,8 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
+ if (np) {
+ parent_res = res;
+ } else {
+- parent_res = kmemdup(res, sizeof(struct resource), GFP_KERNEL);
+- if (!parent_res)
+- return -ENOMEM;
++ memcpy(&local_res, res, sizeof(struct resource));
++ parent_res = &local_res;
+
+ parent_res->start = res->start +
+ qcom->acpi_pdata->qscratch_base_offset;
+--
+2.39.2
+
--- /dev/null
+From 0111895332a37f31641ebb0ee9d8090513358b8d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 4 Jun 2023 17:04:37 +0200
+Subject: usb: dwc3: qcom: Release the correct resources in dwc3_qcom_remove()
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+[ Upstream commit 8fd95da2cfb5046c4bb5a3cdc9eb7963ba8b10dd ]
+
+In the probe, some resources are allocated with
+dwc3_qcom_of_register_core() or dwc3_qcom_acpi_register_core(). The
+corresponding resources are already coorectly freed in the error handling
+path of the probe, but not in the remove function.
+
+Fix it.
+
+Fixes: 2bc02355f8ba ("usb: dwc3: qcom: Add support for booting with ACPI")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
+Message-ID: <c0215a84cdf18fb3514c81842783ec53cf149deb.1685891059.git.christophe.jaillet@wanadoo.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/dwc3/dwc3-qcom.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
+index 3662565642120..657ae26671d29 100644
+--- a/drivers/usb/dwc3/dwc3-qcom.c
++++ b/drivers/usb/dwc3/dwc3-qcom.c
+@@ -709,11 +709,15 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
+ static int dwc3_qcom_remove(struct platform_device *pdev)
+ {
+ struct dwc3_qcom *qcom = platform_get_drvdata(pdev);
++ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ int i;
+
+ device_remove_software_node(&qcom->dwc3->dev);
+- of_platform_depopulate(dev);
++ if (np)
++ of_platform_depopulate(&pdev->dev);
++ else
++ platform_device_put(pdev);
+
+ for (i = qcom->num_clocks - 1; i >= 0; i--) {
+ clk_disable_unprepare(qcom->clks[i]);
+--
+2.39.2
+
--- /dev/null
+From 882a68da590d8b5700ab16a88f2c6e06cb19395b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 16 May 2023 22:17:42 +0200
+Subject: usb: hide unused usbfs_notify_suspend/resume functions
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+[ Upstream commit 8e6bd945e6dde64fbc60ec3fe252164493a8d3a2 ]
+
+The declaration is in an #ifdef, which causes warnings when building
+with 'make W=1' and without CONFIG_PM:
+
+drivers/usb/core/devio.c:742:6: error: no previous prototype for 'usbfs_notify_suspend'
+drivers/usb/core/devio.c:747:6: error: no previous prototype for 'usbfs_notify_resume'
+
+Use the same #ifdef check around the function definitions to avoid
+the warnings and slightly shrink the USB core.
+
+Fixes: 7794f486ed0b ("usbfs: Add ioctls for runtime power management")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Link: https://lore.kernel.org/r/20230516202103.558301-1-arnd@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/core/devio.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
+index 44922e6381da6..087ab22488552 100644
+--- a/drivers/usb/core/devio.c
++++ b/drivers/usb/core/devio.c
+@@ -734,6 +734,7 @@ static int driver_resume(struct usb_interface *intf)
+ return 0;
+ }
+
++#ifdef CONFIG_PM
+ /* The following routines apply to the entire device, not interfaces */
+ void usbfs_notify_suspend(struct usb_device *udev)
+ {
+@@ -752,6 +753,7 @@ void usbfs_notify_resume(struct usb_device *udev)
+ }
+ mutex_unlock(&usbfs_mutex);
+ }
++#endif
+
+ struct usb_driver usbfs_driver = {
+ .name = "usbfs",
+--
+2.39.2
+
--- /dev/null
+From 8aa7a6d4305067f4b75c7f64661b981d72060166 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 a3e043e3e4aae..d0672b6712985 100644
+--- a/drivers/usb/phy/phy-tahvo.c
++++ b/drivers/usb/phy/phy-tahvo.c
+@@ -395,7 +395,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 34e6fe9641d5d7402b033346c99fd48cab3bd172 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 2a7970a10533e..e08f40c9d54c9 100644
+--- a/drivers/w1/w1.c
++++ b/drivers/w1/w1.c
+@@ -1228,10 +1228,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
+
--- /dev/null
+From 846711fa26e61e053082b3796fa85fc102d26a60 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 3 Jul 2023 19:53:29 +0200
+Subject: xsk: Honor SO_BINDTODEVICE on bind
+
+From: Ilya Maximets <i.maximets@ovn.org>
+
+[ Upstream commit f7306acec9aae9893d15e745c8791124d42ab10a ]
+
+Initial creation of an AF_XDP socket requires CAP_NET_RAW capability. A
+privileged process might create the socket and pass it to a non-privileged
+process for later use. However, that process will be able to bind the socket
+to any network interface. Even though it will not be able to receive any
+traffic without modification of the BPF map, the situation is not ideal.
+
+Sockets already have a mechanism that can be used to restrict what interface
+they can be attached to. That is SO_BINDTODEVICE.
+
+To change the SO_BINDTODEVICE binding the process will need CAP_NET_RAW.
+
+Make xsk_bind() honor the SO_BINDTODEVICE in order to allow safer workflow
+when non-privileged process is using AF_XDP.
+
+The intended workflow is following:
+
+ 1. First process creates a bare socket with socket(AF_XDP, ...).
+ 2. First process loads the XSK program to the interface.
+ 3. First process adds the socket fd to a BPF map.
+ 4. First process ties socket fd to a particular interface using
+ SO_BINDTODEVICE.
+ 5. First process sends socket fd to a second process.
+ 6. Second process allocates UMEM.
+ 7. Second process binds socket to the interface with bind(...).
+ 8. Second process sends/receives the traffic.
+
+All the steps above are possible today if the first process is privileged
+and the second one has sufficient RLIMIT_MEMLOCK and no capabilities.
+However, the second process will be able to bind the socket to any interface
+it wants on step 7 and send traffic from it. With the proposed change, the
+second process will be able to bind the socket only to a specific interface
+chosen by the first process at step 4.
+
+Fixes: 965a99098443 ("xsk: add support for bind for Rx")
+Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
+Acked-by: John Fastabend <john.fastabend@gmail.com>
+Acked-by: Jason Wang <jasowang@redhat.com>
+Link: https://lore.kernel.org/bpf/20230703175329.3259672-1-i.maximets@ovn.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ Documentation/networking/af_xdp.rst | 9 +++++++++
+ net/xdp/xsk.c | 5 +++++
+ 2 files changed, 14 insertions(+)
+
+diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst
+index 7a4caaaf3a179..09b3943b3b719 100644
+--- a/Documentation/networking/af_xdp.rst
++++ b/Documentation/networking/af_xdp.rst
+@@ -378,6 +378,15 @@ start N bytes into the buffer leaving the first N bytes for the
+ application to use. The final option is the flags field, but it will
+ be dealt with in separate sections for each UMEM flag.
+
++SO_BINDTODEVICE setsockopt
++--------------------------
++
++This is a generic SOL_SOCKET option that can be used to tie AF_XDP
++socket to a particular network interface. It is useful when a socket
++is created by a privileged process and passed to a non-privileged one.
++Once the option is set, kernel will refuse attempts to bind that socket
++to a different interface. Updating the value requires CAP_NET_RAW.
++
+ XDP_STATISTICS getsockopt
+ -------------------------
+
+diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
+index 2bc0d6e3e124c..d04a2345bc3f5 100644
+--- a/net/xdp/xsk.c
++++ b/net/xdp/xsk.c
+@@ -613,6 +613,7 @@ static int xsk_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
+ struct sock *sk = sock->sk;
+ struct xdp_sock *xs = xdp_sk(sk);
+ struct net_device *dev;
++ int bound_dev_if;
+ u32 flags, qid;
+ int err = 0;
+
+@@ -626,6 +627,10 @@ static int xsk_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
+ XDP_USE_NEED_WAKEUP))
+ return -EINVAL;
+
++ bound_dev_if = READ_ONCE(sk->sk_bound_dev_if);
++ if (bound_dev_if && bound_dev_if != sxdp->sxdp_ifindex)
++ return -EINVAL;
++
+ rtnl_lock();
+ mutex_lock(&xs->mutex);
+ if (xs->state != XSK_READY) {
+--
+2.39.2
+
--- /dev/null
+From 0465515ac2c363884f8310d98987d80ba1245e80 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 21 Oct 2019 10:57:04 +0200
+Subject: xsk: Improve documentation for AF_XDP
+
+From: Magnus Karlsson <magnus.karlsson@intel.com>
+
+[ Upstream commit e0e4f8e938c48b7c5377661fa3e4738901e6a19b ]
+
+Added sections on all the bind flags, libbpf, all the setsockopts and
+all the getsockopts. Also updated the document to reflect the latest
+features and to correct some spelling errors.
+
+v1 -> v2:
+* Updated XDP program with latest BTF map format
+* Added one more FAQ entry
+* Some minor edits and corrections
+
+v2 -> v3:
+* Simplified XDP_SHARED_UMEM example XDP program
+
+Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Link: https://lore.kernel.org/bpf/1571648224-16889-1-git-send-email-magnus.karlsson@intel.com
+Stable-dep-of: f7306acec9aa ("xsk: Honor SO_BINDTODEVICE on bind")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ Documentation/networking/af_xdp.rst | 259 +++++++++++++++++++++++++---
+ 1 file changed, 231 insertions(+), 28 deletions(-)
+
+diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst
+index 83f7ae5fc045e..7a4caaaf3a179 100644
+--- a/Documentation/networking/af_xdp.rst
++++ b/Documentation/networking/af_xdp.rst
+@@ -40,13 +40,13 @@ allocates memory for this UMEM using whatever means it feels is most
+ appropriate (malloc, mmap, huge pages, etc). This memory area is then
+ registered with the kernel using the new setsockopt XDP_UMEM_REG. The
+ UMEM also has two rings: the FILL ring and the COMPLETION ring. The
+-fill ring is used by the application to send down addr for the kernel
++FILL ring is used by the application to send down addr for the kernel
+ to fill in with RX packet data. References to these frames will then
+ appear in the RX ring once each packet has been received. The
+-completion ring, on the other hand, contains frame addr that the
++COMPLETION ring, on the other hand, contains frame addr that the
+ kernel has transmitted completely and can now be used again by user
+ space, for either TX or RX. Thus, the frame addrs appearing in the
+-completion ring are addrs that were previously transmitted using the
++COMPLETION ring are addrs that were previously transmitted using the
+ TX ring. In summary, the RX and FILL rings are used for the RX path
+ and the TX and COMPLETION rings are used for the TX path.
+
+@@ -91,11 +91,16 @@ Concepts
+ ========
+
+ In order to use an AF_XDP socket, a number of associated objects need
+-to be setup.
++to be setup. These objects and their options are explained in the
++following sections.
+
+-Jonathan Corbet has also written an excellent article on LWN,
+-"Accelerating networking with AF_XDP". It can be found at
+-https://lwn.net/Articles/750845/.
++For an overview on how AF_XDP works, you can also take a look at the
++Linux Plumbers paper from 2018 on the subject:
++http://vger.kernel.org/lpc_net2018_talks/lpc18_paper_af_xdp_perf-v2.pdf. Do
++NOT consult the paper from 2017 on "AF_PACKET v4", the first attempt
++at AF_XDP. Nearly everything changed since then. Jonathan Corbet has
++also written an excellent article on LWN, "Accelerating networking
++with AF_XDP". It can be found at https://lwn.net/Articles/750845/.
+
+ UMEM
+ ----
+@@ -113,22 +118,22 @@ the next socket B can do this by setting the XDP_SHARED_UMEM flag in
+ struct sockaddr_xdp member sxdp_flags, and passing the file descriptor
+ of A to struct sockaddr_xdp member sxdp_shared_umem_fd.
+
+-The UMEM has two single-producer/single-consumer rings, that are used
++The UMEM has two single-producer/single-consumer rings that are used
+ to transfer ownership of UMEM frames between the kernel and the
+ user-space application.
+
+ Rings
+ -----
+
+-There are a four different kind of rings: Fill, Completion, RX and
++There are a four different kind of rings: FILL, COMPLETION, RX and
+ TX. All rings are single-producer/single-consumer, so the user-space
+ application need explicit synchronization of multiple
+ processes/threads are reading/writing to them.
+
+-The UMEM uses two rings: Fill and Completion. Each socket associated
++The UMEM uses two rings: FILL and COMPLETION. Each socket associated
+ with the UMEM must have an RX queue, TX queue or both. Say, that there
+ is a setup with four sockets (all doing TX and RX). Then there will be
+-one Fill ring, one Completion ring, four TX rings and four RX rings.
++one FILL ring, one COMPLETION ring, four TX rings and four RX rings.
+
+ The rings are head(producer)/tail(consumer) based rings. A producer
+ writes the data ring at the index pointed out by struct xdp_ring
+@@ -146,7 +151,7 @@ The size of the rings need to be of size power of two.
+ UMEM Fill Ring
+ ~~~~~~~~~~~~~~
+
+-The Fill ring is used to transfer ownership of UMEM frames from
++The FILL ring is used to transfer ownership of UMEM frames from
+ user-space to kernel-space. The UMEM addrs are passed in the ring. As
+ an example, if the UMEM is 64k and each chunk is 4k, then the UMEM has
+ 16 chunks and can pass addrs between 0 and 64k.
+@@ -164,8 +169,8 @@ chunks mode, then the incoming addr will be left untouched.
+ UMEM Completion Ring
+ ~~~~~~~~~~~~~~~~~~~~
+
+-The Completion Ring is used transfer ownership of UMEM frames from
+-kernel-space to user-space. Just like the Fill ring, UMEM indicies are
++The COMPLETION Ring is used transfer ownership of UMEM frames from
++kernel-space to user-space. Just like the FILL ring, UMEM indices are
+ used.
+
+ Frames passed from the kernel to user-space are frames that has been
+@@ -181,7 +186,7 @@ The RX ring is the receiving side of a socket. Each entry in the ring
+ is a struct xdp_desc descriptor. The descriptor contains UMEM offset
+ (addr) and the length of the data (len).
+
+-If no frames have been passed to kernel via the Fill ring, no
++If no frames have been passed to kernel via the FILL ring, no
+ descriptors will (or can) appear on the RX ring.
+
+ The user application consumes struct xdp_desc descriptors from this
+@@ -199,8 +204,24 @@ be relaxed in the future.
+ The user application produces struct xdp_desc descriptors to this
+ ring.
+
++Libbpf
++======
++
++Libbpf is a helper library for eBPF and XDP that makes using these
++technologies a lot simpler. It also contains specific helper functions
++in tools/lib/bpf/xsk.h for facilitating the use of AF_XDP. It
++contains two types of functions: those that can be used to make the
++setup of AF_XDP socket easier and ones that can be used in the data
++plane to access the rings safely and quickly. To see an example on how
++to use this API, please take a look at the sample application in
++samples/bpf/xdpsock_usr.c which uses libbpf for both setup and data
++plane operations.
++
++We recommend that you use this library unless you have become a power
++user. It will make your program a lot simpler.
++
+ XSKMAP / BPF_MAP_TYPE_XSKMAP
+-----------------------------
++============================
+
+ On XDP side there is a BPF map type BPF_MAP_TYPE_XSKMAP (XSKMAP) that
+ is used in conjunction with bpf_redirect_map() to pass the ingress
+@@ -216,21 +237,184 @@ queue 17. Only the XDP program executing for eth0 and queue 17 will
+ successfully pass data to the socket. Please refer to the sample
+ application (samples/bpf/) in for an example.
+
++Configuration Flags and Socket Options
++======================================
++
++These are the various configuration flags that can be used to control
++and monitor the behavior of AF_XDP sockets.
++
++XDP_COPY and XDP_ZERO_COPY bind flags
++-------------------------------------
++
++When you bind to a socket, the kernel will first try to use zero-copy
++copy. If zero-copy is not supported, it will fall back on using copy
++mode, i.e. copying all packets out to user space. But if you would
++like to force a certain mode, you can use the following flags. If you
++pass the XDP_COPY flag to the bind call, the kernel will force the
++socket into copy mode. If it cannot use copy mode, the bind call will
++fail with an error. Conversely, the XDP_ZERO_COPY flag will force the
++socket into zero-copy mode or fail.
++
++XDP_SHARED_UMEM bind flag
++-------------------------
++
++This flag enables you to bind multiple sockets to the same UMEM, but
++only if they share the same queue id. In this mode, each socket has
++their own RX and TX rings, but the UMEM (tied to the fist socket
++created) only has a single FILL ring and a single COMPLETION
++ring. To use this mode, create the first socket and bind it in the normal
++way. Create a second socket and create an RX and a TX ring, or at
++least one of them, but no FILL or COMPLETION rings as the ones from
++the first socket will be used. In the bind call, set he
++XDP_SHARED_UMEM option and provide the initial socket's fd in the
++sxdp_shared_umem_fd field. You can attach an arbitrary number of extra
++sockets this way.
++
++What socket will then a packet arrive on? This is decided by the XDP
++program. Put all the sockets in the XSK_MAP and just indicate which
++index in the array you would like to send each packet to. A simple
++round-robin example of distributing packets is shown below:
++
++.. code-block:: c
++
++ #include <linux/bpf.h>
++ #include "bpf_helpers.h"
++
++ #define MAX_SOCKS 16
++
++ struct {
++ __uint(type, BPF_MAP_TYPE_XSKMAP);
++ __uint(max_entries, MAX_SOCKS);
++ __uint(key_size, sizeof(int));
++ __uint(value_size, sizeof(int));
++ } xsks_map SEC(".maps");
++
++ static unsigned int rr;
++
++ SEC("xdp_sock") int xdp_sock_prog(struct xdp_md *ctx)
++ {
++ rr = (rr + 1) & (MAX_SOCKS - 1);
++
++ return bpf_redirect_map(&xsks_map, rr, 0);
++ }
++
++Note, that since there is only a single set of FILL and COMPLETION
++rings, and they are single producer, single consumer rings, you need
++to make sure that multiple processes or threads do not use these rings
++concurrently. There are no synchronization primitives in the
++libbpf code that protects multiple users at this point in time.
++
++XDP_USE_NEED_WAKEUP bind flag
++-----------------------------
++
++This option adds support for a new flag called need_wakeup that is
++present in the FILL ring and the TX ring, the rings for which user
++space is a producer. When this option is set in the bind call, the
++need_wakeup flag will be set if the kernel needs to be explicitly
++woken up by a syscall to continue processing packets. If the flag is
++zero, no syscall is needed.
++
++If the flag is set on the FILL ring, the application needs to call
++poll() to be able to continue to receive packets on the RX ring. This
++can happen, for example, when the kernel has detected that there are no
++more buffers on the FILL ring and no buffers left on the RX HW ring of
++the NIC. In this case, interrupts are turned off as the NIC cannot
++receive any packets (as there are no buffers to put them in), and the
++need_wakeup flag is set so that user space can put buffers on the
++FILL ring and then call poll() so that the kernel driver can put these
++buffers on the HW ring and start to receive packets.
++
++If the flag is set for the TX ring, it means that the application
++needs to explicitly notify the kernel to send any packets put on the
++TX ring. This can be accomplished either by a poll() call, as in the
++RX path, or by calling sendto().
++
++An example of how to use this flag can be found in
++samples/bpf/xdpsock_user.c. An example with the use of libbpf helpers
++would look like this for the TX path:
++
++.. code-block:: c
++
++ if (xsk_ring_prod__needs_wakeup(&my_tx_ring))
++ sendto(xsk_socket__fd(xsk_handle), NULL, 0, MSG_DONTWAIT, NULL, 0);
++
++I.e., only use the syscall if the flag is set.
++
++We recommend that you always enable this mode as it usually leads to
++better performance especially if you run the application and the
++driver on the same core, but also if you use different cores for the
++application and the kernel driver, as it reduces the number of
++syscalls needed for the TX path.
++
++XDP_{RX|TX|UMEM_FILL|UMEM_COMPLETION}_RING setsockopts
++------------------------------------------------------
++
++These setsockopts sets the number of descriptors that the RX, TX,
++FILL, and COMPLETION rings respectively should have. It is mandatory
++to set the size of at least one of the RX and TX rings. If you set
++both, you will be able to both receive and send traffic from your
++application, but if you only want to do one of them, you can save
++resources by only setting up one of them. Both the FILL ring and the
++COMPLETION ring are mandatory if you have a UMEM tied to your socket,
++which is the normal case. But if the XDP_SHARED_UMEM flag is used, any
++socket after the first one does not have a UMEM and should in that
++case not have any FILL or COMPLETION rings created.
++
++XDP_UMEM_REG setsockopt
++-----------------------
++
++This setsockopt registers a UMEM to a socket. This is the area that
++contain all the buffers that packet can recide in. The call takes a
++pointer to the beginning of this area and the size of it. Moreover, it
++also has parameter called chunk_size that is the size that the UMEM is
++divided into. It can only be 2K or 4K at the moment. If you have an
++UMEM area that is 128K and a chunk size of 2K, this means that you
++will be able to hold a maximum of 128K / 2K = 64 packets in your UMEM
++area and that your largest packet size can be 2K.
++
++There is also an option to set the headroom of each single buffer in
++the UMEM. If you set this to N bytes, it means that the packet will
++start N bytes into the buffer leaving the first N bytes for the
++application to use. The final option is the flags field, but it will
++be dealt with in separate sections for each UMEM flag.
++
++XDP_STATISTICS getsockopt
++-------------------------
++
++Gets drop statistics of a socket that can be useful for debug
++purposes. The supported statistics are shown below:
++
++.. code-block:: c
++
++ struct xdp_statistics {
++ __u64 rx_dropped; /* Dropped for reasons other than invalid desc */
++ __u64 rx_invalid_descs; /* Dropped due to invalid descriptor */
++ __u64 tx_invalid_descs; /* Dropped due to invalid descriptor */
++ };
++
++XDP_OPTIONS getsockopt
++----------------------
++
++Gets options from an XDP socket. The only one supported so far is
++XDP_OPTIONS_ZEROCOPY which tells you if zero-copy is on or not.
++
+ Usage
+ =====
+
+-In order to use AF_XDP sockets there are two parts needed. The
++In order to use AF_XDP sockets two parts are needed. The
+ user-space application and the XDP program. For a complete setup and
+ usage example, please refer to the sample application. The user-space
+ side is xdpsock_user.c and the XDP side is part of libbpf.
+
+-The XDP code sample included in tools/lib/bpf/xsk.c is the following::
++The XDP code sample included in tools/lib/bpf/xsk.c is the following:
++
++.. code-block:: c
+
+ SEC("xdp_sock") int xdp_sock_prog(struct xdp_md *ctx)
+ {
+ int index = ctx->rx_queue_index;
+
+- // A set entry here means that the correspnding queue_id
++ // A set entry here means that the corresponding queue_id
+ // has an active AF_XDP socket bound to it.
+ if (bpf_map_lookup_elem(&xsks_map, &index))
+ return bpf_redirect_map(&xsks_map, index, 0);
+@@ -238,7 +422,10 @@ The XDP code sample included in tools/lib/bpf/xsk.c is the following::
+ return XDP_PASS;
+ }
+
+-Naive ring dequeue and enqueue could look like this::
++A simple but not so performance ring dequeue and enqueue could look
++like this:
++
++.. code-block:: c
+
+ // struct xdp_rxtx_ring {
+ // __u32 *producer;
+@@ -287,17 +474,16 @@ Naive ring dequeue and enqueue could look like this::
+ return 0;
+ }
+
+-
+-For a more optimized version, please refer to the sample application.
++But please use the libbpf functions as they are optimized and ready to
++use. Will make your life easier.
+
+ Sample application
+ ==================
+
+ There is a xdpsock benchmarking/test application included that
+-demonstrates how to use AF_XDP sockets with both private and shared
+-UMEMs. Say that you would like your UDP traffic from port 4242 to end
+-up in queue 16, that we will enable AF_XDP on. Here, we use ethtool
+-for this::
++demonstrates how to use AF_XDP sockets with private UMEMs. Say that
++you would like your UDP traffic from port 4242 to end up in queue 16,
++that we will enable AF_XDP on. Here, we use ethtool for this::
+
+ ethtool -N p3p2 rx-flow-hash udp4 fn
+ ethtool -N p3p2 flow-type udp4 src-port 4242 dst-port 4242 \
+@@ -311,13 +497,18 @@ using::
+ For XDP_SKB mode, use the switch "-S" instead of "-N" and all options
+ can be displayed with "-h", as usual.
+
++This sample application uses libbpf to make the setup and usage of
++AF_XDP simpler. If you want to know how the raw uapi of AF_XDP is
++really used to make something more advanced, take a look at the libbpf
++code in tools/lib/bpf/xsk.[ch].
++
+ FAQ
+ =======
+
+ Q: I am not seeing any traffic on the socket. What am I doing wrong?
+
+ A: When a netdev of a physical NIC is initialized, Linux usually
+- allocates one Rx and Tx queue pair per core. So on a 8 core system,
++ allocates one RX and TX queue pair per core. So on a 8 core system,
+ queue ids 0 to 7 will be allocated, one per core. In the AF_XDP
+ bind call or the xsk_socket__create libbpf function call, you
+ specify a specific queue id to bind to and it is only the traffic
+@@ -343,9 +534,21 @@ A: When a netdev of a physical NIC is initialized, Linux usually
+ sudo ethtool -N <interface> flow-type udp4 src-port 4242 dst-port \
+ 4242 action 2
+
+- A number of other ways are possible all up to the capabilitites of
++ A number of other ways are possible all up to the capabilities of
+ the NIC you have.
+
++Q: Can I use the XSKMAP to implement a switch betwen different umems
++ in copy mode?
++
++A: The short answer is no, that is not supported at the moment. The
++ XSKMAP can only be used to switch traffic coming in on queue id X
++ to sockets bound to the same queue id X. The XSKMAP can contain
++ sockets bound to different queue ids, for example X and Y, but only
++ traffic goming in from queue id Y can be directed to sockets bound
++ to the same queue id Y. In zero-copy mode, you should use the
++ switch, or other distribution mechanism, in your NIC to direct
++ traffic to the correct queue id and socket.
++
+ Credits
+ =======
+
+--
+2.39.2
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
