From: Sasha Levin Date: Thu, 13 Jul 2023 02:10:05 +0000 (-0400) Subject: Fixes for 5.4 X-Git-Tag: v6.1.39~106 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=ff0f56eda1028e1bb6504413e274dcf4ffc753ce;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.4 Signed-off-by: Sasha Levin --- diff --git a/queue-5.4/add-module_firmware-for-firmware_tg357766.patch b/queue-5.4/add-module_firmware-for-firmware_tg357766.patch new file mode 100644 index 00000000000..605d8fed3ee --- /dev/null +++ b/queue-5.4/add-module_firmware-for-firmware_tg357766.patch @@ -0,0 +1,37 @@ +From 7b7bc6e6b4065be710de7be625fd830ccfc71ee7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 28 Jun 2023 02:13:32 +0200 +Subject: Add MODULE_FIRMWARE() for FIRMWARE_TG357766. + +From: Tobias Heider + +[ 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 +Reviewed-by: Michael Chan +Link: https://lore.kernel.org/r/ZJt7LKzjdz8+dClx@tobhe.de +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/extcon-fix-kernel-doc-of-property-capability-fields-.patch b/queue-5.4/extcon-fix-kernel-doc-of-property-capability-fields-.patch new file mode 100644 index 00000000000..d920d752cf5 --- /dev/null +++ b/queue-5.4/extcon-fix-kernel-doc-of-property-capability-fields-.patch @@ -0,0 +1,46 @@ +From 234d6d4113c2a9a2386a02cd48ec6a8b75209ee4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 22 Mar 2023 16:39:53 +0200 +Subject: extcon: Fix kernel doc of property capability fields to avoid + warnings + +From: Andy Shevchenko + +[ 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 +Signed-off-by: Chanwoo Choi +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/extcon-fix-kernel-doc-of-property-fields-to-avoid-wa.patch b/queue-5.4/extcon-fix-kernel-doc-of-property-fields-to-avoid-wa.patch new file mode 100644 index 00000000000..3b4c26aab12 --- /dev/null +++ b/queue-5.4/extcon-fix-kernel-doc-of-property-fields-to-avoid-wa.patch @@ -0,0 +1,45 @@ +From e3ec1522ffa67dce0b89287b5e4869daae394ad1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 22 Mar 2023 16:39:52 +0200 +Subject: extcon: Fix kernel doc of property fields to avoid warnings + +From: Andy Shevchenko + +[ 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 +Signed-off-by: Chanwoo Choi +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/f2fs-fix-error-path-handling-in-truncate_dnode.patch b/queue-5.4/f2fs-fix-error-path-handling-in-truncate_dnode.patch new file mode 100644 index 00000000000..a8b26f03f70 --- /dev/null +++ b/queue-5.4/f2fs-fix-error-path-handling-in-truncate_dnode.patch @@ -0,0 +1,39 @@ +From a0996a6d79039d5b6f0692dd35faa2cef61e28c6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 29 Jun 2023 09:41:02 +0800 +Subject: f2fs: fix error path handling in truncate_dnode() + +From: Chao Yu + +[ 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 +Signed-off-by: Jaegeuk Kim +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/i2c-xiic-defer-xiic_wakeup-and-__xiic_start_xfer-in-.patch b/queue-5.4/i2c-xiic-defer-xiic_wakeup-and-__xiic_start_xfer-in-.patch new file mode 100644 index 00000000000..37c3473c8fd --- /dev/null +++ b/queue-5.4/i2c-xiic-defer-xiic_wakeup-and-__xiic_start_xfer-in-.patch @@ -0,0 +1,112 @@ +From 55e0d2495f220a9481e73f0e53e8223c51ae11e2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Acked-by: Michal Simek +Signed-off-by: Wolfram Sang +Stable-dep-of: cb6e45c9a0ad ("i2c: xiic: Don't try to handle more interrupt events after error") +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/i2c-xiic-don-t-try-to-handle-more-interrupt-events-a.patch b/queue-5.4/i2c-xiic-don-t-try-to-handle-more-interrupt-events-a.patch new file mode 100644 index 00000000000..97e4d4aa12d --- /dev/null +++ b/queue-5.4/i2c-xiic-don-t-try-to-handle-more-interrupt-events-a.patch @@ -0,0 +1,60 @@ +From d7a67b251fc7714cdcc0a35f0488138fc6a21c3d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Acked-by: Andi Shyti +Signed-off-by: Wolfram Sang +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/kvm-s390-fix-kvm_s390_get_cmma_bits-for-gfns-in-mems.patch b/queue-5.4/kvm-s390-fix-kvm_s390_get_cmma_bits-for-gfns-in-mems.patch new file mode 100644 index 00000000000..192bfd62e22 --- /dev/null +++ b/queue-5.4/kvm-s390-fix-kvm_s390_get_cmma_bits-for-gfns-in-mems.patch @@ -0,0 +1,74 @@ +From cb77bd4b66fc12acc2a600a8707bcb76709d84d9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 | | 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 +Reviewed-by: Claudio Imbrenda +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 +Signed-off-by: Janosch Frank +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/kvm-s390-vsie-fix-the-length-of-apcb-bitmap.patch b/queue-5.4/kvm-s390-vsie-fix-the-length-of-apcb-bitmap.patch new file mode 100644 index 00000000000..8f1b7295cfb --- /dev/null +++ b/queue-5.4/kvm-s390-vsie-fix-the-length-of-apcb-bitmap.patch @@ -0,0 +1,52 @@ +From c4264d6cc6f7858a46495b03a0db4ec4a29c4037 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 10 May 2023 17:42:58 +0200 +Subject: KVM: s390: vsie: fix the length of APCB bitmap + +From: Pierre Morel + +[ 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 +Reviewed-by: Janosch Frank +Link: https://lore.kernel.org/kvm/20230511094719.9691-1-pmorel@linux.ibm.com/ +Signed-off-by: Janosch Frank +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/mailbox-ti-msgmgr-fill-non-message-tx-data-fields-wi.patch b/queue-5.4/mailbox-ti-msgmgr-fill-non-message-tx-data-fields-wi.patch new file mode 100644 index 00000000000..2b3d7b301a0 --- /dev/null +++ b/queue-5.4/mailbox-ti-msgmgr-fill-non-message-tx-data-fields-wi.patch @@ -0,0 +1,75 @@ +From a8083ee00dc4d6595c0a634260449f797bcdd366 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 20 Jun 2023 20:00:22 -0500 +Subject: mailbox: ti-msgmgr: Fill non-message tx data fields with 0x0 + +From: Nishanth Menon + +[ 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 +Signed-off-by: Jassi Brar +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/media-usb-check-az6007_read-return-value.patch b/queue-5.4/media-usb-check-az6007_read-return-value.patch new file mode 100644 index 00000000000..d092b8cfc45 --- /dev/null +++ b/queue-5.4/media-usb-check-az6007_read-return-value.patch @@ -0,0 +1,38 @@ +From 54ce570329203390e86373b3875d5bf0938dafc4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 14 Mar 2023 10:04:49 -0700 +Subject: media: usb: Check az6007_read() return value + +From: Daniil Dulov + +[ 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 +Signed-off-by: Hans Verkuil +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/media-usb-siano-fix-warning-due-to-null-work_func_t-.patch b/queue-5.4/media-usb-siano-fix-warning-due-to-null-work_func_t-.patch new file mode 100644 index 00000000000..ccc5f2d6e4c --- /dev/null +++ b/queue-5.4/media-usb-siano-fix-warning-due-to-null-work_func_t-.patch @@ -0,0 +1,83 @@ +From 057ff1636f13fca736945002ddf4cfb43fe34455 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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: + + __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 +Signed-off-by: Hans Verkuil +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/media-videodev2.h-fix-struct-v4l2_input-tuner-index-.patch b/queue-5.4/media-videodev2.h-fix-struct-v4l2_input-tuner-index-.patch new file mode 100644 index 00000000000..1136c45eaf3 --- /dev/null +++ b/queue-5.4/media-videodev2.h-fix-struct-v4l2_input-tuner-index-.patch @@ -0,0 +1,62 @@ +From fb57ae911c10a867ad28a6a7a06a71d090d2743e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 May 2023 15:36:49 +0200 +Subject: media: videodev2.h: Fix struct v4l2_input tuner index comment + +From: Marek Vasut + +[ 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 +Signed-off-by: Hans Verkuil +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/mfd-intel-lpss-add-missing-check-for-platform_get_re.patch b/queue-5.4/mfd-intel-lpss-add-missing-check-for-platform_get_re.patch new file mode 100644 index 00000000000..57178837c4e --- /dev/null +++ b/queue-5.4/mfd-intel-lpss-add-missing-check-for-platform_get_re.patch @@ -0,0 +1,38 @@ +From af1c829097481553d8ee46d138ffa2d5092f1853 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 9 Jun 2023 09:48:18 +0800 +Subject: mfd: intel-lpss: Add missing check for platform_get_resource + +From: Jiasheng Jiang + +[ 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 +Signed-off-by: Lee Jones +Link: https://lore.kernel.org/r/20230609014818.28475-1-jiasheng@iscas.ac.cn +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/mfd-rt5033-drop-rt5033-battery-sub-device.patch b/queue-5.4/mfd-rt5033-drop-rt5033-battery-sub-device.patch new file mode 100644 index 00000000000..11be92fc8be --- /dev/null +++ b/queue-5.4/mfd-rt5033-drop-rt5033-battery-sub-device.patch @@ -0,0 +1,41 @@ +From e483912baac0162b153ccacef1795deddba084b3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 15 May 2023 22:57:10 +0200 +Subject: mfd: rt5033: Drop rt5033-battery sub-device + +From: Stephan Gerhold + +[ 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 +Signed-off-by: Jakob Hauser +Reviewed-by: Linus Walleij +Signed-off-by: Lee Jones +Link: https://lore.kernel.org/r/6a8a19bc67b5be3732882e8131ad2ffcb546ac03.1684182964.git.jahau@rocketmail.com +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/mfd-stmfx-fix-error-path-in-stmfx_chip_init.patch b/queue-5.4/mfd-stmfx-fix-error-path-in-stmfx_chip_init.patch new file mode 100644 index 00000000000..8c4e7db9ffc --- /dev/null +++ b/queue-5.4/mfd-stmfx-fix-error-path-in-stmfx_chip_init.patch @@ -0,0 +1,38 @@ +From cd60fdba993d9121829a5c238c770ac00059be33 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 9 Jun 2023 11:28:03 +0200 +Subject: mfd: stmfx: Fix error path in stmfx_chip_init + +From: Amelie Delaunay + +[ 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 +Link: https://lore.kernel.org/r/20230609092804.793100-1-amelie.delaunay@foss.st.com +Signed-off-by: Lee Jones +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/mfd-stmpe-only-disable-the-regulators-if-they-are-en.patch b/queue-5.4/mfd-stmpe-only-disable-the-regulators-if-they-are-en.patch new file mode 100644 index 00000000000..d29d1d3e568 --- /dev/null +++ b/queue-5.4/mfd-stmpe-only-disable-the-regulators-if-they-are-en.patch @@ -0,0 +1,45 @@ +From 4cced9c67cdd53f56e8dc8831dfa79e533aabac0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 17 Jun 2023 12:43:16 +0200 +Subject: mfd: stmpe: Only disable the regulators if they are enabled + +From: Christophe JAILLET + +[ 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 +Reviewed-by: Linus Walleij +Link: https://lore.kernel.org/r/8de3aaf297931d655b9ad6aed548f4de8b85425a.1686998575.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Lee Jones +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/net-bridge-keep-ports-without-iff_unicast_flt-in-br_.patch b/queue-5.4/net-bridge-keep-ports-without-iff_unicast_flt-in-br_.patch new file mode 100644 index 00000000000..99bed0d1953 --- /dev/null +++ b/queue-5.4/net-bridge-keep-ports-without-iff_unicast_flt-in-br_.patch @@ -0,0 +1,198 @@ +From cb8c2d1ecf895f8c6b83f645391b1b44b542dd28 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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); + + 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:: +| +| -> +| -> + +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 +Reviewed-by: Ido Schimmel +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/net-dsa-tag_sja1105-fix-mac-da-patching-from-meta-fr.patch b/queue-5.4/net-dsa-tag_sja1105-fix-mac-da-patching-from-meta-fr.patch new file mode 100644 index 00000000000..c60feec1ca7 --- /dev/null +++ b/queue-5.4/net-dsa-tag_sja1105-fix-mac-da-patching-from-meta-fr.patch @@ -0,0 +1,46 @@ +From a257ddee39cf9408c9cb6c4787c307bb85880c66 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 4 Jul 2023 01:05:44 +0300 +Subject: net: dsa: tag_sja1105: fix MAC DA patching from meta frames + +From: Vladimir Oltean + +[ 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 +Reviewed-by: Simon Horman +Reviewed-by: Florian Fainelli +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/net-sched-act_pedit-add-size-check-for-tca_pedit_par.patch b/queue-5.4/net-sched-act_pedit-add-size-check-for-tca_pedit_par.patch new file mode 100644 index 00000000000..6ed9c657aa6 --- /dev/null +++ b/queue-5.4/net-sched-act_pedit-add-size-check-for-tca_pedit_par.patch @@ -0,0 +1,57 @@ +From c6d4942bfabd5aa6bc717e23b0f0fa6a5fd3166f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Pedro Tammela +Link: https://lore.kernel.org/r/20230703110842.590282-1-linma@zju.edu.cn +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/powerpc-allow-ppc_early_debug_cpm-only-when-serial_c.patch b/queue-5.4/powerpc-allow-ppc_early_debug_cpm-only-when-serial_c.patch new file mode 100644 index 00000000000..c8f5ac728af --- /dev/null +++ b/queue-5.4/powerpc-allow-ppc_early_debug_cpm-only-when-serial_c.patch @@ -0,0 +1,46 @@ +From 6a3c1b16314d82eaae596f572e79085f899c7632 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Pali Rohár +Reviewed-by: Christophe Leroy +Signed-off-by: Michael Ellerman +Link: https://msgid.link/20230701054714.30512-1-rdunlap@infradead.org +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/pwm-imx-tpm-force-real_period-to-be-zero-in-suspend.patch b/queue-5.4/pwm-imx-tpm-force-real_period-to-be-zero-in-suspend.patch new file mode 100644 index 00000000000..fd047457b8a --- /dev/null +++ b/queue-5.4/pwm-imx-tpm-force-real_period-to-be-zero-in-suspend.patch @@ -0,0 +1,48 @@ +From a92b7ac7410e183bb2f6e41d0f3746d835de0c68 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Signed-off-by: Clark Wang +Acked-by: Uwe Kleine-König +Fixes: 738a1cfec2ed ("pwm: Add i.MX TPM PWM driver support") +Signed-off-by: Thierry Reding +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/pwm-sysfs-do-not-apply-state-to-already-disabled-pwm.patch b/queue-5.4/pwm-sysfs-do-not-apply-state-to-already-disabled-pwm.patch new file mode 100644 index 00000000000..b3b6472eb71 --- /dev/null +++ b/queue-5.4/pwm-sysfs-do-not-apply-state-to-already-disabled-pwm.patch @@ -0,0 +1,90 @@ +From fa6912a8dd82c69bf7e1b9dda0dc7ce9cc0170fe Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Fixes: ef2bf4997f7d ("pwm: Improve args checking in pwm_apply_state()") +Reviewed-by: Brian Norris +Reviewed-by: Uwe Kleine-König +Signed-off-by: Thierry Reding +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/rtc-st-lpc-release-some-resources-in-st_rtc_probe-in.patch b/queue-5.4/rtc-st-lpc-release-some-resources-in-st_rtc_probe-in.patch new file mode 100644 index 00000000000..cd17ccdd4d9 --- /dev/null +++ b/queue-5.4/rtc-st-lpc-release-some-resources-in-st_rtc_probe-in.patch @@ -0,0 +1,40 @@ +From 8c82f084a7d7497bc68e19dd0dba3712c6515447 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://lore.kernel.org/r/866af6adbc7454a7b4505eb6c28fbdc86ccff39e.1686251455.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Alexandre Belloni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/sctp-fix-potential-deadlock-on-net-sctp.addr_wq_lock.patch b/queue-5.4/sctp-fix-potential-deadlock-on-net-sctp.addr_wq_lock.patch new file mode 100644 index 00000000000..38840a92fbc --- /dev/null +++ b/queue-5.4/sctp-fix-potential-deadlock-on-net-sctp.addr_wq_lock.patch @@ -0,0 +1,57 @@ +From a6f7a997392fb2d43f8c55c7b2bda3e3cfc93ba0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 27 Jun 2023 12:03:40 +0000 +Subject: sctp: fix potential deadlock on &net->sctp.addr_wq_lock + +From: Chengfeng Ye + +[ 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) + + -> 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 +Fixes: 34e5b0118685 ("sctp: delay auto_asconf init until binding the first addr") +Acked-by: Xin Long +Link: https://lore.kernel.org/r/20230627120340.19432-1-dg573847474@gmail.com +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/serial-8250_omap-use-force_suspend-and-resume-for-sy.patch b/queue-5.4/serial-8250_omap-use-force_suspend-and-resume-for-sy.patch new file mode 100644 index 00000000000..ebcd5b14c40 --- /dev/null +++ b/queue-5.4/serial-8250_omap-use-force_suspend-and-resume-for-sy.patch @@ -0,0 +1,78 @@ +From 80745984ddc2e5e98f17784c2a91d4af61ddeca5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 14 Jun 2023 07:59:19 +0300 +Subject: serial: 8250_omap: Use force_suspend and resume for system suspend + +From: Tony Lindgren + +[ 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 +Tested-by: Dhruva Gole +Message-ID: <20230614045922.4798-1-tony@atomide.com> +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/series b/queue-5.4/series index 121cf64c467..28988d6df8e 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -123,3 +123,41 @@ usb-serial-option-add-lara-r6-01b-pids.patch 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 diff --git a/queue-5.4/sh-dma-fix-dma-channel-offset-calculation.patch b/queue-5.4/sh-dma-fix-dma-channel-offset-calculation.patch new file mode 100644 index 00000000000..05eaa895355 --- /dev/null +++ b/queue-5.4/sh-dma-fix-dma-channel-offset-calculation.patch @@ -0,0 +1,103 @@ +From 0b15731deafacf13c37fa4409c56568222978b95 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 27 May 2023 18:44:50 +0200 +Subject: sh: dma: Fix DMA channel offset calculation + +From: Artur Rojek + +[ 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 +Reviewed-by: Geert Uytterhoeven +Reviewed-by: John Paul Adrian Glaubitz +Link: https://lore.kernel.org/r/20230527164452.64797-2-contact@artur-rojek.eu +Signed-off-by: John Paul Adrian Glaubitz +Signed-off-by: Sasha Levin +--- + 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 + #include + ++/* ++ * 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 + diff --git a/queue-5.4/sh-j2-use-ioremap-to-translate-device-tree-address-i.patch b/queue-5.4/sh-j2-use-ioremap-to-translate-device-tree-address-i.patch new file mode 100644 index 00000000000..1af332e5e5b --- /dev/null +++ b/queue-5.4/sh-j2-use-ioremap-to-translate-device-tree-address-i.patch @@ -0,0 +1,44 @@ +From 5e5c6c3b152e912c822ba227130d0d57b0b214b4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Tested-by: Rob Landley +Signed-off-by: John Paul Adrian Glaubitz +Link: https://lore.kernel.org/r/20230503125746.331835-1-glaubitz@physik.fu-berlin.de +Signed-off-by: John Paul Adrian Glaubitz +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/software-node-introduce-device_add_software_node.patch b/queue-5.4/software-node-introduce-device_add_software_node.patch new file mode 100644 index 00000000000..3b1aa38a18d --- /dev/null +++ b/queue-5.4/software-node-introduce-device_add_software_node.patch @@ -0,0 +1,135 @@ +From 77739841c2046e7a2820af8201754478ddbe4686 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 15 Jan 2021 12:49:11 +0300 +Subject: software node: Introduce device_add_software_node() + +From: Heikki Krogerus + +[ 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 +Signed-off-by: Heikki Krogerus +Link: https://lore.kernel.org/r/20210115094914.88401-2-heikki.krogerus@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +Stable-dep-of: 8fd95da2cfb5 ("usb: dwc3: qcom: Release the correct resources in dwc3_qcom_remove()") +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/spi-bcm-qspi-return-error-if-neither-hif_mspi-nor-ms.patch b/queue-5.4/spi-bcm-qspi-return-error-if-neither-hif_mspi-nor-ms.patch new file mode 100644 index 00000000000..d74ec6d7917 --- /dev/null +++ b/queue-5.4/spi-bcm-qspi-return-error-if-neither-hif_mspi-nor-ms.patch @@ -0,0 +1,58 @@ +From 5eac33d10c2667b17f978abbd37d508c4a697e90 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Kamal Dasu +Link: https://lore.kernel.org/r/20230629134306.95823-1-jonas.gorski@gmail.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/tcp-annotate-data-races-in-__tcp_oow_rate_limited.patch b/queue-5.4/tcp-annotate-data-races-in-__tcp_oow_rate_limited.patch new file mode 100644 index 00000000000..861ee8f4abe --- /dev/null +++ b/queue-5.4/tcp-annotate-data-races-in-__tcp_oow_rate_limited.patch @@ -0,0 +1,55 @@ +From 18c2a5a44f150dbf7f29d80f288aeb6d5c6d88bc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 29 Jun 2023 16:41:50 +0000 +Subject: tcp: annotate data races in __tcp_oow_rate_limited() + +From: Eric Dumazet + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/usb-dwc3-qcom-constify-the-software-node.patch b/queue-5.4/usb-dwc3-qcom-constify-the-software-node.patch new file mode 100644 index 00000000000..cfb645929d8 --- /dev/null +++ b/queue-5.4/usb-dwc3-qcom-constify-the-software-node.patch @@ -0,0 +1,71 @@ +From 69665dbcb9e352a15bab2cf25306e6f1c7addaa4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 4 Feb 2021 17:17:09 +0300 +Subject: usb: dwc3: qcom: Constify the software node + +From: Heikki Krogerus + +[ 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 +Link: https://lore.kernel.org/r/20210204141711.53775-5-heikki.krogerus@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +Stable-dep-of: 8fd95da2cfb5 ("usb: dwc3: qcom: Release the correct resources in dwc3_qcom_remove()") +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/usb-dwc3-qcom-fix-potential-memory-leak.patch b/queue-5.4/usb-dwc3-qcom-fix-potential-memory-leak.patch new file mode 100644 index 00000000000..6868c466e11 --- /dev/null +++ b/queue-5.4/usb-dwc3-qcom-fix-potential-memory-leak.patch @@ -0,0 +1,53 @@ +From 0d77c20807fb276e36370300c4c66cda0f328b23 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 17 May 2023 20:25:18 +0300 +Subject: usb: dwc3: qcom: Fix potential memory leak + +From: Vladislav Efanov + +[ 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 +Acked-by: Shawn Guo +Link: https://lore.kernel.org/r/20230517172518.442591-1-VEfanov@ispras.ru +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/usb-dwc3-qcom-release-the-correct-resources-in-dwc3_.patch b/queue-5.4/usb-dwc3-qcom-release-the-correct-resources-in-dwc3_.patch new file mode 100644 index 00000000000..05bff2d39a0 --- /dev/null +++ b/queue-5.4/usb-dwc3-qcom-release-the-correct-resources-in-dwc3_.patch @@ -0,0 +1,50 @@ +From 0111895332a37f31641ebb0ee9d8090513358b8d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 4 Jun 2023 17:04:37 +0200 +Subject: usb: dwc3: qcom: Release the correct resources in dwc3_qcom_remove() + +From: Christophe JAILLET + +[ 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 +Reviewed-by: Andrew Halaney +Message-ID: +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/usb-hide-unused-usbfs_notify_suspend-resume-function.patch b/queue-5.4/usb-hide-unused-usbfs_notify_suspend-resume-function.patch new file mode 100644 index 00000000000..8df5273b760 --- /dev/null +++ b/queue-5.4/usb-hide-unused-usbfs_notify_suspend-resume-function.patch @@ -0,0 +1,52 @@ +From 882a68da590d8b5700ab16a88f2c6e06cb19395b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 16 May 2023 22:17:42 +0200 +Subject: usb: hide unused usbfs_notify_suspend/resume functions + +From: Arnd Bergmann + +[ 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 +Reviewed-by: Sebastian Reichel +Acked-by: Alan Stern +Link: https://lore.kernel.org/r/20230516202103.558301-1-arnd@kernel.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/usb-phy-phy-tahvo-fix-memory-leak-in-tahvo_usb_probe.patch b/queue-5.4/usb-phy-phy-tahvo-fix-memory-leak-in-tahvo_usb_probe.patch new file mode 100644 index 00000000000..ed551dedc05 --- /dev/null +++ b/queue-5.4/usb-phy-phy-tahvo-fix-memory-leak-in-tahvo_usb_probe.patch @@ -0,0 +1,43 @@ +From 8aa7a6d4305067f4b75c7f64661b981d72060166 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 20 Apr 2023 22:08:31 +0800 +Subject: usb: phy: phy-tahvo: fix memory leak in tahvo_usb_probe() + +From: Li Yang + +[ 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 +Reviewed-by: Dongliang Mu +Link: https://lore.kernel.org/r/20230420140832.9110-1-lidaxian@hust.edu.cn +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/w1-fix-loop-in-w1_fini.patch b/queue-5.4/w1-fix-loop-in-w1_fini.patch new file mode 100644 index 00000000000..47c0c20cf3f --- /dev/null +++ b/queue-5.4/w1-fix-loop-in-w1_fini.patch @@ -0,0 +1,43 @@ +From 34e6fe9641d5d7402b033346c99fd48cab3bd172 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 19 May 2021 17:17:45 +0300 +Subject: w1: fix loop in w1_fini() + +From: Dan Carpenter + +[ 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 +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/xsk-honor-so_bindtodevice-on-bind.patch b/queue-5.4/xsk-honor-so_bindtodevice-on-bind.patch new file mode 100644 index 00000000000..5ab4fa4185b --- /dev/null +++ b/queue-5.4/xsk-honor-so_bindtodevice-on-bind.patch @@ -0,0 +1,101 @@ +From 846711fa26e61e053082b3796fa85fc102d26a60 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 3 Jul 2023 19:53:29 +0200 +Subject: xsk: Honor SO_BINDTODEVICE on bind + +From: Ilya Maximets + +[ 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 +Signed-off-by: Daniel Borkmann +Acked-by: Magnus Karlsson +Acked-by: John Fastabend +Acked-by: Jason Wang +Link: https://lore.kernel.org/bpf/20230703175329.3259672-1-i.maximets@ovn.org +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/xsk-improve-documentation-for-af_xdp.patch b/queue-5.4/xsk-improve-documentation-for-af_xdp.patch new file mode 100644 index 00000000000..ede2b97a9ef --- /dev/null +++ b/queue-5.4/xsk-improve-documentation-for-af_xdp.patch @@ -0,0 +1,423 @@ +From 0465515ac2c363884f8310d98987d80ba1245e80 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 21 Oct 2019 10:57:04 +0200 +Subject: xsk: Improve documentation for AF_XDP + +From: Magnus Karlsson + +[ 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 +Signed-off-by: Alexei Starovoitov +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 +--- + 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 ++ #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 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 +