Fixes for 6.6

Signed-off-by: Sasha Levin <sashal@kernel.org>

28 files changed, 2477 insertions, 0 deletions

diff --git a/queue-6.6/af_unix-call-manage_oob-for-every-skb-in-unix_stream.patch b/queue-6.6/af_unix-call-manage_oob-for-every-skb-in-unix_stream.patch
new file mode 100644
index 0000000000..7b10b755ed
--- /dev/null
+++ b/queue-6.6/af_unix-call-manage_oob-for-every-skb-in-unix_stream.patch
@@ -0,0 +1,73 @@
+From 49d2ab8c92f1f51a365cc4d57b8872c665a4ef6c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 10 Apr 2024 10:10:15 -0700
+Subject: af_unix: Call manage_oob() for every skb in
+ unix_stream_read_generic().
+
+From: Kuniyuki Iwashima <kuniyu@amazon.com>
+
+[ Upstream commit 283454c8a123072e5c386a5a2b5fc576aa455b6f ]
+
+When we call recv() for AF_UNIX socket, we first peek one skb and
+calls manage_oob() to check if the skb is sent with MSG_OOB.
+
+However, when we fetch the next (and the following) skb, manage_oob()
+is not called now, leading a wrong behaviour.
+
+Let's say a socket send()s "hello" with MSG_OOB and the peer tries
+to recv() 5 bytes with MSG_PEEK.  Here, we should get only "hell"
+without 'o', but actually not:
+
+  >>> from socket import *
+  >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
+  >>> c1.send(b'hello', MSG_OOB)
+  5
+  >>> c2.recv(5, MSG_PEEK)
+  b'hello'
+
+The first skb fills 4 bytes, and the next skb is peeked but not
+properly checked by manage_oob().
+
+Let's move up the again label to call manage_oob() for evry skb.
+
+With this patch:
+
+  >>> from socket import *
+  >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
+  >>> c1.send(b'hello', MSG_OOB)
+  5
+  >>> c2.recv(5, MSG_PEEK)
+  b'hell'
+
+Fixes: 314001f0bf92 ("af_unix: Add OOB support")
+Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
+Link: https://lore.kernel.org/r/20240410171016.7621-2-kuniyu@amazon.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/unix/af_unix.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
+index 918724844231e..1340cb86f104c 100644
+--- a/net/unix/af_unix.c
++++ b/net/unix/af_unix.c
+@@ -2665,6 +2665,7 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state,
+ 		last = skb = skb_peek(&sk->sk_receive_queue);
+ 		last_len = last ? last->len : 0;
+ 
++again:
+ #if IS_ENABLED(CONFIG_AF_UNIX_OOB)
+ 		if (skb) {
+ 			skb = manage_oob(skb, sk, flags, copied);
+@@ -2676,7 +2677,6 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state,
+ 			}
+ 		}
+ #endif
+-again:
+ 		if (skb == NULL) {
+ 			if (copied >= target)
+ 				goto unlock;
+-- 
+2.43.0
+
diff --git a/queue-6.6/af_unix-don-t-peek-oob-data-without-msg_oob.patch b/queue-6.6/af_unix-don-t-peek-oob-data-without-msg_oob.patch
new file mode 100644
index 0000000000..51ea43e15d
--- /dev/null
+++ b/queue-6.6/af_unix-don-t-peek-oob-data-without-msg_oob.patch
@@ -0,0 +1,86 @@
+From 5089cc040c785b3919c4a2907448a224974895c3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 10 Apr 2024 10:10:16 -0700
+Subject: af_unix: Don't peek OOB data without MSG_OOB.
+
+From: Kuniyuki Iwashima <kuniyu@amazon.com>
+
+[ Upstream commit 22dd70eb2c3d754862964377a75abafd3167346b ]
+
+Currently, we can read OOB data without MSG_OOB by using MSG_PEEK
+when OOB data is sitting on the front row, which is apparently
+wrong.
+
+  >>> from socket import *
+  >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
+  >>> c1.send(b'a', MSG_OOB)
+  1
+  >>> c2.recv(1, MSG_PEEK | MSG_DONTWAIT)
+  b'a'
+
+If manage_oob() is called when no data has been copied, we only
+check if the socket enables SO_OOBINLINE or MSG_PEEK is not used.
+Otherwise, the skb is returned as is.
+
+However, here we should return NULL if MSG_PEEK is set and no data
+has been copied.
+
+Also, in such a case, we should not jump to the redo label because
+we will be caught in the loop and hog the CPU until normal data
+comes in.
+
+Then, we need to handle skb == NULL case with the if-clause below
+the manage_oob() block.
+
+With this patch:
+
+  >>> from socket import *
+  >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
+  >>> c1.send(b'a', MSG_OOB)
+  1
+  >>> c2.recv(1, MSG_PEEK | MSG_DONTWAIT)
+  Traceback (most recent call last):
+    File "<stdin>", line 1, in <module>
+  BlockingIOError: [Errno 11] Resource temporarily unavailable
+
+Fixes: 314001f0bf92 ("af_unix: Add OOB support")
+Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
+Link: https://lore.kernel.org/r/20240410171016.7621-3-kuniyu@amazon.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/unix/af_unix.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
+index 1340cb86f104c..6eab35a5e2f3b 100644
+--- a/net/unix/af_unix.c
++++ b/net/unix/af_unix.c
+@@ -2587,7 +2587,9 @@ static struct sk_buff *manage_oob(struct sk_buff *skb, struct sock *sk,
+ 					WRITE_ONCE(u->oob_skb, NULL);
+ 					consume_skb(skb);
+ 				}
+-			} else if (!(flags & MSG_PEEK)) {
++			} else if (flags & MSG_PEEK) {
++				skb = NULL;
++			} else {
+ 				skb_unlink(skb, &sk->sk_receive_queue);
+ 				WRITE_ONCE(u->oob_skb, NULL);
+ 				if (!WARN_ON_ONCE(skb_unref(skb)))
+@@ -2669,11 +2671,9 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state,
+ #if IS_ENABLED(CONFIG_AF_UNIX_OOB)
+ 		if (skb) {
+ 			skb = manage_oob(skb, sk, flags, copied);
+-			if (!skb) {
++			if (!skb && copied) {
+ 				unix_state_unlock(sk);
+-				if (copied)
+-					break;
+-				goto redo;
++				break;
+ 			}
+ 		}
+ #endif
+-- 
+2.43.0
+
diff --git a/queue-6.6/gpiolib-swnode-remove-wrong-header-inclusion.patch b/queue-6.6/gpiolib-swnode-remove-wrong-header-inclusion.patch
new file mode 100644
index 0000000000..1e324d30d6
--- /dev/null
+++ b/queue-6.6/gpiolib-swnode-remove-wrong-header-inclusion.patch
@@ -0,0 +1,37 @@
+From ed3a4b5f118efe5635e2ef600395a24a7acb9e9f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 17 Apr 2024 17:19:13 +0300
+Subject: gpiolib: swnode: Remove wrong header inclusion
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+[ Upstream commit 69ffed4b62523bbc85511f150500329d28aba356 ]
+
+The flags in the software node properties are supposed to be
+the GPIO lookup flags, which are provided by gpio/machine.h,
+as the software nodes are the kernel internal thing and doesn't
+need to rely to any of ABIs.
+
+Fixes: e7f9ff5dc90c ("gpiolib: add support for software nodes")
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/gpio/property.h | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/include/linux/gpio/property.h b/include/linux/gpio/property.h
+index 6c75c8bd44a0b..1a14e239221f7 100644
+--- a/include/linux/gpio/property.h
++++ b/include/linux/gpio/property.h
+@@ -2,7 +2,6 @@
+ #ifndef __LINUX_GPIO_PROPERTY_H
+ #define __LINUX_GPIO_PROPERTY_H
+ 
+-#include <dt-bindings/gpio/gpio.h> /* for GPIO_* flags */
+ #include <linux/property.h>
+ 
+ #define PROPERTY_ENTRY_GPIO(_name_, _chip_node_, _idx_, _flags_) \
+-- 
+2.43.0
+
diff --git a/queue-6.6/ice-fix-checking-for-unsupported-keys-on-non-tunnel-.patch b/queue-6.6/ice-fix-checking-for-unsupported-keys-on-non-tunnel-.patch
new file mode 100644
index 0000000000..3905c209e3
--- /dev/null
+++ b/queue-6.6/ice-fix-checking-for-unsupported-keys-on-non-tunnel-.patch
@@ -0,0 +1,51 @@
+From 555d7e0700eb3531cb9f8f93c8fa6e380b862573 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 9 Apr 2024 17:45:44 +0200
+Subject: ice: Fix checking for unsupported keys on non-tunnel device
+
+From: Marcin Szycik <marcin.szycik@linux.intel.com>
+
+[ Upstream commit 2cca35f5dd78b9f8297c879c5db5ab137c5d86c3 ]
+
+Add missing FLOW_DISSECTOR_KEY_ENC_* checks to TC flower filter parsing.
+Without these checks, it would be possible to add filters with tunnel
+options on non-tunnel devices. enc_* options are only valid for tunnel
+devices.
+
+Example:
+  devlink dev eswitch set $PF1_PCI mode switchdev
+  echo 1 > /sys/class/net/$PF1/device/sriov_numvfs
+  tc qdisc add dev $VF1_PR ingress
+  ethtool -K $PF1 hw-tc-offload on
+  tc filter add dev $VF1_PR ingress flower enc_ttl 12 skip_sw action drop
+
+Fixes: 9e300987d4a8 ("ice: VXLAN and Geneve TC support")
+Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
+Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com>
+Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
+Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/ice/ice_tc_lib.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/intel/ice/ice_tc_lib.c b/drivers/net/ethernet/intel/ice/ice_tc_lib.c
+index 9c97c99feac3d..76ad5930c0102 100644
+--- a/drivers/net/ethernet/intel/ice/ice_tc_lib.c
++++ b/drivers/net/ethernet/intel/ice/ice_tc_lib.c
+@@ -1448,7 +1448,10 @@ ice_parse_cls_flower(struct net_device *filter_dev, struct ice_vsi *vsi,
+ 		  (BIT_ULL(FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) |
+ 		   BIT_ULL(FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS) |
+ 		   BIT_ULL(FLOW_DISSECTOR_KEY_ENC_KEYID) |
+-		   BIT_ULL(FLOW_DISSECTOR_KEY_ENC_PORTS))) {
++		   BIT_ULL(FLOW_DISSECTOR_KEY_ENC_PORTS) |
++		   BIT_ULL(FLOW_DISSECTOR_KEY_ENC_IP) |
++		   BIT_ULL(FLOW_DISSECTOR_KEY_ENC_OPTS) |
++		   BIT_ULL(FLOW_DISSECTOR_KEY_ENC_CONTROL))) {
+ 		NL_SET_ERR_MSG_MOD(fltr->extack, "Tunnel key used, but device isn't a tunnel");
+ 		return -EOPNOTSUPP;
+ 	} else {
+-- 
+2.43.0
+
diff --git a/queue-6.6/ice-tc-allow-zero-flags-in-parsing-tc-flower.patch b/queue-6.6/ice-tc-allow-zero-flags-in-parsing-tc-flower.patch
new file mode 100644
index 0000000000..4d8ae31ed0
--- /dev/null
+++ b/queue-6.6/ice-tc-allow-zero-flags-in-parsing-tc-flower.patch
@@ -0,0 +1,49 @@
+From 50acfdbe1bb509a8e8eb708605670c5d137062ba Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 15 Mar 2024 12:08:21 +0100
+Subject: ice: tc: allow zero flags in parsing tc flower
+
+From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
+
+[ Upstream commit 73278715725a8347032acf233082ca4eb31e6a56 ]
+
+The check for flags is done to not pass empty lookups to adding switch
+rule functions. Since metadata is always added to lookups there is no
+need to check against the flag.
+
+It is also fixing the problem with such rule:
+$ tc filter add dev gtp_dev ingress protocol ip prio 0 flower \
+	enc_dst_port 2123 action drop
+Switch block in case of GTP can't parse the destination port, because it
+should always be set to GTP specific value. The same with ethertype. The
+result is that there is no other matching criteria than GTP tunnel. In
+this case flags is 0, rule can't be added only because of defensive
+check against flags.
+
+Fixes: 9a225f81f540 ("ice: Support GTP-U and GTP-C offload in switchdev")
+Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
+Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/ice/ice_tc_lib.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/intel/ice/ice_tc_lib.c b/drivers/net/ethernet/intel/ice/ice_tc_lib.c
+index f111fdd6a6ef7..9c97c99feac3d 100644
+--- a/drivers/net/ethernet/intel/ice/ice_tc_lib.c
++++ b/drivers/net/ethernet/intel/ice/ice_tc_lib.c
+@@ -738,7 +738,7 @@ ice_eswitch_add_tc_fltr(struct ice_vsi *vsi, struct ice_tc_flower_fltr *fltr)
+ 	int ret;
+ 	int i;
+ 
+-	if (!flags || (flags & ICE_TC_FLWR_FIELD_ENC_SRC_L4_PORT)) {
++	if (flags & ICE_TC_FLWR_FIELD_ENC_SRC_L4_PORT) {
+ 		NL_SET_ERR_MSG_MOD(fltr->extack, "Unsupported encap field(s)");
+ 		return -EOPNOTSUPP;
+ 	}
+-- 
+2.43.0
+
diff --git a/queue-6.6/ice-tc-check-src_vsi-in-case-of-traffic-from-vf.patch b/queue-6.6/ice-tc-check-src_vsi-in-case-of-traffic-from-vf.patch
new file mode 100644
index 0000000000..10cb564953
--- /dev/null
+++ b/queue-6.6/ice-tc-check-src_vsi-in-case-of-traffic-from-vf.patch
@@ -0,0 +1,71 @@
+From 4162cc329dce7394f1321b014f6f560ef0a176ec Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 15 Mar 2024 12:08:20 +0100
+Subject: ice: tc: check src_vsi in case of traffic from VF
+
+From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
+
+[ Upstream commit 428051600cb4e5a61d81aba3f8009b6c4f5e7582 ]
+
+In case of traffic going from the VF (so ingress for port representor)
+source VSI should be consider during packet classification. It is
+needed for hardware to not match packets from different ports with
+filters added on other port.
+
+It is only for "from VF" traffic, because other traffic direction
+doesn't have source VSI.
+
+Set correct ::src_vsi in rule_info to pass it to the hardware filter.
+
+For example this rule should drop only ipv4 packets from eth10, not from
+the others VF PRs. It is needed to check source VSI in this case.
+$tc filter add dev eth10 ingress protocol ip flower skip_sw action drop
+
+Fixes: 0d08a441fb1a ("ice: ndo_setup_tc implementation for PF")
+Reviewed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
+Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
+Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/ice/ice_tc_lib.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/net/ethernet/intel/ice/ice_tc_lib.c b/drivers/net/ethernet/intel/ice/ice_tc_lib.c
+index dd03cb69ad26b..f111fdd6a6ef7 100644
+--- a/drivers/net/ethernet/intel/ice/ice_tc_lib.c
++++ b/drivers/net/ethernet/intel/ice/ice_tc_lib.c
+@@ -28,6 +28,8 @@ ice_tc_count_lkups(u32 flags, struct ice_tc_flower_lyr_2_4_hdrs *headers,
+ 	 * - ICE_TC_FLWR_FIELD_VLAN_TPID (present if specified)
+ 	 * - Tunnel flag (present if tunnel)
+ 	 */
++	if (fltr->direction == ICE_ESWITCH_FLTR_EGRESS)
++		lkups_cnt++;
+ 
+ 	if (flags & ICE_TC_FLWR_FIELD_TENANT_ID)
+ 		lkups_cnt++;
+@@ -363,6 +365,11 @@ ice_tc_fill_rules(struct ice_hw *hw, u32 flags,
+ 	/* Always add direction metadata */
+ 	ice_rule_add_direction_metadata(&list[ICE_TC_METADATA_LKUP_IDX]);
+ 
++	if (tc_fltr->direction == ICE_ESWITCH_FLTR_EGRESS) {
++		ice_rule_add_src_vsi_metadata(&list[i]);
++		i++;
++	}
++
+ 	rule_info->tun_type = ice_sw_type_from_tunnel(tc_fltr->tunnel_type);
+ 	if (tc_fltr->tunnel_type != TNL_LAST) {
+ 		i = ice_tc_fill_tunnel_outer(flags, tc_fltr, list, i);
+@@ -779,6 +786,7 @@ ice_eswitch_add_tc_fltr(struct ice_vsi *vsi, struct ice_tc_flower_fltr *fltr)
+ 
+ 	/* specify the cookie as filter_rule_id */
+ 	rule_info.fltr_rule_id = fltr->cookie;
++	rule_info.src_vsi = vsi->idx;
+ 
+ 	ret = ice_add_adv_rule(hw, list, lkups_cnt, &rule_info, &rule_added);
+ 	if (ret == -EEXIST) {
+-- 
+2.43.0
+
diff --git a/queue-6.6/net-change-maximum-number-of-udp-segments-to-128.patch b/queue-6.6/net-change-maximum-number-of-udp-segments-to-128.patch
new file mode 100644
index 0000000000..5ae5229fa2
--- /dev/null
+++ b/queue-6.6/net-change-maximum-number-of-udp-segments-to-128.patch
@@ -0,0 +1,71 @@
+From 4f092dadde909f1ea6e3b40285926f23455fc2b7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 11 Apr 2024 08:11:24 +0300
+Subject: net: change maximum number of UDP segments to 128
+
+From: Yuri Benditovich <yuri.benditovich@daynix.com>
+
+[ Upstream commit 1382e3b6a3500c245e5278c66d210c02926f804f ]
+
+The commit fc8b2a619469
+("net: more strict VIRTIO_NET_HDR_GSO_UDP_L4 validation")
+adds check of potential number of UDP segments vs
+UDP_MAX_SEGMENTS in linux/virtio_net.h.
+After this change certification test of USO guest-to-guest
+transmit on Windows driver for virtio-net device fails,
+for example with packet size of ~64K and mss of 536 bytes.
+In general the USO should not be more restrictive than TSO.
+Indeed, in case of unreasonably small mss a lot of segments
+can cause queue overflow and packet loss on the destination.
+Limit of 128 segments is good for any practical purpose,
+with minimal meaningful mss of 536 the maximal UDP packet will
+be divided to ~120 segments.
+The number of segments for UDP packets is validated vs
+UDP_MAX_SEGMENTS also in udp.c (v4,v6), this does not affect
+quest-to-guest path but does affect packets sent to host, for
+example.
+It is important to mention that UDP_MAX_SEGMENTS is kernel-only
+define and not available to user mode socket applications.
+In order to request MSS smaller than MTU the applications
+just uses setsockopt with SOL_UDP and UDP_SEGMENT and there is
+no limitations on socket API level.
+
+Fixes: fc8b2a619469 ("net: more strict VIRTIO_NET_HDR_GSO_UDP_L4 validation")
+Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
+Reviewed-by: Willem de Bruijn <willemb@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/udp.h                  | 2 +-
+ tools/testing/selftests/net/udpgso.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/include/linux/udp.h b/include/linux/udp.h
+index 94e63b2695406..00790bb5cbde6 100644
+--- a/include/linux/udp.h
++++ b/include/linux/udp.h
+@@ -105,7 +105,7 @@ struct udp_sock {
+ #define udp_assign_bit(nr, sk, val)		\
+ 	assign_bit(UDP_FLAGS_##nr, &udp_sk(sk)->udp_flags, val)
+ 
+-#define UDP_MAX_SEGMENTS	(1 << 6UL)
++#define UDP_MAX_SEGMENTS	(1 << 7UL)
+ 
+ #define udp_sk(ptr) container_of_const(ptr, struct udp_sock, inet.sk)
+ 
+diff --git a/tools/testing/selftests/net/udpgso.c b/tools/testing/selftests/net/udpgso.c
+index 7badaf215de28..b02080d09fbc0 100644
+--- a/tools/testing/selftests/net/udpgso.c
++++ b/tools/testing/selftests/net/udpgso.c
+@@ -34,7 +34,7 @@
+ #endif
+ 
+ #ifndef UDP_MAX_SEGMENTS
+-#define UDP_MAX_SEGMENTS	(1 << 6UL)
++#define UDP_MAX_SEGMENTS	(1 << 7UL)
+ #endif
+ 
+ #define CONST_MTU_TEST	1500
+-- 
+2.43.0
+
diff --git a/queue-6.6/net-dsa-mt7530-fix-mirroring-frames-received-on-loca.patch b/queue-6.6/net-dsa-mt7530-fix-mirroring-frames-received-on-loca.patch
new file mode 100644
index 0000000000..c0345e0997
--- /dev/null
+++ b/queue-6.6/net-dsa-mt7530-fix-mirroring-frames-received-on-loca.patch
@@ -0,0 +1,81 @@
+From 8a9e13d951a243ac68ff5129877993aa61cafbd1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 13 Apr 2024 16:01:39 +0300
+Subject: net: dsa: mt7530: fix mirroring frames received on local port
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Arınç ÜNAL <arinc.unal@arinc9.com>
+
+[ Upstream commit d59cf049c8378677053703e724808836f180888e ]
+
+This switch intellectual property provides a bit on the ARL global control
+register which controls allowing mirroring frames which are received on the
+local port (monitor port). This bit is unset after reset.
+
+This ability must be enabled to fully support the port mirroring feature on
+this switch intellectual property.
+
+Therefore, this patch fixes the traffic not being reflected on a port,
+which would be configured like below:
+
+  tc qdisc add dev swp0 clsact
+
+  tc filter add dev swp0 ingress matchall skip_sw \
+  action mirred egress mirror dev swp0
+
+As a side note, this configuration provides the hairpinning feature for a
+single port.
+
+Fixes: 37feab6076aa ("net: dsa: mt7530: add support for port mirroring")
+Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/mt7530.c | 6 ++++++
+ drivers/net/dsa/mt7530.h | 4 ++++
+ 2 files changed, 10 insertions(+)
+
+diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
+index 88f081672f6fb..a123bb832db91 100644
+--- a/drivers/net/dsa/mt7530.c
++++ b/drivers/net/dsa/mt7530.c
+@@ -2518,6 +2518,9 @@ mt7530_setup(struct dsa_switch *ds)
+ 			   PVC_EG_TAG(MT7530_VLAN_EG_CONSISTENT));
+ 	}
+ 
++	/* Allow mirroring frames received on the local port (monitor port). */
++	mt7530_set(priv, MT753X_AGC, LOCAL_EN);
++
+ 	/* Setup VLAN ID 0 for VLAN-unaware bridges */
+ 	ret = mt7530_setup_vlan0(priv);
+ 	if (ret)
+@@ -2626,6 +2629,9 @@ mt7531_setup_common(struct dsa_switch *ds)
+ 			   PVC_EG_TAG(MT7530_VLAN_EG_CONSISTENT));
+ 	}
+ 
++	/* Allow mirroring frames received on the local port (monitor port). */
++	mt7530_set(priv, MT753X_AGC, LOCAL_EN);
++
+ 	/* Flush the FDB table */
+ 	ret = mt7530_fdb_cmd(priv, MT7530_FDB_FLUSH, NULL);
+ 	if (ret < 0)
+diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
+index ddefeb69afda1..9388c1205bea2 100644
+--- a/drivers/net/dsa/mt7530.h
++++ b/drivers/net/dsa/mt7530.h
+@@ -32,6 +32,10 @@ enum mt753x_id {
+ #define SYSC_REG_RSTCTRL		0x34
+ #define  RESET_MCM			BIT(2)
+ 
++/* Register for ARL global control */
++#define MT753X_AGC			0xc
++#define  LOCAL_EN			BIT(7)
++
+ /* Registers to mac forward control for unknown frames */
+ #define MT7530_MFC			0x10
+ #define  BC_FFP(x)			(((x) & 0xff) << 24)
+-- 
+2.43.0
+
diff --git a/queue-6.6/net-dsa-mt7530-fix-port-mirroring-for-mt7988-soc-swi.patch b/queue-6.6/net-dsa-mt7530-fix-port-mirroring-for-mt7988-soc-swi.patch
new file mode 100644
index 0000000000..427eb5de77
--- /dev/null
+++ b/queue-6.6/net-dsa-mt7530-fix-port-mirroring-for-mt7988-soc-swi.patch
@@ -0,0 +1,58 @@
+From a4ae39b0d19ecbd62e40d4df8b670bd17775bfe2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 13 Apr 2024 16:01:40 +0300
+Subject: net: dsa: mt7530: fix port mirroring for MT7988 SoC switch
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Arınç ÜNAL <arinc.unal@arinc9.com>
+
+[ Upstream commit 2c606d138518cc69f09c35929abc414a99e3a28f ]
+
+The "MT7988A Wi-Fi 7 Generation Router Platform: Datasheet (Open Version)
+v0.1" document shows bits 16 to 18 as the MIRROR_PORT field of the CPU
+forward control register. Currently, the MT7530 DSA subdriver configures
+bits 0 to 2 of the CPU forward control register which breaks the port
+mirroring feature for the MT7988 SoC switch.
+
+Fix this by using the MT7531_MIRROR_PORT_GET() and MT7531_MIRROR_PORT_SET()
+macros which utilise the correct bits.
+
+Fixes: 110c18bfed41 ("net: dsa: mt7530: introduce driver for MT7988 built-in switch")
+Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
+Acked-by: Daniel Golle <daniel@makrotopia.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/mt7530.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
+index a123bb832db91..ea59f19a724c9 100644
+--- a/drivers/net/dsa/mt7530.c
++++ b/drivers/net/dsa/mt7530.c
+@@ -1948,14 +1948,16 @@ mt7530_port_vlan_del(struct dsa_switch *ds, int port,
+ 
+ static int mt753x_mirror_port_get(unsigned int id, u32 val)
+ {
+-	return (id == ID_MT7531) ? MT7531_MIRROR_PORT_GET(val) :
+-				   MIRROR_PORT(val);
++	return (id == ID_MT7531 || id == ID_MT7988) ?
++		       MT7531_MIRROR_PORT_GET(val) :
++		       MIRROR_PORT(val);
+ }
+ 
+ static int mt753x_mirror_port_set(unsigned int id, u32 val)
+ {
+-	return (id == ID_MT7531) ? MT7531_MIRROR_PORT_SET(val) :
+-				   MIRROR_PORT(val);
++	return (id == ID_MT7531 || id == ID_MT7988) ?
++		       MT7531_MIRROR_PORT_SET(val) :
++		       MIRROR_PORT(val);
+ }
+ 
+ static int mt753x_port_mirror_add(struct dsa_switch *ds, int port,
+-- 
+2.43.0
+
diff --git a/queue-6.6/net-ethernet-mtk_eth_soc-fix-wed-wifi-reset.patch b/queue-6.6/net-ethernet-mtk_eth_soc-fix-wed-wifi-reset.patch
new file mode 100644
index 0000000000..aa87af8279
--- /dev/null
+++ b/queue-6.6/net-ethernet-mtk_eth_soc-fix-wed-wifi-reset.patch
@@ -0,0 +1,64 @@
+From 7568923b5814e0ce0db3461ce5bd1855d5c9f4c8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 16 Apr 2024 10:23:29 +0200
+Subject: net: ethernet: mtk_eth_soc: fix WED + wifi reset
+
+From: Felix Fietkau <nbd@nbd.name>
+
+[ Upstream commit 94667949ec3bbb2218c46ad0a0e7274c8832e494 ]
+
+The WLAN + WED reset sequence relies on being able to receive interrupts from
+the card, in order to synchronize individual steps with the firmware.
+When WED is stopped, leave interrupts running and rely on the driver turning
+off unwanted ones.
+WED DMA also needs to be disabled before resetting.
+
+Fixes: f78cd9c783e0 ("net: ethernet: mtk_wed: update mtk_wed_stop")
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Link: https://lore.kernel.org/r/20240416082330.82564-1-nbd@nbd.name
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/mediatek/mtk_wed.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+diff --git a/drivers/net/ethernet/mediatek/mtk_wed.c b/drivers/net/ethernet/mediatek/mtk_wed.c
+index 94376aa2b34c5..c7196055c8c98 100644
+--- a/drivers/net/ethernet/mediatek/mtk_wed.c
++++ b/drivers/net/ethernet/mediatek/mtk_wed.c
+@@ -598,13 +598,13 @@ mtk_wed_dma_disable(struct mtk_wed_device *dev)
+ static void
+ mtk_wed_stop(struct mtk_wed_device *dev)
+ {
++	mtk_wed_dma_disable(dev);
+ 	mtk_wed_set_ext_int(dev, false);
+ 
+ 	wed_w32(dev, MTK_WED_WPDMA_INT_TRIGGER, 0);
+ 	wed_w32(dev, MTK_WED_WDMA_INT_TRIGGER, 0);
+ 	wdma_w32(dev, MTK_WDMA_INT_MASK, 0);
+ 	wdma_w32(dev, MTK_WDMA_INT_GRP2, 0);
+-	wed_w32(dev, MTK_WED_WPDMA_INT_MASK, 0);
+ 
+ 	if (dev->hw->version == 1)
+ 		return;
+@@ -617,7 +617,6 @@ static void
+ mtk_wed_deinit(struct mtk_wed_device *dev)
+ {
+ 	mtk_wed_stop(dev);
+-	mtk_wed_dma_disable(dev);
+ 
+ 	wed_clr(dev, MTK_WED_CTRL,
+ 		MTK_WED_CTRL_WDMA_INT_AGENT_EN |
+@@ -1703,9 +1702,6 @@ mtk_wed_irq_get(struct mtk_wed_device *dev, u32 mask)
+ static void
+ mtk_wed_irq_set_mask(struct mtk_wed_device *dev, u32 mask)
+ {
+-	if (!dev->running)
+-		return;
+-
+ 	mtk_wed_set_ext_int(dev, !!mask);
+ 	wed_w32(dev, MTK_WED_INT_MASK, mask);
+ }
+-- 
+2.43.0
+
diff --git a/queue-6.6/net-ethernet-ti-am65-cpsw-nuss-cleanup-dma-channels-.patch b/queue-6.6/net-ethernet-ti-am65-cpsw-nuss-cleanup-dma-channels-.patch
new file mode 100644
index 0000000000..7871808a1d
--- /dev/null
+++ b/queue-6.6/net-ethernet-ti-am65-cpsw-nuss-cleanup-dma-channels-.patch
@@ -0,0 +1,66 @@
+From 8ee70da8ce7d848e142f0ded98b82f91c1b6c58d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 17 Apr 2024 15:24:25 +0530
+Subject: net: ethernet: ti: am65-cpsw-nuss: cleanup DMA Channels before using
+ them
+
+From: Siddharth Vadapalli <s-vadapalli@ti.com>
+
+[ Upstream commit c24cd679b075b0e953ea167b0aa2b2d59e4eba7f ]
+
+The TX and RX DMA Channels used by the driver to exchange data with CPSW
+are not guaranteed to be in a clean state during driver initialization.
+The Bootloader could have used the same DMA Channels without cleaning them
+up in the event of failure. Thus, reset and disable the DMA Channels to
+ensure that they are in a clean state before using them.
+
+Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
+Reported-by: Schuyler Patton <spatton@ti.com>
+Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
+Reviewed-by: Roger Quadros <rogerq@kernel.org>
+Link: https://lore.kernel.org/r/20240417095425.2253876-1-s-vadapalli@ti.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/ti/am65-cpsw-nuss.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+index c62b0f99f2bc4..d556e705ec000 100644
+--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
++++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+@@ -2716,6 +2716,8 @@ static void am65_cpsw_unregister_devlink(struct am65_cpsw_common *common)
+ 
+ static int am65_cpsw_nuss_register_ndevs(struct am65_cpsw_common *common)
+ {
++	struct am65_cpsw_rx_chn *rx_chan = &common->rx_chns;
++	struct am65_cpsw_tx_chn *tx_chan = common->tx_chns;
+ 	struct device *dev = common->dev;
+ 	struct am65_cpsw_port *port;
+ 	int ret = 0, i;
+@@ -2728,6 +2730,22 @@ static int am65_cpsw_nuss_register_ndevs(struct am65_cpsw_common *common)
+ 	if (ret)
+ 		return ret;
+ 
++	/* The DMA Channels are not guaranteed to be in a clean state.
++	 * Reset and disable them to ensure that they are back to the
++	 * clean state and ready to be used.
++	 */
++	for (i = 0; i < common->tx_ch_num; i++) {
++		k3_udma_glue_reset_tx_chn(tx_chan[i].tx_chn, &tx_chan[i],
++					  am65_cpsw_nuss_tx_cleanup);
++		k3_udma_glue_disable_tx_chn(tx_chan[i].tx_chn);
++	}
++
++	for (i = 0; i < AM65_CPSW_MAX_RX_FLOWS; i++)
++		k3_udma_glue_reset_rx_chn(rx_chan->rx_chn, i, rx_chan,
++					  am65_cpsw_nuss_rx_cleanup, !!i);
++
++	k3_udma_glue_disable_rx_chn(rx_chan->rx_chn);
++
+ 	ret = am65_cpsw_nuss_register_devlink(common);
+ 	if (ret)
+ 		return ret;
+-- 
+2.43.0
+
diff --git a/queue-6.6/net-mlx5-lag-restore-buckets-number-to-default-after.patch b/queue-6.6/net-mlx5-lag-restore-buckets-number-to-default-after.patch
new file mode 100644
index 0000000000..3f8bce870d
--- /dev/null
+++ b/queue-6.6/net-mlx5-lag-restore-buckets-number-to-default-after.patch
@@ -0,0 +1,49 @@
+From c84564a89445744af4fd94dceab7e39f8b8dde34 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 11 Apr 2024 14:54:39 +0300
+Subject: net/mlx5: Lag, restore buckets number to default after hash LAG
+ deactivation
+
+From: Shay Drory <shayd@nvidia.com>
+
+[ Upstream commit 37cc10da3a50e6d0cb9808a90b7da9b4868794dd ]
+
+The cited patch introduces the concept of buckets in LAG in hash mode.
+However, the patch doesn't clear the number of buckets in the LAG
+deactivation. This results in using the wrong number of buckets in
+case user create a hash mode LAG and afterwards create a non-hash
+mode LAG.
+
+Hence, restore buckets number to default after hash mode LAG
+deactivation.
+
+Fixes: 352899f384d4 ("net/mlx5: Lag, use buckets in hash mode")
+Signed-off-by: Shay Drory <shayd@nvidia.com>
+Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
+Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
+Link: https://lore.kernel.org/r/20240411115444.374475-2-tariqt@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c b/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c
+index af3fac090b828..e51cac1e1811e 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c
+@@ -703,8 +703,10 @@ int mlx5_deactivate_lag(struct mlx5_lag *ldev)
+ 		return err;
+ 	}
+ 
+-	if (test_bit(MLX5_LAG_MODE_FLAG_HASH_BASED, &flags))
++	if (test_bit(MLX5_LAG_MODE_FLAG_HASH_BASED, &flags)) {
+ 		mlx5_lag_port_sel_destroy(ldev);
++		ldev->buckets = 1;
++	}
+ 	if (mlx5_lag_has_drop_rule(ldev))
+ 		mlx5_lag_drop_rule_cleanup(ldev);
+ 
+-- 
+2.43.0
+
diff --git a/queue-6.6/net-mlx5e-prevent-deadlock-while-disabling-arfs.patch b/queue-6.6/net-mlx5e-prevent-deadlock-while-disabling-arfs.patch
new file mode 100644
index 0000000000..9ab3f1281b
--- /dev/null
+++ b/queue-6.6/net-mlx5e-prevent-deadlock-while-disabling-arfs.patch
@@ -0,0 +1,213 @@
+From 3cb0b8e3e641e022a220fc9fc68c380060d421bd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 11 Apr 2024 14:54:44 +0300
+Subject: net/mlx5e: Prevent deadlock while disabling aRFS
+
+From: Carolina Jubran <cjubran@nvidia.com>
+
+[ Upstream commit fef965764cf562f28afb997b626fc7c3cec99693 ]
+
+When disabling aRFS under the `priv->state_lock`, any scheduled
+aRFS works are canceled using the `cancel_work_sync` function,
+which waits for the work to end if it has already started.
+However, while waiting for the work handler, the handler will
+try to acquire the `state_lock` which is already acquired.
+
+The worker acquires the lock to delete the rules if the state
+is down, which is not the worker's responsibility since
+disabling aRFS deletes the rules.
+
+Add an aRFS state variable, which indicates whether the aRFS is
+enabled and prevent adding rules when the aRFS is disabled.
+
+Kernel log:
+
+======================================================
+WARNING: possible circular locking dependency detected
+6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G          I
+------------------------------------------------------
+ethtool/386089 is trying to acquire lock:
+ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
+
+but task is already holding lock:
+ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
+
+which lock already depends on the new lock.
+
+the existing dependency chain (in reverse order) is:
+
+-> #1 (&priv->state_lock){+.+.}-{3:3}:
+       __mutex_lock+0x80/0xc90
+       arfs_handle_work+0x4b/0x3b0 [mlx5_core]
+       process_one_work+0x1dc/0x4a0
+       worker_thread+0x1bf/0x3c0
+       kthread+0xd7/0x100
+       ret_from_fork+0x2d/0x50
+       ret_from_fork_asm+0x11/0x20
+
+-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}:
+       __lock_acquire+0x17b4/0x2c80
+       lock_acquire+0xd0/0x2b0
+       __flush_work+0x7a/0x4e0
+       __cancel_work_timer+0x131/0x1c0
+       arfs_del_rules+0x143/0x1e0 [mlx5_core]
+       mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
+       mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
+       ethnl_set_channels+0x28f/0x3b0
+       ethnl_default_set_doit+0xec/0x240
+       genl_family_rcv_msg_doit+0xd0/0x120
+       genl_rcv_msg+0x188/0x2c0
+       netlink_rcv_skb+0x54/0x100
+       genl_rcv+0x24/0x40
+       netlink_unicast+0x1a1/0x270
+       netlink_sendmsg+0x214/0x460
+       __sock_sendmsg+0x38/0x60
+       __sys_sendto+0x113/0x170
+       __x64_sys_sendto+0x20/0x30
+       do_syscall_64+0x40/0xe0
+       entry_SYSCALL_64_after_hwframe+0x46/0x4e
+
+other info that might help us debug this:
+
+ Possible unsafe locking scenario:
+
+       CPU0                    CPU1
+       ----                    ----
+  lock(&priv->state_lock);
+                               lock((work_completion)(&rule->arfs_work));
+                               lock(&priv->state_lock);
+  lock((work_completion)(&rule->arfs_work));
+
+ *** DEADLOCK ***
+
+3 locks held by ethtool/386089:
+ #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40
+ #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240
+ #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
+
+stack backtrace:
+CPU: 15 PID: 386089 Comm: ethtool Tainted: G          I        6.7.0-rc4_net_next_mlx5_5483eb2 #1
+Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x60/0xa0
+ check_noncircular+0x144/0x160
+ __lock_acquire+0x17b4/0x2c80
+ lock_acquire+0xd0/0x2b0
+ ? __flush_work+0x74/0x4e0
+ ? save_trace+0x3e/0x360
+ ? __flush_work+0x74/0x4e0
+ __flush_work+0x7a/0x4e0
+ ? __flush_work+0x74/0x4e0
+ ? __lock_acquire+0xa78/0x2c80
+ ? lock_acquire+0xd0/0x2b0
+ ? mark_held_locks+0x49/0x70
+ __cancel_work_timer+0x131/0x1c0
+ ? mark_held_locks+0x49/0x70
+ arfs_del_rules+0x143/0x1e0 [mlx5_core]
+ mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
+ mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
+ ethnl_set_channels+0x28f/0x3b0
+ ethnl_default_set_doit+0xec/0x240
+ genl_family_rcv_msg_doit+0xd0/0x120
+ genl_rcv_msg+0x188/0x2c0
+ ? ethnl_ops_begin+0xb0/0xb0
+ ? genl_family_rcv_msg_dumpit+0xf0/0xf0
+ netlink_rcv_skb+0x54/0x100
+ genl_rcv+0x24/0x40
+ netlink_unicast+0x1a1/0x270
+ netlink_sendmsg+0x214/0x460
+ __sock_sendmsg+0x38/0x60
+ __sys_sendto+0x113/0x170
+ ? do_user_addr_fault+0x53f/0x8f0
+ __x64_sys_sendto+0x20/0x30
+ do_syscall_64+0x40/0xe0
+ entry_SYSCALL_64_after_hwframe+0x46/0x4e
+ </TASK>
+
+Fixes: 45bf454ae884 ("net/mlx5e: Enabling aRFS mechanism")
+Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
+Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
+Link: https://lore.kernel.org/r/20240411115444.374475-7-tariqt@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/mellanox/mlx5/core/en_arfs.c | 27 +++++++++++--------
+ 1 file changed, 16 insertions(+), 11 deletions(-)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c b/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c
+index e66f486faafe1..415fec7763bd2 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c
+@@ -45,6 +45,10 @@ struct arfs_table {
+ 	struct hlist_head	 rules_hash[ARFS_HASH_SIZE];
+ };
+ 
++enum {
++	MLX5E_ARFS_STATE_ENABLED,
++};
++
+ enum arfs_type {
+ 	ARFS_IPV4_TCP,
+ 	ARFS_IPV6_TCP,
+@@ -59,6 +63,7 @@ struct mlx5e_arfs_tables {
+ 	spinlock_t                     arfs_lock;
+ 	int                            last_filter_id;
+ 	struct workqueue_struct        *wq;
++	unsigned long                  state;
+ };
+ 
+ struct arfs_tuple {
+@@ -169,6 +174,8 @@ int mlx5e_arfs_enable(struct mlx5e_flow_steering *fs)
+ 			return err;
+ 		}
+ 	}
++	set_bit(MLX5E_ARFS_STATE_ENABLED, &arfs->state);
++
+ 	return 0;
+ }
+ 
+@@ -454,6 +461,8 @@ static void arfs_del_rules(struct mlx5e_flow_steering *fs)
+ 	int i;
+ 	int j;
+ 
++	clear_bit(MLX5E_ARFS_STATE_ENABLED, &arfs->state);
++
+ 	spin_lock_bh(&arfs->arfs_lock);
+ 	mlx5e_for_each_arfs_rule(rule, htmp, arfs->arfs_tables, i, j) {
+ 		hlist_del_init(&rule->hlist);
+@@ -626,17 +635,8 @@ static void arfs_handle_work(struct work_struct *work)
+ 	struct mlx5_flow_handle *rule;
+ 
+ 	arfs = mlx5e_fs_get_arfs(priv->fs);
+-	mutex_lock(&priv->state_lock);
+-	if (!test_bit(MLX5E_STATE_OPENED, &priv->state)) {
+-		spin_lock_bh(&arfs->arfs_lock);
+-		hlist_del(&arfs_rule->hlist);
+-		spin_unlock_bh(&arfs->arfs_lock);
+-
+-		mutex_unlock(&priv->state_lock);
+-		kfree(arfs_rule);
+-		goto out;
+-	}
+-	mutex_unlock(&priv->state_lock);
++	if (!test_bit(MLX5E_ARFS_STATE_ENABLED, &arfs->state))
++		return;
+ 
+ 	if (!arfs_rule->rule) {
+ 		rule = arfs_add_rule(priv, arfs_rule);
+@@ -752,6 +752,11 @@ int mlx5e_rx_flow_steer(struct net_device *dev, const struct sk_buff *skb,
+ 		return -EPROTONOSUPPORT;
+ 
+ 	spin_lock_bh(&arfs->arfs_lock);
++	if (!test_bit(MLX5E_ARFS_STATE_ENABLED, &arfs->state)) {
++		spin_unlock_bh(&arfs->arfs_lock);
++		return -EPERM;
++	}
++
+ 	arfs_rule = arfs_find_rule(arfs_t, &fk);
+ 	if (arfs_rule) {
+ 		if (arfs_rule->rxq == rxq_index || work_busy(&arfs_rule->arfs_work)) {
+-- 
+2.43.0
+
diff --git a/queue-6.6/net-sparx5-flower-fix-fragment-flags-handling.patch b/queue-6.6/net-sparx5-flower-fix-fragment-flags-handling.patch
new file mode 100644
index 0000000000..be2f8e29d8
--- /dev/null
+++ b/queue-6.6/net-sparx5-flower-fix-fragment-flags-handling.patch
@@ -0,0 +1,168 @@
+From c262bd347a870fa9dd750a597c365c3eeee72842 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 11 Apr 2024 11:13:18 +0000
+Subject: net: sparx5: flower: fix fragment flags handling
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Asbjørn Sloth Tønnesen <ast@fiberby.net>
+
+[ Upstream commit 68aba00483c7c4102429bcdfdece7289a8ab5c8e ]
+
+I noticed that only 3 out of the 4 input bits were used,
+mt.key->flags & FLOW_DIS_IS_FRAGMENT was never checked.
+
+In order to avoid a complicated maze, I converted it to
+use a 16 byte mapping table.
+
+As shown in the table below the old heuristics doesn't
+always do the right thing, ie. when FLOW_DIS_IS_FRAGMENT=1/1
+then it used to only match follow-up fragment packets.
+
+Here are all the combinations, and their resulting new/old
+VCAP key/mask filter:
+
+  /- FLOW_DIS_IS_FRAGMENT (key/mask)
+  |    /- FLOW_DIS_FIRST_FRAG (key/mask)
+  |    |    /-- new VCAP fragment (key/mask)
+  v    v    v    v- old VCAP fragment (key/mask)
+
+ 0/0  0/0  -/-  -/-     impossible (due to entry cond. on mask)
+ 0/0  0/1  -/-  0/3 !!  invalid (can't match non-fragment + follow-up frag)
+ 0/0  1/0  -/-  -/-     impossible (key > mask)
+ 0/0  1/1  1/3  1/3     first fragment
+
+ 0/1  0/0  0/3  3/3 !!  not fragmented
+ 0/1  0/1  0/3  3/3 !!  not fragmented (+ not first fragment)
+ 0/1  1/0  -/-  -/-     impossible (key > mask)
+ 0/1  1/1  -/-  1/3 !!  invalid (non-fragment and first frag)
+
+ 1/0  0/0  -/-  -/-     impossible (key > mask)
+ 1/0  0/1  -/-  -/-     impossible (key > mask)
+ 1/0  1/0  -/-  -/-     impossible (key > mask)
+ 1/0  1/1  -/-  -/-     impossible (key > mask)
+
+ 1/1  0/0  1/1  3/3 !!  some fragment
+ 1/1  0/1  3/3  3/3     follow-up fragment
+ 1/1  1/0  -/-  -/-     impossible (key > mask)
+ 1/1  1/1  1/3  1/3     first fragment
+
+In the datasheet the VCAP fragment values are documented as:
+ 0 = no fragment
+ 1 = initial fragment
+ 2 = suspicious fragment
+ 3 = valid follow-up fragment
+
+Result: 3 combinations match the old behavior,
+        3 combinations have been corrected,
+        2 combinations are now invalid, and fail,
+        8 combinations are impossible.
+
+It should now be aligned with how FLOW_DIS_IS_FRAGMENT
+and FLOW_DIS_FIRST_FRAG is set in __skb_flow_dissect() in
+net/core/flow_dissector.c
+
+Since the VCAP fragment values are not a bitfield, we have
+to ignore the suspicious fragment value, eg. when matching
+on any kind of fragment with FLOW_DIS_IS_FRAGMENT=1/1.
+
+Only compile tested, and logic tested in userspace, as I
+unfortunately don't have access to this switch chip (yet).
+
+Fixes: d6c2964db3fe ("net: microchip: sparx5: Adding more tc flower keys for the IS2 VCAP")
+Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
+Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
+Tested-by: Daniel Machon <daniel.machon@microchip.com>
+Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
+Link: https://lore.kernel.org/r/20240411111321.114095-1-ast@fiberby.net
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../microchip/sparx5/sparx5_tc_flower.c       | 61 ++++++++++++-------
+ 1 file changed, 40 insertions(+), 21 deletions(-)
+
+diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_tc_flower.c b/drivers/net/ethernet/microchip/sparx5/sparx5_tc_flower.c
+index 523e0c470894f..55f255a3c9db6 100644
+--- a/drivers/net/ethernet/microchip/sparx5/sparx5_tc_flower.c
++++ b/drivers/net/ethernet/microchip/sparx5/sparx5_tc_flower.c
+@@ -36,6 +36,27 @@ struct sparx5_tc_flower_template {
+ 	u16 l3_proto; /* protocol specified in the template */
+ };
+ 
++/* SparX-5 VCAP fragment types:
++ * 0 = no fragment, 1 = initial fragment,
++ * 2 = suspicious fragment, 3 = valid follow-up fragment
++ */
++enum {                   /* key / mask */
++	FRAG_NOT   = 0x03, /* 0 / 3 */
++	FRAG_SOME  = 0x11, /* 1 / 1 */
++	FRAG_FIRST = 0x13, /* 1 / 3 */
++	FRAG_LATER = 0x33, /* 3 / 3 */
++	FRAG_INVAL = 0xff, /* invalid */
++};
++
++/* Flower fragment flag to VCAP fragment type mapping */
++static const u8 sparx5_vcap_frag_map[4][4] = {		  /* is_frag */
++	{ FRAG_INVAL, FRAG_INVAL, FRAG_INVAL, FRAG_FIRST }, /* 0/0 */
++	{ FRAG_NOT,   FRAG_NOT,   FRAG_INVAL, FRAG_INVAL }, /* 0/1 */
++	{ FRAG_INVAL, FRAG_INVAL, FRAG_INVAL, FRAG_INVAL }, /* 1/0 */
++	{ FRAG_SOME,  FRAG_LATER, FRAG_INVAL, FRAG_FIRST }  /* 1/1 */
++	/* 0/0	      0/1	  1/0	      1/1 <-- first_frag */
++};
++
+ static int
+ sparx5_tc_flower_es0_tpid(struct vcap_tc_flower_parse_usage *st)
+ {
+@@ -145,29 +166,27 @@ sparx5_tc_flower_handler_control_usage(struct vcap_tc_flower_parse_usage *st)
+ 	flow_rule_match_control(st->frule, &mt);
+ 
+ 	if (mt.mask->flags) {
+-		if (mt.mask->flags & FLOW_DIS_FIRST_FRAG) {
+-			if (mt.key->flags & FLOW_DIS_FIRST_FRAG) {
+-				value = 1; /* initial fragment */
+-				mask = 0x3;
+-			} else {
+-				if (mt.mask->flags & FLOW_DIS_IS_FRAGMENT) {
+-					value = 3; /* follow up fragment */
+-					mask = 0x3;
+-				} else {
+-					value = 0; /* no fragment */
+-					mask = 0x3;
+-				}
+-			}
+-		} else {
+-			if (mt.mask->flags & FLOW_DIS_IS_FRAGMENT) {
+-				value = 3; /* follow up fragment */
+-				mask = 0x3;
+-			} else {
+-				value = 0; /* no fragment */
+-				mask = 0x3;
+-			}
++		u8 is_frag_key = !!(mt.key->flags & FLOW_DIS_IS_FRAGMENT);
++		u8 is_frag_mask = !!(mt.mask->flags & FLOW_DIS_IS_FRAGMENT);
++		u8 is_frag_idx = (is_frag_key << 1) | is_frag_mask;
++
++		u8 first_frag_key = !!(mt.key->flags & FLOW_DIS_FIRST_FRAG);
++		u8 first_frag_mask = !!(mt.mask->flags & FLOW_DIS_FIRST_FRAG);
++		u8 first_frag_idx = (first_frag_key << 1) | first_frag_mask;
++
++		/* Lookup verdict based on the 2 + 2 input bits */
++		u8 vdt = sparx5_vcap_frag_map[is_frag_idx][first_frag_idx];
++
++		if (vdt == FRAG_INVAL) {
++			NL_SET_ERR_MSG_MOD(st->fco->common.extack,
++					   "Match on invalid fragment flag combination");
++			return -EINVAL;
+ 		}
+ 
++		/* Extract VCAP fragment key and mask from verdict */
++		value = (vdt >> 4) & 0x3;
++		mask = vdt & 0x3;
++
+ 		err = vcap_rule_add_key_u32(st->vrule,
+ 					    VCAP_KF_L3_FRAGMENT_TYPE,
+ 					    value, mask);
+-- 
+2.43.0
+
diff --git a/queue-6.6/net-stmmac-apply-half-duplex-less-constraint-for-dw-.patch b/queue-6.6/net-stmmac-apply-half-duplex-less-constraint-for-dw-.patch
new file mode 100644
index 0000000000..dd841af433
--- /dev/null
+++ b/queue-6.6/net-stmmac-apply-half-duplex-less-constraint-for-dw-.patch
@@ -0,0 +1,101 @@
+From 5c4c99ad595b5fccbe475dd88e907972ffb41c40 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 12 Apr 2024 21:03:14 +0300
+Subject: net: stmmac: Apply half-duplex-less constraint for DW QoS Eth only
+
+From: Serge Semin <fancer.lancer@gmail.com>
+
+[ Upstream commit 0ebd96f5da4410c0cb8fc75e44f1009530b2f90b ]
+
+There are three DW MAC IP-cores which can have the multiple Tx/Rx queues
+enabled:
+DW GMAC v3.7+ with AV feature,
+DW QoS Eth v4.x/v5.x,
+DW XGMAC/XLGMAC
+Based on the respective HW databooks, only the DW QoS Eth IP-core doesn't
+support the half-duplex link mode in case if more than one queues enabled:
+
+"In multiple queue/channel configurations, for half-duplex operation,
+enable only the Q0/CH0 on Tx and Rx. For single queue/channel in
+full-duplex operation, any queue/channel can be enabled."
+
+The rest of the IP-cores don't have such constraint. Thus in order to have
+the constraint applied for the DW QoS Eth MACs only, let's move the it'
+implementation to the respective MAC-capabilities getter and make sure the
+getter is called in the queues re-init procedure.
+
+Fixes: b6cfffa7ad92 ("stmmac: fix DMA channel hang in half-duplex mode")
+Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
+Reviewed-by: Romain Gantois <romain.gantois@bootlin.com>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/stmicro/stmmac/dwmac4_core.c |  7 +++++++
+ .../net/ethernet/stmicro/stmmac/stmmac_main.c | 19 +++----------------
+ 2 files changed, 10 insertions(+), 16 deletions(-)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+index 683c34e609638..434e306876b41 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+@@ -71,6 +71,13 @@ static void dwmac4_core_init(struct mac_device_info *hw,
+ static void dwmac4_phylink_get_caps(struct stmmac_priv *priv)
+ {
+ 	priv->phylink_config.mac_capabilities |= MAC_2500FD;
++
++	if (priv->plat->tx_queues_to_use > 1)
++		priv->phylink_config.mac_capabilities &=
++			~(MAC_10HD | MAC_100HD | MAC_1000HD);
++	else
++		priv->phylink_config.mac_capabilities |=
++			(MAC_10HD | MAC_100HD | MAC_1000HD);
+ }
+ 
+ static void dwmac4_rx_queue_enable(struct mac_device_info *hw,
+diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+index d1adb102a1d49..f3dbbc900d498 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+@@ -1198,17 +1198,6 @@ static int stmmac_init_phy(struct net_device *dev)
+ 	return ret;
+ }
+ 
+-static void stmmac_set_half_duplex(struct stmmac_priv *priv)
+-{
+-	/* Half-Duplex can only work with single tx queue */
+-	if (priv->plat->tx_queues_to_use > 1)
+-		priv->phylink_config.mac_capabilities &=
+-			~(MAC_10HD | MAC_100HD | MAC_1000HD);
+-	else
+-		priv->phylink_config.mac_capabilities |=
+-			(MAC_10HD | MAC_100HD | MAC_1000HD);
+-}
+-
+ static int stmmac_phy_setup(struct stmmac_priv *priv)
+ {
+ 	struct stmmac_mdio_bus_data *mdio_bus_data;
+@@ -1237,10 +1226,7 @@ static int stmmac_phy_setup(struct stmmac_priv *priv)
+ 				    priv->phylink_config.supported_interfaces);
+ 
+ 	priv->phylink_config.mac_capabilities = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
+-						MAC_10FD | MAC_100FD |
+-						MAC_1000FD;
+-
+-	stmmac_set_half_duplex(priv);
++						MAC_10 | MAC_100 | MAC_1000;
+ 
+ 	/* Get the MAC specific capabilities */
+ 	stmmac_mac_phylink_get_caps(priv);
+@@ -7197,7 +7183,8 @@ int stmmac_reinit_queues(struct net_device *dev, u32 rx_cnt, u32 tx_cnt)
+ 			priv->rss.table[i] = ethtool_rxfh_indir_default(i,
+ 									rx_cnt);
+ 
+-	stmmac_set_half_duplex(priv);
++	stmmac_mac_phylink_get_caps(priv);
++
+ 	stmmac_napi_add(dev);
+ 
+ 	if (netif_running(dev))
+-- 
+2.43.0
+
diff --git a/queue-6.6/net-stmmac-fix-ip-cores-specific-mac-capabilities.patch b/queue-6.6/net-stmmac-fix-ip-cores-specific-mac-capabilities.patch
new file mode 100644
index 0000000000..5da3d0be50
--- /dev/null
+++ b/queue-6.6/net-stmmac-fix-ip-cores-specific-mac-capabilities.patch
@@ -0,0 +1,245 @@
+From 69e0478b63a4dc000d453f1dce3cd0c16f48a43e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 12 Apr 2024 21:03:16 +0300
+Subject: net: stmmac: Fix IP-cores specific MAC capabilities
+
+From: Serge Semin <fancer.lancer@gmail.com>
+
+[ Upstream commit 9cb54af214a7cdc91577ec083e5569f2ce2c86d8 ]
+
+Here is the list of the MAC capabilities specific to the particular DW MAC
+IP-cores currently supported by the driver:
+
+DW MAC100: MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
+	   MAC_10 | MAC_100
+
+DW GMAC:  MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
+          MAC_10 | MAC_100 | MAC_1000
+
+Allwinner sun8i MAC: MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
+                     MAC_10 | MAC_100 | MAC_1000
+
+DW QoS Eth: MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
+            MAC_10 | MAC_100 | MAC_1000 | MAC_2500FD
+if there is more than 1 active Tx/Rx queues:
+	   MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
+           MAC_10FD | MAC_100FD | MAC_1000FD | MAC_2500FD
+
+DW XGMAC: MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
+          MAC_1000FD | MAC_2500FD | MAC_5000FD | MAC_10000FD
+
+DW XLGMAC: MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
+          MAC_1000FD | MAC_2500FD | MAC_5000FD | MAC_10000FD |
+          MAC_25000FD | MAC_40000FD | MAC_50000FD | MAC_100000FD
+
+As you can see there are only two common capabilities:
+MAC_ASYM_PAUSE | MAC_SYM_PAUSE.
+Meanwhile what is currently implemented defines 10/100/1000 link speeds
+for all IP-cores, which is definitely incorrect for DW MAC100, DW XGMAC
+and DW XLGMAC devices.
+
+Seeing the flow-control is implemented as a callback for each MAC IP-core
+(see dwmac100_flow_ctrl(), dwmac1000_flow_ctrl(), sun8i_dwmac_flow_ctrl(),
+etc) and since the MAC-specific setup() method is supposed to be called
+for each available DW MAC-based device, the capabilities initialization
+can be freely moved to these setup() functions, thus correctly setting up
+the MAC-capabilities for each IP-core (including the Allwinner Sun8i). A
+new stmmac_link::caps field was specifically introduced for that so to
+have all link-specific info preserved in a single structure.
+
+Note the suggested change fixes three earlier commits at a time. The
+commit 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC
+supports") permitted the 10-100 link speeds and 1G half-duplex mode for DW
+XGMAC IP-core even though it doesn't support them. The commit df7699c70c1b
+("net: stmmac: Do not cut down 1G modes") incorrectly added the MAC1000
+capability to the DW MAC100 IP-core. Similarly to the DW XGMAC the commit
+8a880936e902 ("net: stmmac: Add XLGMII support") incorrectly permitted the
+10-100 link speeds and 1G half-duplex mode for DW XLGMAC IP-core.
+
+Fixes: 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
+Fixes: df7699c70c1b ("net: stmmac: Do not cut down 1G modes")
+Fixes: 8a880936e902 ("net: stmmac: Add XLGMII support")
+Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk>
+Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
+Reviewed-by: Romain Gantois <romain.gantois@bootlin.com>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/common.h   |  1 +
+ .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c  |  2 ++
+ .../ethernet/stmicro/stmmac/dwmac1000_core.c   |  2 ++
+ .../ethernet/stmicro/stmmac/dwmac100_core.c    |  2 ++
+ .../net/ethernet/stmicro/stmmac/dwmac4_core.c  | 10 ++++------
+ .../ethernet/stmicro/stmmac/dwxgmac2_core.c    | 18 ++++++++----------
+ .../net/ethernet/stmicro/stmmac/stmmac_main.c  |  7 ++++---
+ 7 files changed, 23 insertions(+), 19 deletions(-)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
+index b0dd8adce3560..4dbc076f72d65 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/common.h
++++ b/drivers/net/ethernet/stmicro/stmmac/common.h
+@@ -550,6 +550,7 @@ extern const struct stmmac_hwtimestamp stmmac_ptp;
+ extern const struct stmmac_mode_ops dwmac4_ring_mode_ops;
+ 
+ struct mac_link {
++	u32 caps;
+ 	u32 speed_mask;
+ 	u32 speed10;
+ 	u32 speed100;
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+index 51f121f867457..63998d65fef8e 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+@@ -1096,6 +1096,8 @@ static struct mac_device_info *sun8i_dwmac_setup(void *ppriv)
+ 
+ 	priv->dev->priv_flags |= IFF_UNICAST_FLT;
+ 
++	mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
++			 MAC_10 | MAC_100 | MAC_1000;
+ 	/* The loopback bit seems to be re-set when link change
+ 	 * Simply mask it each time
+ 	 * Speed 10/100/1000 are set in BIT(2)/BIT(3)
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+index 3927609abc441..8555299443f4e 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+@@ -539,6 +539,8 @@ int dwmac1000_setup(struct stmmac_priv *priv)
+ 	if (mac->multicast_filter_bins)
+ 		mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
+ 
++	mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
++			 MAC_10 | MAC_100 | MAC_1000;
+ 	mac->link.duplex = GMAC_CONTROL_DM;
+ 	mac->link.speed10 = GMAC_CONTROL_PS;
+ 	mac->link.speed100 = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+index a6e8d7bd95886..7667d103cd0eb 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+@@ -175,6 +175,8 @@ int dwmac100_setup(struct stmmac_priv *priv)
+ 	dev_info(priv->device, "\tDWMAC100\n");
+ 
+ 	mac->pcsr = priv->ioaddr;
++	mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
++			 MAC_10 | MAC_100;
+ 	mac->link.duplex = MAC_CONTROL_F;
+ 	mac->link.speed10 = 0;
+ 	mac->link.speed100 = 0;
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+index 434e306876b41..4ead0ddf43a7a 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+@@ -70,14 +70,10 @@ static void dwmac4_core_init(struct mac_device_info *hw,
+ 
+ static void dwmac4_phylink_get_caps(struct stmmac_priv *priv)
+ {
+-	priv->phylink_config.mac_capabilities |= MAC_2500FD;
+-
+ 	if (priv->plat->tx_queues_to_use > 1)
+-		priv->phylink_config.mac_capabilities &=
+-			~(MAC_10HD | MAC_100HD | MAC_1000HD);
++		priv->hw->link.caps &= ~(MAC_10HD | MAC_100HD | MAC_1000HD);
+ 	else
+-		priv->phylink_config.mac_capabilities |=
+-			(MAC_10HD | MAC_100HD | MAC_1000HD);
++		priv->hw->link.caps |= (MAC_10HD | MAC_100HD | MAC_1000HD);
+ }
+ 
+ static void dwmac4_rx_queue_enable(struct mac_device_info *hw,
+@@ -1354,6 +1350,8 @@ int dwmac4_setup(struct stmmac_priv *priv)
+ 	if (mac->multicast_filter_bins)
+ 		mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
+ 
++	mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
++			 MAC_10 | MAC_100 | MAC_1000 | MAC_2500FD;
+ 	mac->link.duplex = GMAC_CONFIG_DM;
+ 	mac->link.speed10 = GMAC_CONFIG_PS;
+ 	mac->link.speed100 = GMAC_CONFIG_FES | GMAC_CONFIG_PS;
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+index 24c53b7255a2e..8bc317d2f7a61 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+@@ -47,14 +47,6 @@ static void dwxgmac2_core_init(struct mac_device_info *hw,
+ 	writel(XGMAC_INT_DEFAULT_EN, ioaddr + XGMAC_INT_EN);
+ }
+ 
+-static void xgmac_phylink_get_caps(struct stmmac_priv *priv)
+-{
+-	priv->phylink_config.mac_capabilities |= MAC_2500FD | MAC_5000FD |
+-						 MAC_10000FD | MAC_25000FD |
+-						 MAC_40000FD | MAC_50000FD |
+-						 MAC_100000FD;
+-}
+-
+ static void dwxgmac2_set_mac(void __iomem *ioaddr, bool enable)
+ {
+ 	u32 tx = readl(ioaddr + XGMAC_TX_CONFIG);
+@@ -1591,7 +1583,6 @@ static void dwxgmac3_fpe_configure(void __iomem *ioaddr, struct stmmac_fpe_cfg *
+ 
+ const struct stmmac_ops dwxgmac210_ops = {
+ 	.core_init = dwxgmac2_core_init,
+-	.phylink_get_caps = xgmac_phylink_get_caps,
+ 	.set_mac = dwxgmac2_set_mac,
+ 	.rx_ipc = dwxgmac2_rx_ipc,
+ 	.rx_queue_enable = dwxgmac2_rx_queue_enable,
+@@ -1653,7 +1644,6 @@ static void dwxlgmac2_rx_queue_enable(struct mac_device_info *hw, u8 mode,
+ 
+ const struct stmmac_ops dwxlgmac2_ops = {
+ 	.core_init = dwxgmac2_core_init,
+-	.phylink_get_caps = xgmac_phylink_get_caps,
+ 	.set_mac = dwxgmac2_set_mac,
+ 	.rx_ipc = dwxgmac2_rx_ipc,
+ 	.rx_queue_enable = dwxlgmac2_rx_queue_enable,
+@@ -1714,6 +1704,9 @@ int dwxgmac2_setup(struct stmmac_priv *priv)
+ 	if (mac->multicast_filter_bins)
+ 		mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
+ 
++	mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
++			 MAC_1000FD | MAC_2500FD | MAC_5000FD |
++			 MAC_10000FD;
+ 	mac->link.duplex = 0;
+ 	mac->link.speed10 = XGMAC_CONFIG_SS_10_MII;
+ 	mac->link.speed100 = XGMAC_CONFIG_SS_100_MII;
+@@ -1751,6 +1744,11 @@ int dwxlgmac2_setup(struct stmmac_priv *priv)
+ 	if (mac->multicast_filter_bins)
+ 		mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
+ 
++	mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
++			 MAC_1000FD | MAC_2500FD | MAC_5000FD |
++			 MAC_10000FD | MAC_25000FD |
++			 MAC_40000FD | MAC_50000FD |
++			 MAC_100000FD;
+ 	mac->link.duplex = 0;
+ 	mac->link.speed1000 = XLGMAC_CONFIG_SS_1000;
+ 	mac->link.speed2500 = XLGMAC_CONFIG_SS_2500;
+diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+index 2479e9a5f9d22..19c58ad8df345 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+@@ -1225,12 +1225,11 @@ static int stmmac_phy_setup(struct stmmac_priv *priv)
+ 		xpcs_get_interfaces(priv->hw->xpcs,
+ 				    priv->phylink_config.supported_interfaces);
+ 
+-	priv->phylink_config.mac_capabilities = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
+-						MAC_10 | MAC_100 | MAC_1000;
+-
+ 	/* Get the MAC specific capabilities */
+ 	stmmac_mac_phylink_get_caps(priv);
+ 
++	priv->phylink_config.mac_capabilities = priv->hw->link.caps;
++
+ 	max_speed = priv->plat->max_speed;
+ 	if (max_speed)
+ 		phylink_limit_mac_speed(&priv->phylink_config, max_speed);
+@@ -7186,6 +7185,8 @@ int stmmac_reinit_queues(struct net_device *dev, u32 rx_cnt, u32 tx_cnt)
+ 
+ 	stmmac_mac_phylink_get_caps(priv);
+ 
++	priv->phylink_config.mac_capabilities = priv->hw->link.caps;
++
+ 	max_speed = priv->plat->max_speed;
+ 	if (max_speed)
+ 		phylink_limit_mac_speed(&priv->phylink_config, max_speed);
+-- 
+2.43.0
+
diff --git a/queue-6.6/net-stmmac-fix-max-speed-being-ignored-on-queue-re-i.patch b/queue-6.6/net-stmmac-fix-max-speed-being-ignored-on-queue-re-i.patch
new file mode 100644
index 0000000000..cefbadf829
--- /dev/null
+++ b/queue-6.6/net-stmmac-fix-max-speed-being-ignored-on-queue-re-i.patch
@@ -0,0 +1,57 @@
+From 2368f7863b8e86562ef3cb6a47f696f317edc6ef Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 12 Apr 2024 21:03:15 +0300
+Subject: net: stmmac: Fix max-speed being ignored on queue re-init
+
+From: Serge Semin <fancer.lancer@gmail.com>
+
+[ Upstream commit 59c3d6ca6cbded6c6599e975b42a9d6a27fcbaf2 ]
+
+It's possible to have the maximum link speed being artificially limited on
+the platform-specific basis. It's done either by setting up the
+plat_stmmacenet_data::max_speed field or by specifying the "max-speed"
+DT-property. In such cases it's required that any specific
+MAC-capabilities re-initializations would take the limit into account. In
+particular the link speed capabilities may change during the number of
+active Tx/Rx queues re-initialization. But the currently implemented
+procedure doesn't take the speed limit into account.
+
+Fix that by calling phylink_limit_mac_speed() in the
+stmmac_reinit_queues() method if the speed limitation was required in the
+same way as it's done in the stmmac_phy_setup() function.
+
+Fixes: 95201f36f395 ("net: stmmac: update MAC capabilities when tx queues are updated")
+Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
+Reviewed-by: Romain Gantois <romain.gantois@bootlin.com>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+index f3dbbc900d498..2479e9a5f9d22 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+@@ -7170,6 +7170,7 @@ int stmmac_reinit_queues(struct net_device *dev, u32 rx_cnt, u32 tx_cnt)
+ {
+ 	struct stmmac_priv *priv = netdev_priv(dev);
+ 	int ret = 0, i;
++	int max_speed;
+ 
+ 	if (netif_running(dev))
+ 		stmmac_release(dev);
+@@ -7185,6 +7186,10 @@ int stmmac_reinit_queues(struct net_device *dev, u32 rx_cnt, u32 tx_cnt)
+ 
+ 	stmmac_mac_phylink_get_caps(priv);
+ 
++	max_speed = priv->plat->max_speed;
++	if (max_speed)
++		phylink_limit_mac_speed(&priv->phylink_config, max_speed);
++
+ 	stmmac_napi_add(dev);
+ 
+ 	if (netif_running(dev))
+-- 
+2.43.0
+
diff --git a/queue-6.6/netfilter-br_netfilter-skip-conntrack-input-hook-for.patch b/queue-6.6/netfilter-br_netfilter-skip-conntrack-input-hook-for.patch
new file mode 100644
index 0000000000..2a024d6b0e
--- /dev/null
+++ b/queue-6.6/netfilter-br_netfilter-skip-conntrack-input-hook-for.patch
@@ -0,0 +1,220 @@
+From a34bdc61d65f2f276801fa8be4de65262cd76cf5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 9 Apr 2024 11:24:59 +0200
+Subject: netfilter: br_netfilter: skip conntrack input hook for promisc
+ packets
+
+From: Pablo Neira Ayuso <pablo@netfilter.org>
+
+[ Upstream commit 751de2012eafa4d46d8081056761fa0e9cc8a178 ]
+
+For historical reasons, when bridge device is in promisc mode, packets
+that are directed to the taps follow bridge input hook path. This patch
+adds a workaround to reset conntrack for these packets.
+
+Jianbo Liu reports warning splats in their test infrastructure where
+cloned packets reach the br_netfilter input hook to confirm the
+conntrack object.
+
+Scratch one bit from BR_INPUT_SKB_CB to annotate that this packet has
+reached the input hook because it is passed up to the bridge device to
+reach the taps.
+
+[   57.571874] WARNING: CPU: 1 PID: 0 at net/bridge/br_netfilter_hooks.c:616 br_nf_local_in+0x157/0x180 [br_netfilter]
+[   57.572749] Modules linked in: xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_isc si ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5ctl mlx5_core
+[   57.575158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0+ #19
+[   57.575700] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
+[   57.576662] RIP: 0010:br_nf_local_in+0x157/0x180 [br_netfilter]
+[   57.577195] Code: fe ff ff 41 bd 04 00 00 00 be 04 00 00 00 e9 4a ff ff ff be 04 00 00 00 48 89 ef e8 f3 a9 3c e1 66 83 ad b4 00 00 00 04 eb 91 <0f> 0b e9 f1 fe ff ff 0f 0b e9 df fe ff ff 48 89 df e8 b3 53 47 e1
+[   57.578722] RSP: 0018:ffff88885f845a08 EFLAGS: 00010202
+[   57.579207] RAX: 0000000000000002 RBX: ffff88812dfe8000 RCX: 0000000000000000
+[   57.579830] RDX: ffff88885f845a60 RSI: ffff8881022dc300 RDI: 0000000000000000
+[   57.580454] RBP: ffff88885f845a60 R08: 0000000000000001 R09: 0000000000000003
+[   57.581076] R10: 00000000ffff1300 R11: 0000000000000002 R12: 0000000000000000
+[   57.581695] R13: ffff8881047ffe00 R14: ffff888108dbee00 R15: ffff88814519b800
+[   57.582313] FS:  0000000000000000(0000) GS:ffff88885f840000(0000) knlGS:0000000000000000
+[   57.583040] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[   57.583564] CR2: 000000c4206aa000 CR3: 0000000103847001 CR4: 0000000000370eb0
+[   57.584194] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
+0000000000000000
+[   57.584820] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
+0000000000000400
+[   57.585440] Call Trace:
+[   57.585721]  <IRQ>
+[   57.585976]  ? __warn+0x7d/0x130
+[   57.586323]  ? br_nf_local_in+0x157/0x180 [br_netfilter]
+[   57.586811]  ? report_bug+0xf1/0x1c0
+[   57.587177]  ? handle_bug+0x3f/0x70
+[   57.587539]  ? exc_invalid_op+0x13/0x60
+[   57.587929]  ? asm_exc_invalid_op+0x16/0x20
+[   57.588336]  ? br_nf_local_in+0x157/0x180 [br_netfilter]
+[   57.588825]  nf_hook_slow+0x3d/0xd0
+[   57.589188]  ? br_handle_vlan+0x4b/0x110
+[   57.589579]  br_pass_frame_up+0xfc/0x150
+[   57.589970]  ? br_port_flags_change+0x40/0x40
+[   57.590396]  br_handle_frame_finish+0x346/0x5e0
+[   57.590837]  ? ipt_do_table+0x32e/0x430
+[   57.591221]  ? br_handle_local_finish+0x20/0x20
+[   57.591656]  br_nf_hook_thresh+0x4b/0xf0 [br_netfilter]
+[   57.592286]  ? br_handle_local_finish+0x20/0x20
+[   57.592802]  br_nf_pre_routing_finish+0x178/0x480 [br_netfilter]
+[   57.593348]  ? br_handle_local_finish+0x20/0x20
+[   57.593782]  ? nf_nat_ipv4_pre_routing+0x25/0x60 [nf_nat]
+[   57.594279]  br_nf_pre_routing+0x24c/0x550 [br_netfilter]
+[   57.594780]  ? br_nf_hook_thresh+0xf0/0xf0 [br_netfilter]
+[   57.595280]  br_handle_frame+0x1f3/0x3d0
+[   57.595676]  ? br_handle_local_finish+0x20/0x20
+[   57.596118]  ? br_handle_frame_finish+0x5e0/0x5e0
+[   57.596566]  __netif_receive_skb_core+0x25b/0xfc0
+[   57.597017]  ? __napi_build_skb+0x37/0x40
+[   57.597418]  __netif_receive_skb_list_core+0xfb/0x220
+
+Fixes: 62e7151ae3eb ("netfilter: bridge: confirm multicast packets before passing them up the stack")
+Reported-by: Jianbo Liu <jianbol@nvidia.com>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bridge/br_input.c                      | 15 +++++++++++----
+ net/bridge/br_netfilter_hooks.c            |  6 ++++++
+ net/bridge/br_private.h                    |  1 +
+ net/bridge/netfilter/nf_conntrack_bridge.c | 14 ++++++++++----
+ 4 files changed, 28 insertions(+), 8 deletions(-)
+
+diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
+index c729528b5e85f..e09000e38d071 100644
+--- a/net/bridge/br_input.c
++++ b/net/bridge/br_input.c
+@@ -30,7 +30,7 @@ br_netif_receive_skb(struct net *net, struct sock *sk, struct sk_buff *skb)
+ 	return netif_receive_skb(skb);
+ }
+ 
+-static int br_pass_frame_up(struct sk_buff *skb)
++static int br_pass_frame_up(struct sk_buff *skb, bool promisc)
+ {
+ 	struct net_device *indev, *brdev = BR_INPUT_SKB_CB(skb)->brdev;
+ 	struct net_bridge *br = netdev_priv(brdev);
+@@ -65,6 +65,8 @@ static int br_pass_frame_up(struct sk_buff *skb)
+ 	br_multicast_count(br, NULL, skb, br_multicast_igmp_type(skb),
+ 			   BR_MCAST_DIR_TX);
+ 
++	BR_INPUT_SKB_CB(skb)->promisc = promisc;
++
+ 	return NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN,
+ 		       dev_net(indev), NULL, skb, indev, NULL,
+ 		       br_netif_receive_skb);
+@@ -82,6 +84,7 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
+ 	struct net_bridge_mcast *brmctx;
+ 	struct net_bridge_vlan *vlan;
+ 	struct net_bridge *br;
++	bool promisc;
+ 	u16 vid = 0;
+ 	u8 state;
+ 
+@@ -137,7 +140,9 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
+ 	if (p->flags & BR_LEARNING)
+ 		br_fdb_update(br, p, eth_hdr(skb)->h_source, vid, 0);
+ 
+-	local_rcv = !!(br->dev->flags & IFF_PROMISC);
++	promisc = !!(br->dev->flags & IFF_PROMISC);
++	local_rcv = promisc;
++
+ 	if (is_multicast_ether_addr(eth_hdr(skb)->h_dest)) {
+ 		/* by definition the broadcast is also a multicast address */
+ 		if (is_broadcast_ether_addr(eth_hdr(skb)->h_dest)) {
+@@ -200,7 +205,7 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
+ 		unsigned long now = jiffies;
+ 
+ 		if (test_bit(BR_FDB_LOCAL, &dst->flags))
+-			return br_pass_frame_up(skb);
++			return br_pass_frame_up(skb, false);
+ 
+ 		if (now != dst->used)
+ 			dst->used = now;
+@@ -213,7 +218,7 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
+ 	}
+ 
+ 	if (local_rcv)
+-		return br_pass_frame_up(skb);
++		return br_pass_frame_up(skb, promisc);
+ 
+ out:
+ 	return 0;
+@@ -386,6 +391,8 @@ static rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
+ 				goto forward;
+ 		}
+ 
++		BR_INPUT_SKB_CB(skb)->promisc = false;
++
+ 		/* The else clause should be hit when nf_hook():
+ 		 *   - returns < 0 (drop/error)
+ 		 *   - returns = 0 (stolen/nf_queue)
+diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
+index 6ef67030b4db3..d848c84ed030d 100644
+--- a/net/bridge/br_netfilter_hooks.c
++++ b/net/bridge/br_netfilter_hooks.c
+@@ -600,11 +600,17 @@ static unsigned int br_nf_local_in(void *priv,
+ 				   struct sk_buff *skb,
+ 				   const struct nf_hook_state *state)
+ {
++	bool promisc = BR_INPUT_SKB_CB(skb)->promisc;
+ 	struct nf_conntrack *nfct = skb_nfct(skb);
+ 	const struct nf_ct_hook *ct_hook;
+ 	struct nf_conn *ct;
+ 	int ret;
+ 
++	if (promisc) {
++		nf_reset_ct(skb);
++		return NF_ACCEPT;
++	}
++
+ 	if (!nfct || skb->pkt_type == PACKET_HOST)
+ 		return NF_ACCEPT;
+ 
+diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
+index 82e63908dce8a..e4f1a08322da9 100644
+--- a/net/bridge/br_private.h
++++ b/net/bridge/br_private.h
+@@ -583,6 +583,7 @@ struct br_input_skb_cb {
+ #endif
+ 	u8 proxyarp_replied:1;
+ 	u8 src_port_isolated:1;
++	u8 promisc:1;
+ #ifdef CONFIG_BRIDGE_VLAN_FILTERING
+ 	u8 vlan_filtered:1;
+ #endif
+diff --git a/net/bridge/netfilter/nf_conntrack_bridge.c b/net/bridge/netfilter/nf_conntrack_bridge.c
+index d32fce70d797d..6ef04f9fe481b 100644
+--- a/net/bridge/netfilter/nf_conntrack_bridge.c
++++ b/net/bridge/netfilter/nf_conntrack_bridge.c
+@@ -294,18 +294,24 @@ static unsigned int nf_ct_bridge_pre(void *priv, struct sk_buff *skb,
+ static unsigned int nf_ct_bridge_in(void *priv, struct sk_buff *skb,
+ 				    const struct nf_hook_state *state)
+ {
+-	enum ip_conntrack_info ctinfo;
++	bool promisc = BR_INPUT_SKB_CB(skb)->promisc;
++	struct nf_conntrack *nfct = skb_nfct(skb);
+ 	struct nf_conn *ct;
+ 
+-	if (skb->pkt_type == PACKET_HOST)
++	if (promisc) {
++		nf_reset_ct(skb);
++		return NF_ACCEPT;
++	}
++
++	if (!nfct || skb->pkt_type == PACKET_HOST)
+ 		return NF_ACCEPT;
+ 
+ 	/* nf_conntrack_confirm() cannot handle concurrent clones,
+ 	 * this happens for broad/multicast frames with e.g. macvlan on top
+ 	 * of the bridge device.
+ 	 */
+-	ct = nf_ct_get(skb, &ctinfo);
+-	if (!ct || nf_ct_is_confirmed(ct) || nf_ct_is_template(ct))
++	ct = container_of(nfct, struct nf_conn, ct_general);
++	if (nf_ct_is_confirmed(ct) || nf_ct_is_template(ct))
+ 		return NF_ACCEPT;
+ 
+ 	/* let inet prerouting call conntrack again */
+-- 
+2.43.0
+
diff --git a/queue-6.6/netfilter-flowtable-incorrect-pppoe-tuple.patch b/queue-6.6/netfilter-flowtable-incorrect-pppoe-tuple.patch
new file mode 100644
index 0000000000..33e9090f44
--- /dev/null
+++ b/queue-6.6/netfilter-flowtable-incorrect-pppoe-tuple.patch
@@ -0,0 +1,37 @@
+From 6da713842d216d85ee1ea4d9c4b80324c6bf8175 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 11 Apr 2024 00:09:00 +0200
+Subject: netfilter: flowtable: incorrect pppoe tuple
+
+From: Pablo Neira Ayuso <pablo@netfilter.org>
+
+[ Upstream commit 6db5dc7b351b9569940cd1cf445e237c42cd6d27 ]
+
+pppoe traffic reaching ingress path does not match the flowtable entry
+because the pppoe header is expected to be at the network header offset.
+This bug causes a mismatch in the flow table lookup, so pppoe packets
+enter the classical forwarding path.
+
+Fixes: 72efd585f714 ("netfilter: flowtable: add pppoe support")
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nf_flow_table_ip.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
+index 9e9e105052dae..5383bed3d3e00 100644
+--- a/net/netfilter/nf_flow_table_ip.c
++++ b/net/netfilter/nf_flow_table_ip.c
+@@ -157,7 +157,7 @@ static void nf_flow_tuple_encap(struct sk_buff *skb,
+ 		tuple->encap[i].proto = skb->protocol;
+ 		break;
+ 	case htons(ETH_P_PPP_SES):
+-		phdr = (struct pppoe_hdr *)skb_mac_header(skb);
++		phdr = (struct pppoe_hdr *)skb_network_header(skb);
+ 		tuple->encap[i].id = ntohs(phdr->sid);
+ 		tuple->encap[i].proto = skb->protocol;
+ 		break;
+-- 
+2.43.0
+
diff --git a/queue-6.6/netfilter-flowtable-validate-pppoe-header.patch b/queue-6.6/netfilter-flowtable-validate-pppoe-header.patch
new file mode 100644
index 0000000000..48d428f241
--- /dev/null
+++ b/queue-6.6/netfilter-flowtable-validate-pppoe-header.patch
@@ -0,0 +1,106 @@
+From 2813d124b0640b0ed59f6f75dd7f03c4c62c8b80 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 9 Apr 2024 13:47:33 +0200
+Subject: netfilter: flowtable: validate pppoe header
+
+From: Pablo Neira Ayuso <pablo@netfilter.org>
+
+[ Upstream commit 87b3593bed1868b2d9fe096c01bcdf0ea86cbebf ]
+
+Ensure there is sufficient room to access the protocol field of the
+PPPoe header. Validate it once before the flowtable lookup, then use a
+helper function to access protocol field.
+
+Reported-by: syzbot+b6f07e1c07ef40199081@syzkaller.appspotmail.com
+Fixes: 72efd585f714 ("netfilter: flowtable: add pppoe support")
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/netfilter/nf_flow_table.h | 12 +++++++++++-
+ net/netfilter/nf_flow_table_inet.c    |  3 ++-
+ net/netfilter/nf_flow_table_ip.c      |  8 +++++---
+ 3 files changed, 18 insertions(+), 5 deletions(-)
+
+diff --git a/include/net/netfilter/nf_flow_table.h b/include/net/netfilter/nf_flow_table.h
+index 4a767b3d20b9d..df7775afb92b9 100644
+--- a/include/net/netfilter/nf_flow_table.h
++++ b/include/net/netfilter/nf_flow_table.h
+@@ -335,7 +335,7 @@ int nf_flow_rule_route_ipv6(struct net *net, struct flow_offload *flow,
+ int nf_flow_table_offload_init(void);
+ void nf_flow_table_offload_exit(void);
+ 
+-static inline __be16 nf_flow_pppoe_proto(const struct sk_buff *skb)
++static inline __be16 __nf_flow_pppoe_proto(const struct sk_buff *skb)
+ {
+ 	__be16 proto;
+ 
+@@ -351,6 +351,16 @@ static inline __be16 nf_flow_pppoe_proto(const struct sk_buff *skb)
+ 	return 0;
+ }
+ 
++static inline bool nf_flow_pppoe_proto(struct sk_buff *skb, __be16 *inner_proto)
++{
++	if (!pskb_may_pull(skb, PPPOE_SES_HLEN))
++		return false;
++
++	*inner_proto = __nf_flow_pppoe_proto(skb);
++
++	return true;
++}
++
+ #define NF_FLOW_TABLE_STAT_INC(net, count) __this_cpu_inc((net)->ft.stat->count)
+ #define NF_FLOW_TABLE_STAT_DEC(net, count) __this_cpu_dec((net)->ft.stat->count)
+ #define NF_FLOW_TABLE_STAT_INC_ATOMIC(net, count)	\
+diff --git a/net/netfilter/nf_flow_table_inet.c b/net/netfilter/nf_flow_table_inet.c
+index 9505f9d188ff2..6eef15648b7b0 100644
+--- a/net/netfilter/nf_flow_table_inet.c
++++ b/net/netfilter/nf_flow_table_inet.c
+@@ -21,7 +21,8 @@ nf_flow_offload_inet_hook(void *priv, struct sk_buff *skb,
+ 		proto = veth->h_vlan_encapsulated_proto;
+ 		break;
+ 	case htons(ETH_P_PPP_SES):
+-		proto = nf_flow_pppoe_proto(skb);
++		if (!nf_flow_pppoe_proto(skb, &proto))
++			return NF_ACCEPT;
+ 		break;
+ 	default:
+ 		proto = skb->protocol;
+diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
+index e45fade764096..9e9e105052dae 100644
+--- a/net/netfilter/nf_flow_table_ip.c
++++ b/net/netfilter/nf_flow_table_ip.c
+@@ -273,10 +273,11 @@ static unsigned int nf_flow_xmit_xfrm(struct sk_buff *skb,
+ 	return NF_STOLEN;
+ }
+ 
+-static bool nf_flow_skb_encap_protocol(const struct sk_buff *skb, __be16 proto,
++static bool nf_flow_skb_encap_protocol(struct sk_buff *skb, __be16 proto,
+ 				       u32 *offset)
+ {
+ 	struct vlan_ethhdr *veth;
++	__be16 inner_proto;
+ 
+ 	switch (skb->protocol) {
+ 	case htons(ETH_P_8021Q):
+@@ -287,7 +288,8 @@ static bool nf_flow_skb_encap_protocol(const struct sk_buff *skb, __be16 proto,
+ 		}
+ 		break;
+ 	case htons(ETH_P_PPP_SES):
+-		if (nf_flow_pppoe_proto(skb) == proto) {
++		if (nf_flow_pppoe_proto(skb, &inner_proto) &&
++		    inner_proto == proto) {
+ 			*offset += PPPOE_SES_HLEN;
+ 			return true;
+ 		}
+@@ -316,7 +318,7 @@ static void nf_flow_encap_pop(struct sk_buff *skb,
+ 			skb_reset_network_header(skb);
+ 			break;
+ 		case htons(ETH_P_PPP_SES):
+-			skb->protocol = nf_flow_pppoe_proto(skb);
++			skb->protocol = __nf_flow_pppoe_proto(skb);
+ 			skb_pull(skb, PPPOE_SES_HLEN);
+ 			skb_reset_network_header(skb);
+ 			break;
+-- 
+2.43.0
+
diff --git a/queue-6.6/netfilter-nf_tables-fix-potential-data-race-in-__nft.patch b/queue-6.6/netfilter-nf_tables-fix-potential-data-race-in-__nft.patch
new file mode 100644
index 0000000000..81c2c97f94
--- /dev/null
+++ b/queue-6.6/netfilter-nf_tables-fix-potential-data-race-in-__nft.patch
@@ -0,0 +1,58 @@
+From fea59e8cbdda234b6675220c1515c7576a7124ae Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 7 Apr 2024 14:56:04 +0800
+Subject: netfilter: nf_tables: Fix potential data-race in
+ __nft_expr_type_get()
+
+From: Ziyang Xuan <william.xuanziyang@huawei.com>
+
+[ Upstream commit f969eb84ce482331a991079ab7a5c4dc3b7f89bf ]
+
+nft_unregister_expr() can concurrent with __nft_expr_type_get(),
+and there is not any protection when iterate over nf_tables_expressions
+list in __nft_expr_type_get(). Therefore, there is potential data-race
+of nf_tables_expressions list entry.
+
+Use list_for_each_entry_rcu() to iterate over nf_tables_expressions
+list in __nft_expr_type_get(), and use rcu_read_lock() in the caller
+nft_expr_type_get() to protect the entire type query process.
+
+Fixes: ef1f7df9170d ("netfilter: nf_tables: expression ops overloading")
+Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nf_tables_api.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
+index 2a4649df8f086..fe6ee16e2dbf4 100644
+--- a/net/netfilter/nf_tables_api.c
++++ b/net/netfilter/nf_tables_api.c
+@@ -3047,7 +3047,7 @@ static const struct nft_expr_type *__nft_expr_type_get(u8 family,
+ {
+ 	const struct nft_expr_type *type, *candidate = NULL;
+ 
+-	list_for_each_entry(type, &nf_tables_expressions, list) {
++	list_for_each_entry_rcu(type, &nf_tables_expressions, list) {
+ 		if (!nla_strcmp(nla, type->name)) {
+ 			if (!type->family && !candidate)
+ 				candidate = type;
+@@ -3079,9 +3079,13 @@ static const struct nft_expr_type *nft_expr_type_get(struct net *net,
+ 	if (nla == NULL)
+ 		return ERR_PTR(-EINVAL);
+ 
++	rcu_read_lock();
+ 	type = __nft_expr_type_get(family, nla);
+-	if (type != NULL && try_module_get(type->owner))
++	if (type != NULL && try_module_get(type->owner)) {
++		rcu_read_unlock();
+ 		return type;
++	}
++	rcu_read_unlock();
+ 
+ 	lockdep_nfnl_nft_mutex_not_held();
+ #ifdef CONFIG_MODULES
+-- 
+2.43.0
+
diff --git a/queue-6.6/netfilter-nf_tables-fix-potential-data-race-in-__nft.patch-8953 b/queue-6.6/netfilter-nf_tables-fix-potential-data-race-in-__nft.patch-8953
new file mode 100644
index 0000000000..de521ad89b
--- /dev/null
+++ b/queue-6.6/netfilter-nf_tables-fix-potential-data-race-in-__nft.patch-8953
@@ -0,0 +1,57 @@
+From ed55b74c178253e9d749bb4393d4d96bd011c6b0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 7 Apr 2024 14:56:05 +0800
+Subject: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
+
+From: Ziyang Xuan <william.xuanziyang@huawei.com>
+
+[ Upstream commit d78d867dcea69c328db30df665be5be7d0148484 ]
+
+nft_unregister_obj() can concurrent with __nft_obj_type_get(),
+and there is not any protection when iterate over nf_tables_objects
+list in __nft_obj_type_get(). Therefore, there is potential data-race
+of nf_tables_objects list entry.
+
+Use list_for_each_entry_rcu() to iterate over nf_tables_objects
+list in __nft_obj_type_get(), and use rcu_read_lock() in the caller
+nft_obj_type_get() to protect the entire type query process.
+
+Fixes: e50092404c1b ("netfilter: nf_tables: add stateful objects")
+Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nf_tables_api.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
+index fe6ee16e2dbf4..387eee416b0bf 100644
+--- a/net/netfilter/nf_tables_api.c
++++ b/net/netfilter/nf_tables_api.c
+@@ -7468,7 +7468,7 @@ static const struct nft_object_type *__nft_obj_type_get(u32 objtype, u8 family)
+ {
+ 	const struct nft_object_type *type;
+ 
+-	list_for_each_entry(type, &nf_tables_objects, list) {
++	list_for_each_entry_rcu(type, &nf_tables_objects, list) {
+ 		if (type->family != NFPROTO_UNSPEC &&
+ 		    type->family != family)
+ 			continue;
+@@ -7484,9 +7484,13 @@ nft_obj_type_get(struct net *net, u32 objtype, u8 family)
+ {
+ 	const struct nft_object_type *type;
+ 
++	rcu_read_lock();
+ 	type = __nft_obj_type_get(objtype, family);
+-	if (type != NULL && try_module_get(type->owner))
++	if (type != NULL && try_module_get(type->owner)) {
++		rcu_read_unlock();
+ 		return type;
++	}
++	rcu_read_unlock();
+ 
+ 	lockdep_nfnl_nft_mutex_not_held();
+ #ifdef CONFIG_MODULES
+-- 
+2.43.0
+
diff --git a/queue-6.6/netfilter-nft_set_pipapo-do-not-free-live-element.patch b/queue-6.6/netfilter-nft_set_pipapo-do-not-free-live-element.patch
new file mode 100644
index 0000000000..e785f87668
--- /dev/null
+++ b/queue-6.6/netfilter-nft_set_pipapo-do-not-free-live-element.patch
@@ -0,0 +1,105 @@
+From 4fbef8f9f446713061f2c2c1dd1c30f5dd00e4c2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 10 Apr 2024 21:05:13 +0200
+Subject: netfilter: nft_set_pipapo: do not free live element
+
+From: Florian Westphal <fw@strlen.de>
+
+[ Upstream commit 3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc ]
+
+Pablo reports a crash with large batches of elements with a
+back-to-back add/remove pattern.  Quoting Pablo:
+
+  add_elem("00000000") timeout 100 ms
+  ...
+  add_elem("0000000X") timeout 100 ms
+  del_elem("0000000X") <---------------- delete one that was just added
+  ...
+  add_elem("00005000") timeout 100 ms
+
+  1) nft_pipapo_remove() removes element 0000000X
+  Then, KASAN shows a splat.
+
+Looking at the remove function there is a chance that we will drop a
+rule that maps to a non-deactivated element.
+
+Removal happens in two steps, first we do a lookup for key k and return the
+to-be-removed element and mark it as inactive in the next generation.
+Then, in a second step, the element gets removed from the set/map.
+
+The _remove function does not work correctly if we have more than one
+element that share the same key.
+
+This can happen if we insert an element into a set when the set already
+holds an element with same key, but the element mapping to the existing
+key has timed out or is not active in the next generation.
+
+In such case its possible that removal will unmap the wrong element.
+If this happens, we will leak the non-deactivated element, it becomes
+unreachable.
+
+The element that got deactivated (and will be freed later) will
+remain reachable in the set data structure, this can result in
+a crash when such an element is retrieved during lookup (stale
+pointer).
+
+Add a check that the fully matching key does in fact map to the element
+that we have marked as inactive in the deactivation step.
+If not, we need to continue searching.
+
+Add a bug/warn trap at the end of the function as well, the remove
+function must not ever be called with an invisible/unreachable/non-existent
+element.
+
+v2: avoid uneeded temporary variable (Stefano)
+
+Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges")
+Reported-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
+Signed-off-by: Florian Westphal <fw@strlen.de>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nft_set_pipapo.c | 14 +++++++++-----
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+diff --git a/net/netfilter/nft_set_pipapo.c b/net/netfilter/nft_set_pipapo.c
+index a890aa0abad58..69b02a3f1ff05 100644
+--- a/net/netfilter/nft_set_pipapo.c
++++ b/net/netfilter/nft_set_pipapo.c
+@@ -1993,6 +1993,8 @@ static void nft_pipapo_remove(const struct net *net, const struct nft_set *set,
+ 		rules_fx = rules_f0;
+ 
+ 		nft_pipapo_for_each_field(f, i, m) {
++			bool last = i == m->field_count - 1;
++
+ 			if (!pipapo_match_field(f, start, rules_fx,
+ 						match_start, match_end))
+ 				break;
+@@ -2005,16 +2007,18 @@ static void nft_pipapo_remove(const struct net *net, const struct nft_set *set,
+ 
+ 			match_start += NFT_PIPAPO_GROUPS_PADDED_SIZE(f);
+ 			match_end += NFT_PIPAPO_GROUPS_PADDED_SIZE(f);
+-		}
+ 
+-		if (i == m->field_count) {
+-			priv->dirty = true;
+-			pipapo_drop(m, rulemap);
+-			return;
++			if (last && f->mt[rulemap[i].to].e == e) {
++				priv->dirty = true;
++				pipapo_drop(m, rulemap);
++				return;
++			}
+ 		}
+ 
+ 		first_rule += rules_f0;
+ 	}
++
++	WARN_ON_ONCE(1); /* elem_priv not found */
+ }
+ 
+ /**
+-- 
+2.43.0
+
diff --git a/queue-6.6/octeontx2-pf-fix-flow_dis_is_fragment-implementation.patch b/queue-6.6/octeontx2-pf-fix-flow_dis_is_fragment-implementation.patch
new file mode 100644
index 0000000000..f1cbc452b9
--- /dev/null
+++ b/queue-6.6/octeontx2-pf-fix-flow_dis_is_fragment-implementation.patch
@@ -0,0 +1,62 @@
+From 502f075380ca7abfd0ffa7310ebf7d4f629065d0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 12 Apr 2024 12:02:56 +0000
+Subject: octeontx2-pf: fix FLOW_DIS_IS_FRAGMENT implementation
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Asbjørn Sloth Tønnesen <ast@fiberby.net>
+
+[ Upstream commit 75ce9506ee3dc66648a7d74ab3b0acfa364d6d43 ]
+
+Upon reviewing the flower control flags handling in
+this driver, I notice that the key wasn't being used,
+only the mask.
+
+Ie. `tc flower ... ip_flags nofrag` was hardware
+offloaded as `... ip_flags frag`.
+
+Only compile tested, no access to HW.
+
+Fixes: c672e3727989 ("octeontx2-pf: Add support to filter packet based on IP fragment")
+Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
+Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
+index 423ce54eaea69..46bdbee9d38ad 100644
+--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
++++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
+@@ -588,6 +588,7 @@ static int otx2_tc_prepare_flow(struct otx2_nic *nic, struct otx2_tc_flow *node,
+ 
+ 	if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_CONTROL)) {
+ 		struct flow_match_control match;
++		u32 val;
+ 
+ 		flow_rule_match_control(rule, &match);
+ 		if (match.mask->flags & FLOW_DIS_FIRST_FRAG) {
+@@ -596,12 +597,14 @@ static int otx2_tc_prepare_flow(struct otx2_nic *nic, struct otx2_tc_flow *node,
+ 		}
+ 
+ 		if (match.mask->flags & FLOW_DIS_IS_FRAGMENT) {
++			val = match.key->flags & FLOW_DIS_IS_FRAGMENT;
+ 			if (ntohs(flow_spec->etype) == ETH_P_IP) {
+-				flow_spec->ip_flag = IPV4_FLAG_MORE;
++				flow_spec->ip_flag = val ? IPV4_FLAG_MORE : 0;
+ 				flow_mask->ip_flag = IPV4_FLAG_MORE;
+ 				req->features |= BIT_ULL(NPC_IPFRAG_IPV4);
+ 			} else if (ntohs(flow_spec->etype) == ETH_P_IPV6) {
+-				flow_spec->next_header = IPPROTO_FRAGMENT;
++				flow_spec->next_header = val ?
++							 IPPROTO_FRAGMENT : 0;
+ 				flow_mask->next_header = 0xff;
+ 				req->features |= BIT_ULL(NPC_IPFRAG_IPV6);
+ 			} else {
+-- 
+2.43.0
+
diff --git a/queue-6.6/s390-ism-properly-fix-receive-message-buffer-allocat.patch b/queue-6.6/s390-ism-properly-fix-receive-message-buffer-allocat.patch
new file mode 100644
index 0000000000..7eef7a5c9b
--- /dev/null
+++ b/queue-6.6/s390-ism-properly-fix-receive-message-buffer-allocat.patch
@@ -0,0 +1,102 @@
+From e9829b6a7c356510badb7121e7b873189886d55c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 15 Apr 2024 15:15:07 +0200
+Subject: s390/ism: Properly fix receive message buffer allocation
+
+From: Gerd Bayer <gbayer@linux.ibm.com>
+
+[ Upstream commit 83781384a96b95e2b6403d3c8a002b2c89031770 ]
+
+Since [1], dma_alloc_coherent() does not accept requests for GFP_COMP
+anymore, even on archs that may be able to fulfill this. Functionality that
+relied on the receive buffer being a compound page broke at that point:
+The SMC-D protocol, that utilizes the ism device driver, passes receive
+buffers to the splice processor in a struct splice_pipe_desc with a
+single entry list of struct pages. As the buffer is no longer a compound
+page, the splice processor now rejects requests to handle more than a
+page worth of data.
+
+Replace dma_alloc_coherent() and allocate a buffer with folio_alloc and
+create a DMA map for it with dma_map_page(). Since only receive buffers
+on ISM devices use DMA, qualify the mapping as FROM_DEVICE.
+Since ISM devices are available on arch s390, only, and on that arch all
+DMA is coherent, there is no need to introduce and export some kind of
+dma_sync_to_cpu() method to be called by the SMC-D protocol layer.
+
+Analogously, replace dma_free_coherent by a two step dma_unmap_page,
+then folio_put to free the receive buffer.
+
+[1] https://lore.kernel.org/all/20221113163535.884299-1-hch@lst.de/
+
+Fixes: c08004eede4b ("s390/ism: don't pass bogus GFP_ flags to dma_alloc_coherent")
+Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/s390/net/ism_drv.c | 37 ++++++++++++++++++++++++++++---------
+ 1 file changed, 28 insertions(+), 9 deletions(-)
+
+diff --git a/drivers/s390/net/ism_drv.c b/drivers/s390/net/ism_drv.c
+index 81aabbfbbe2ca..622a61f8a3b84 100644
+--- a/drivers/s390/net/ism_drv.c
++++ b/drivers/s390/net/ism_drv.c
+@@ -291,13 +291,16 @@ static int ism_read_local_gid(struct ism_dev *ism)
+ static void ism_free_dmb(struct ism_dev *ism, struct ism_dmb *dmb)
+ {
+ 	clear_bit(dmb->sba_idx, ism->sba_bitmap);
+-	dma_free_coherent(&ism->pdev->dev, dmb->dmb_len,
+-			  dmb->cpu_addr, dmb->dma_addr);
++	dma_unmap_page(&ism->pdev->dev, dmb->dma_addr, dmb->dmb_len,
++		       DMA_FROM_DEVICE);
++	folio_put(virt_to_folio(dmb->cpu_addr));
+ }
+ 
+ static int ism_alloc_dmb(struct ism_dev *ism, struct ism_dmb *dmb)
+ {
++	struct folio *folio;
+ 	unsigned long bit;
++	int rc;
+ 
+ 	if (PAGE_ALIGN(dmb->dmb_len) > dma_get_max_seg_size(&ism->pdev->dev))
+ 		return -EINVAL;
+@@ -314,14 +317,30 @@ static int ism_alloc_dmb(struct ism_dev *ism, struct ism_dmb *dmb)
+ 	    test_and_set_bit(dmb->sba_idx, ism->sba_bitmap))
+ 		return -EINVAL;
+ 
+-	dmb->cpu_addr = dma_alloc_coherent(&ism->pdev->dev, dmb->dmb_len,
+-					   &dmb->dma_addr,
+-					   GFP_KERNEL | __GFP_NOWARN |
+-					   __GFP_NOMEMALLOC | __GFP_NORETRY);
+-	if (!dmb->cpu_addr)
+-		clear_bit(dmb->sba_idx, ism->sba_bitmap);
++	folio = folio_alloc(GFP_KERNEL | __GFP_NOWARN | __GFP_NOMEMALLOC |
++			    __GFP_NORETRY, get_order(dmb->dmb_len));
+ 
+-	return dmb->cpu_addr ? 0 : -ENOMEM;
++	if (!folio) {
++		rc = -ENOMEM;
++		goto out_bit;
++	}
++
++	dmb->cpu_addr = folio_address(folio);
++	dmb->dma_addr = dma_map_page(&ism->pdev->dev,
++				     virt_to_page(dmb->cpu_addr), 0,
++				     dmb->dmb_len, DMA_FROM_DEVICE);
++	if (dma_mapping_error(&ism->pdev->dev, dmb->dma_addr)) {
++		rc = -ENOMEM;
++		goto out_free;
++	}
++
++	return 0;
++
++out_free:
++	kfree(dmb->cpu_addr);
++out_bit:
++	clear_bit(dmb->sba_idx, ism->sba_bitmap);
++	return rc;
+ }
+ 
+ int ism_register_dmb(struct ism_dev *ism, struct ism_dmb *dmb,
+-- 
+2.43.0
+
diff --git a/queue-6.6/scsi-ufs-qcom-add-missing-interconnect-bandwidth-val.patch b/queue-6.6/scsi-ufs-qcom-add-missing-interconnect-bandwidth-val.patch
new file mode 100644
index 0000000000..16dbfde8d7
--- /dev/null
+++ b/queue-6.6/scsi-ufs-qcom-add-missing-interconnect-bandwidth-val.patch
@@ -0,0 +1,72 @@
+From dc73f230816fc3a627d3f77606f4dc8009c9ceed Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 3 Apr 2024 18:50:03 +0530
+Subject: scsi: ufs: qcom: Add missing interconnect bandwidth values for Gear 5
+
+From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+[ Upstream commit 8db8f6ce556af60ca9a9fd5e826d369ded70fcc7 ]
+
+These entries are necessary to scale the interconnect bandwidth while
+operating in Gear 5.
+
+Cc: Amit Pundir <amit.pundir@linaro.org>
+Fixes: 03ce80a1bb86 ("scsi: ufs: qcom: Add support for scaling interconnects")
+Tested-by: Amit Pundir <amit.pundir@linaro.org>
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Link: https://lore.kernel.org/r/20240403-ufs-icc-fix-v2-1-958412a5eb45@linaro.org
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ufs/host/ufs-qcom.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
+index 0cbe14aca8774..797219db026bc 100644
+--- a/drivers/ufs/host/ufs-qcom.c
++++ b/drivers/ufs/host/ufs-qcom.c
+@@ -47,7 +47,7 @@ enum {
+ 	TSTBUS_MAX,
+ };
+ 
+-#define QCOM_UFS_MAX_GEAR 4
++#define QCOM_UFS_MAX_GEAR 5
+ #define QCOM_UFS_MAX_LANE 2
+ 
+ enum {
+@@ -67,26 +67,32 @@ static const struct __ufs_qcom_bw_table {
+ 	[MODE_PWM][UFS_PWM_G2][UFS_LANE_1] = { 1844,		1000 },
+ 	[MODE_PWM][UFS_PWM_G3][UFS_LANE_1] = { 3688,		1000 },
+ 	[MODE_PWM][UFS_PWM_G4][UFS_LANE_1] = { 7376,		1000 },
++	[MODE_PWM][UFS_PWM_G5][UFS_LANE_1] = { 14752,		1000 },
+ 	[MODE_PWM][UFS_PWM_G1][UFS_LANE_2] = { 1844,		1000 },
+ 	[MODE_PWM][UFS_PWM_G2][UFS_LANE_2] = { 3688,		1000 },
+ 	[MODE_PWM][UFS_PWM_G3][UFS_LANE_2] = { 7376,		1000 },
+ 	[MODE_PWM][UFS_PWM_G4][UFS_LANE_2] = { 14752,		1000 },
++	[MODE_PWM][UFS_PWM_G5][UFS_LANE_2] = { 29504,		1000 },
+ 	[MODE_HS_RA][UFS_HS_G1][UFS_LANE_1] = { 127796,		1000 },
+ 	[MODE_HS_RA][UFS_HS_G2][UFS_LANE_1] = { 255591,		1000 },
+ 	[MODE_HS_RA][UFS_HS_G3][UFS_LANE_1] = { 1492582,	102400 },
+ 	[MODE_HS_RA][UFS_HS_G4][UFS_LANE_1] = { 2915200,	204800 },
++	[MODE_HS_RA][UFS_HS_G5][UFS_LANE_1] = { 5836800,	409600 },
+ 	[MODE_HS_RA][UFS_HS_G1][UFS_LANE_2] = { 255591,		1000 },
+ 	[MODE_HS_RA][UFS_HS_G2][UFS_LANE_2] = { 511181,		1000 },
+ 	[MODE_HS_RA][UFS_HS_G3][UFS_LANE_2] = { 1492582,	204800 },
+ 	[MODE_HS_RA][UFS_HS_G4][UFS_LANE_2] = { 2915200,	409600 },
++	[MODE_HS_RA][UFS_HS_G5][UFS_LANE_2] = { 5836800,	819200 },
+ 	[MODE_HS_RB][UFS_HS_G1][UFS_LANE_1] = { 149422,		1000 },
+ 	[MODE_HS_RB][UFS_HS_G2][UFS_LANE_1] = { 298189,		1000 },
+ 	[MODE_HS_RB][UFS_HS_G3][UFS_LANE_1] = { 1492582,	102400 },
+ 	[MODE_HS_RB][UFS_HS_G4][UFS_LANE_1] = { 2915200,	204800 },
++	[MODE_HS_RB][UFS_HS_G5][UFS_LANE_1] = { 5836800,	409600 },
+ 	[MODE_HS_RB][UFS_HS_G1][UFS_LANE_2] = { 298189,		1000 },
+ 	[MODE_HS_RB][UFS_HS_G2][UFS_LANE_2] = { 596378,		1000 },
+ 	[MODE_HS_RB][UFS_HS_G3][UFS_LANE_2] = { 1492582,	204800 },
+ 	[MODE_HS_RB][UFS_HS_G4][UFS_LANE_2] = { 2915200,	409600 },
++	[MODE_HS_RB][UFS_HS_G5][UFS_LANE_2] = { 5836800,	819200 },
+ 	[MODE_MAX][0][0]		    = { 7643136,	307200 },
+ };
+ 
+-- 
+2.43.0
+
diff --git a/queue-6.6/series b/queue-6.6/series
index 29e394dd9e..75585c15b2 100644
--- a/queue-6.6/series
+++ b/queue-6.6/series
@@ -29,3 +29,30 @@ scsi-core-fix-handling-of-scmd_fail_if_recovering.patch
 net-usb-ax88179_178a-avoid-writing-the-mac-address-before-first-reading.patch
 arm64-mm-modify-range-based-tlbi-to-decrement-scale.patch
 arm64-tlb-fix-tlbi-range-operand.patch
+scsi-ufs-qcom-add-missing-interconnect-bandwidth-val.patch
+netfilter-nf_tables-fix-potential-data-race-in-__nft.patch
+netfilter-nf_tables-fix-potential-data-race-in-__nft.patch-8953
+netfilter-br_netfilter-skip-conntrack-input-hook-for.patch
+netfilter-nft_set_pipapo-do-not-free-live-element.patch
+netfilter-flowtable-validate-pppoe-header.patch
+netfilter-flowtable-incorrect-pppoe-tuple.patch
+af_unix-call-manage_oob-for-every-skb-in-unix_stream.patch
+af_unix-don-t-peek-oob-data-without-msg_oob.patch
+net-sparx5-flower-fix-fragment-flags-handling.patch
+net-mlx5-lag-restore-buckets-number-to-default-after.patch
+net-mlx5e-prevent-deadlock-while-disabling-arfs.patch
+net-change-maximum-number-of-udp-segments-to-128.patch
+octeontx2-pf-fix-flow_dis_is_fragment-implementation.patch
+net-stmmac-apply-half-duplex-less-constraint-for-dw-.patch
+net-stmmac-fix-max-speed-being-ignored-on-queue-re-i.patch
+net-stmmac-fix-ip-cores-specific-mac-capabilities.patch
+ice-tc-check-src_vsi-in-case-of-traffic-from-vf.patch
+ice-tc-allow-zero-flags-in-parsing-tc-flower.patch
+ice-fix-checking-for-unsupported-keys-on-non-tunnel-.patch
+tun-limit-printing-rate-when-illegal-packet-received.patch
+net-dsa-mt7530-fix-mirroring-frames-received-on-loca.patch
+net-dsa-mt7530-fix-port-mirroring-for-mt7988-soc-swi.patch
+s390-ism-properly-fix-receive-message-buffer-allocat.patch
+gpiolib-swnode-remove-wrong-header-inclusion.patch
+net-ethernet-mtk_eth_soc-fix-wed-wifi-reset.patch
+net-ethernet-ti-am65-cpsw-nuss-cleanup-dma-channels-.patch
diff --git a/queue-6.6/tun-limit-printing-rate-when-illegal-packet-received.patch b/queue-6.6/tun-limit-printing-rate-when-illegal-packet-received.patch
new file mode 100644
index 0000000000..dd65cd05d0
--- /dev/null
+++ b/queue-6.6/tun-limit-printing-rate-when-illegal-packet-received.patch
@@ -0,0 +1,91 @@
+From b86eac371cd027b71e40c7ac9e4b9658a3fd0fc0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 14 Apr 2024 22:02:46 -0400
+Subject: tun: limit printing rate when illegal packet received by tun dev
+
+From: Lei Chen <lei.chen@smartx.com>
+
+[ Upstream commit f8bbc07ac535593139c875ffa19af924b1084540 ]
+
+vhost_worker will call tun call backs to receive packets. If too many
+illegal packets arrives, tun_do_read will keep dumping packet contents.
+When console is enabled, it will costs much more cpu time to dump
+packet and soft lockup will be detected.
+
+net_ratelimit mechanism can be used to limit the dumping rate.
+
+PID: 33036    TASK: ffff949da6f20000  CPU: 23   COMMAND: "vhost-32980"
+ #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253
+ #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3
+ #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e
+ #3 [fffffe00003fced0] do_nmi at ffffffff8922660d
+ #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663
+    [exception RIP: io_serial_in+20]
+    RIP: ffffffff89792594  RSP: ffffa655314979e8  RFLAGS: 00000002
+    RAX: ffffffff89792500  RBX: ffffffff8af428a0  RCX: 0000000000000000
+    RDX: 00000000000003fd  RSI: 0000000000000005  RDI: ffffffff8af428a0
+    RBP: 0000000000002710   R8: 0000000000000004   R9: 000000000000000f
+    R10: 0000000000000000  R11: ffffffff8acbf64f  R12: 0000000000000020
+    R13: ffffffff8acbf698  R14: 0000000000000058  R15: 0000000000000000
+    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
+ #5 [ffffa655314979e8] io_serial_in at ffffffff89792594
+ #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470
+ #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6
+ #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605
+ #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558
+ #10 [ffffa65531497ac8] console_unlock at ffffffff89316124
+ #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07
+ #12 [ffffa65531497b68] printk at ffffffff89318306
+ #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765
+ #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun]
+ #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun]
+ #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net]
+ #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]
+ #18 [ffffa65531497f10] kthread at ffffffff892d2e72
+ #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f
+
+Fixes: ef3db4a59542 ("tun: avoid BUG, dump packet on GSO errors")
+Signed-off-by: Lei Chen <lei.chen@smartx.com>
+Reviewed-by: Willem de Bruijn <willemb@google.com>
+Acked-by: Jason Wang <jasowang@redhat.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Acked-by: Michael S. Tsirkin <mst@redhat.com>
+Link: https://lore.kernel.org/r/20240415020247.2207781-1-lei.chen@smartx.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/tun.c | 18 ++++++++++--------
+ 1 file changed, 10 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/net/tun.c b/drivers/net/tun.c
+index 8f95a562b8d0c..86515f0c2b6c1 100644
+--- a/drivers/net/tun.c
++++ b/drivers/net/tun.c
+@@ -2132,14 +2132,16 @@ static ssize_t tun_put_user(struct tun_struct *tun,
+ 					    tun_is_little_endian(tun), true,
+ 					    vlan_hlen)) {
+ 			struct skb_shared_info *sinfo = skb_shinfo(skb);
+-			pr_err("unexpected GSO type: "
+-			       "0x%x, gso_size %d, hdr_len %d\n",
+-			       sinfo->gso_type, tun16_to_cpu(tun, gso.gso_size),
+-			       tun16_to_cpu(tun, gso.hdr_len));
+-			print_hex_dump(KERN_ERR, "tun: ",
+-				       DUMP_PREFIX_NONE,
+-				       16, 1, skb->head,
+-				       min((int)tun16_to_cpu(tun, gso.hdr_len), 64), true);
++
++			if (net_ratelimit()) {
++				netdev_err(tun->dev, "unexpected GSO type: 0x%x, gso_size %d, hdr_len %d\n",
++					   sinfo->gso_type, tun16_to_cpu(tun, gso.gso_size),
++					   tun16_to_cpu(tun, gso.hdr_len));
++				print_hex_dump(KERN_ERR, "tun: ",
++					       DUMP_PREFIX_NONE,
++					       16, 1, skb->head,
++					       min((int)tun16_to_cpu(tun, gso.hdr_len), 64), true);
++			}
+ 			WARN_ON_ONCE(1);
+ 			return -EINVAL;
+ 		}
+-- 
+2.43.0
+