[net-next PATCH 0/4] fbnic: Synchronize address handling with BMC

[net-next PATCH 0/4] fbnic: Synchronize address handling with BMC

[Alexander Duyck]

The fbnic driver needs to communicate with the BMC if it is operating on
the RMII-based transport (RBT) of the same port the host is on. To enable
this we need to add rules that will route BMC traffic to the RBT/BMC and
the BMC and firmware need to configure rules on the RBT side of the
interface to route traffic from the BMC to the host instead of the MAC.

To enable that this patch set addresses two issues. First it will cause the
TCAM to be reconfigured in the event that the BMC was not previously
present when the driver was loaded, but the FW sends a notification that
the FW capabilities have changed and a BMC w/ various MAC addresses is now
present. Second it adds support for sending a message to the firmware so
that if the host adds additional MAC addresses the FW can be made aware and
route traffic for those addresses from the RBT to the host instead of the
MAC.

---

Alexander Duyck (4):
      fbnic: Move promisc_sync out of netdev code and into RPC path
      fbnic: Pass fbnic_dev instead of netdev to __fbnic_set/clear_rx_mode
      fbnic: Add logic to repopulate RPC TCAM if BMC enables channel
      fbnic: Push local unicast MAC addresses to FW to populate TCAMs


 drivers/net/ethernet/meta/fbnic/fbnic_fw.c    | 106 ++++++++++++++++++
 drivers/net/ethernet/meta/fbnic/fbnic_fw.h    |  23 +++-
 .../net/ethernet/meta/fbnic/fbnic_netdev.c    |  60 ++--------
 .../net/ethernet/meta/fbnic/fbnic_netdev.h    |   4 +-
 drivers/net/ethernet/meta/fbnic/fbnic_pci.c   |   6 +-
 drivers/net/ethernet/meta/fbnic/fbnic_rpc.c   |  86 ++++++++++++--
 drivers/net/ethernet/meta/fbnic/fbnic_rpc.h   |   4 +
 7 files changed, 225 insertions(+), 64 deletions(-)

--

[net-next PATCH 1/4] fbnic: Move promisc_sync out of netdev code and into RPC path

[Alexander Duyck]

From: Alexander Duyck <alexanderduyck@fb.com>

In order for us to support the BMC possibly connecting, disconnecting, and
then reconnecting we need to be able to support entities outside of just
the NIC setting up promiscuous mode as the BMC can use a multicast
promiscuous setup.

To support that we should move the promisc_sync code out of the netdev and
into the RPC section of the driver so that it is reachable from more paths.

Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
---
 drivers/net/ethernet/meta/fbnic/fbnic_netdev.c |   45 +-----------------------
 drivers/net/ethernet/meta/fbnic/fbnic_rpc.c    |   44 +++++++++++++++++++++++
 drivers/net/ethernet/meta/fbnic/fbnic_rpc.h    |    3 ++
 3 files changed, 49 insertions(+), 43 deletions(-)

diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
index b8b684ad376b..c75c849a9cb2 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
@@ -220,49 +220,8 @@ void __fbnic_set_rx_mode(struct net_device *netdev)
 	uc_promisc |= !!(netdev->flags & IFF_PROMISC);
 	mc_promisc |= !!(netdev->flags & IFF_ALLMULTI) || uc_promisc;
 
-	/* Populate last TCAM entry with promiscuous entry and 0/1 bit mask */
-	mac_addr = &fbd->mac_addr[FBNIC_RPC_TCAM_MACDA_PROMISC_IDX];
-	if (uc_promisc) {
-		if (!is_zero_ether_addr(mac_addr->value.addr8) ||
-		    mac_addr->state != FBNIC_TCAM_S_VALID) {
-			eth_zero_addr(mac_addr->value.addr8);
-			eth_broadcast_addr(mac_addr->mask.addr8);
-			clear_bit(FBNIC_MAC_ADDR_T_ALLMULTI,
-				  mac_addr->act_tcam);
-			set_bit(FBNIC_MAC_ADDR_T_PROMISC,
-				mac_addr->act_tcam);
-			mac_addr->state = FBNIC_TCAM_S_ADD;
-		}
-	} else if (mc_promisc &&
-		   (!fbnic_bmc_present(fbd) || !fbd->fw_cap.all_multi)) {
-		/* We have to add a special handler for multicast as the
-		 * BMC may have an all-multi rule already in place. As such
-		 * adding a rule ourselves won't do any good so we will have
-		 * to modify the rules for the ALL MULTI below if the BMC
-		 * already has the rule in place.
-		 */
-		if (!is_multicast_ether_addr(mac_addr->value.addr8) ||
-		    mac_addr->state != FBNIC_TCAM_S_VALID) {
-			eth_zero_addr(mac_addr->value.addr8);
-			eth_broadcast_addr(mac_addr->mask.addr8);
-			mac_addr->value.addr8[0] ^= 1;
-			mac_addr->mask.addr8[0] ^= 1;
-			set_bit(FBNIC_MAC_ADDR_T_ALLMULTI,
-				mac_addr->act_tcam);
-			clear_bit(FBNIC_MAC_ADDR_T_PROMISC,
-				  mac_addr->act_tcam);
-			mac_addr->state = FBNIC_TCAM_S_ADD;
-		}
-	} else if (mac_addr->state == FBNIC_TCAM_S_VALID) {
-		if (test_bit(FBNIC_MAC_ADDR_T_BMC, mac_addr->act_tcam)) {
-			clear_bit(FBNIC_MAC_ADDR_T_ALLMULTI,
-				  mac_addr->act_tcam);
-			clear_bit(FBNIC_MAC_ADDR_T_PROMISC,
-				  mac_addr->act_tcam);
-		} else {
-			mac_addr->state = FBNIC_TCAM_S_DELETE;
-		}
-	}
+	/* Update the promiscuous rules */
+	fbnic_promisc_sync(fbd, uc_promisc, mc_promisc);
 
 	/* Add rules for BMC all multicast if it is enabled */
 	fbnic_bmc_rpc_all_multi_config(fbd, mc_promisc);
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_rpc.c b/drivers/net/ethernet/meta/fbnic/fbnic_rpc.c
index a4dc1024c0c2..d5badaced6c3 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_rpc.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_rpc.c
@@ -454,6 +454,50 @@ int __fbnic_xc_unsync(struct fbnic_mac_addr *mac_addr, unsigned int tcam_idx)
 	return 0;
 }
 
+void fbnic_promisc_sync(struct fbnic_dev *fbd,
+			bool uc_promisc, bool mc_promisc)
+{
+	struct fbnic_mac_addr *mac_addr;
+
+	/* Populate last TCAM entry with promiscuous entry and 0/1 bit mask */
+	mac_addr = &fbd->mac_addr[FBNIC_RPC_TCAM_MACDA_PROMISC_IDX];
+	if (uc_promisc) {
+		if (!is_zero_ether_addr(mac_addr->value.addr8) ||
+		    mac_addr->state != FBNIC_TCAM_S_VALID) {
+			eth_zero_addr(mac_addr->value.addr8);
+			eth_broadcast_addr(mac_addr->mask.addr8);
+			clear_bit(FBNIC_MAC_ADDR_T_ALLMULTI,
+				  mac_addr->act_tcam);
+			set_bit(FBNIC_MAC_ADDR_T_PROMISC,
+				mac_addr->act_tcam);
+			mac_addr->state = FBNIC_TCAM_S_ADD;
+		}
+	} else if (mc_promisc &&
+		   (!fbnic_bmc_present(fbd) || !fbd->fw_cap.all_multi)) {
+		/* We have to add a special handler for multicast as the
+		 * BMC may have an all-multi rule already in place. As such
+		 * adding a rule ourselves won't do any good so we will have
+		 * to modify the rules for the ALL MULTI below if the BMC
+		 * already has the rule in place.
+		 */
+		if (!is_multicast_ether_addr(mac_addr->value.addr8) ||
+		    mac_addr->state != FBNIC_TCAM_S_VALID) {
+			eth_zero_addr(mac_addr->value.addr8);
+			eth_broadcast_addr(mac_addr->mask.addr8);
+			mac_addr->value.addr8[0] ^= 1;
+			mac_addr->mask.addr8[0] ^= 1;
+			set_bit(FBNIC_MAC_ADDR_T_ALLMULTI,
+				mac_addr->act_tcam);
+			clear_bit(FBNIC_MAC_ADDR_T_PROMISC,
+				  mac_addr->act_tcam);
+			mac_addr->state = FBNIC_TCAM_S_ADD;
+		}
+	} else if (mac_addr->state == FBNIC_TCAM_S_VALID) {
+		__fbnic_xc_unsync(mac_addr, FBNIC_MAC_ADDR_T_ALLMULTI);
+		__fbnic_xc_unsync(mac_addr, FBNIC_MAC_ADDR_T_PROMISC);
+	}
+}
+
 void fbnic_sift_macda(struct fbnic_dev *fbd)
 {
 	int dest, src;
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_rpc.h b/drivers/net/ethernet/meta/fbnic/fbnic_rpc.h
index 6892414195c3..d9db7781a49b 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_rpc.h
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_rpc.h
@@ -201,6 +201,9 @@ struct fbnic_mac_addr *__fbnic_mc_sync(struct fbnic_dev *fbd,
 void fbnic_sift_macda(struct fbnic_dev *fbd);
 void fbnic_write_macda(struct fbnic_dev *fbd);
 
+void fbnic_promisc_sync(struct fbnic_dev *fbd,
+			bool uc_promisc, bool mc_promisc);
+
 struct fbnic_ip_addr *__fbnic_ip4_sync(struct fbnic_dev *fbd,
 				       struct fbnic_ip_addr *ip_addr,
 				       const struct in_addr *addr,

Re: [net-next PATCH 1/4] fbnic: Move promisc_sync out of netdev code and into RPC path

[Simon Horman]

On Tue, Aug 26, 2025 at 12:44:47PM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexanderduyck@fb.com>
> 
> In order for us to support the BMC possibly connecting, disconnecting, and
> then reconnecting we need to be able to support entities outside of just
> the NIC setting up promiscuous mode as the BMC can use a multicast
> promiscuous setup.
> 
> To support that we should move the promisc_sync code out of the netdev and
> into the RPC section of the driver so that it is reachable from more paths.
> 
> Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[net-next PATCH 2/4] fbnic: Pass fbnic_dev instead of netdev to __fbnic_set/clear_rx_mode

[Alexander Duyck]

From: Alexander Duyck <alexanderduyck@fb.com>

To make the __fbnic_set_rx_mode and __fbnic_clear_rx_mode calls usable by
more points in the code we can make to that they expect a fbnic_dev pointer
instead of a netdev pointer.

Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
---
 drivers/net/ethernet/meta/fbnic/fbnic_netdev.c |   15 ++++++++-------
 drivers/net/ethernet/meta/fbnic/fbnic_netdev.h |    4 ++--
 drivers/net/ethernet/meta/fbnic/fbnic_pci.c    |    4 ++--
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
index c75c849a9cb2..e2b831610388 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
@@ -179,11 +179,10 @@ static int fbnic_mc_unsync(struct net_device *netdev, const unsigned char *addr)
 	return ret;
 }
 
-void __fbnic_set_rx_mode(struct net_device *netdev)
+void __fbnic_set_rx_mode(struct fbnic_dev *fbd)
 {
-	struct fbnic_net *fbn = netdev_priv(netdev);
 	bool uc_promisc = false, mc_promisc = false;
-	struct fbnic_dev *fbd = fbn->fbd;
+	struct net_device *netdev = fbd->netdev;
 	struct fbnic_mac_addr *mac_addr;
 	int err;
 
@@ -237,9 +236,12 @@ void __fbnic_set_rx_mode(struct net_device *netdev)
 
 static void fbnic_set_rx_mode(struct net_device *netdev)
 {
+	struct fbnic_net *fbn = netdev_priv(netdev);
+	struct fbnic_dev *fbd = fbn->fbd;
+
 	/* No need to update the hardware if we are not running */
 	if (netif_running(netdev))
-		__fbnic_set_rx_mode(netdev);
+		__fbnic_set_rx_mode(fbd);
 }
 
 static int fbnic_set_mac(struct net_device *netdev, void *p)
@@ -256,10 +258,9 @@ static int fbnic_set_mac(struct net_device *netdev, void *p)
 	return 0;
 }
 
-void fbnic_clear_rx_mode(struct net_device *netdev)
+void fbnic_clear_rx_mode(struct fbnic_dev *fbd)
 {
-	struct fbnic_net *fbn = netdev_priv(netdev);
-	struct fbnic_dev *fbd = fbn->fbd;
+	struct net_device *netdev = fbd->netdev;
 	int idx;
 
 	for (idx = ARRAY_SIZE(fbd->mac_addr); idx--;) {
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.h b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.h
index 0a6347f28210..e84e0527c3a9 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.h
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.h
@@ -94,8 +94,8 @@ void fbnic_time_init(struct fbnic_net *fbn);
 int fbnic_time_start(struct fbnic_net *fbn);
 void fbnic_time_stop(struct fbnic_net *fbn);
 
-void __fbnic_set_rx_mode(struct net_device *netdev);
-void fbnic_clear_rx_mode(struct net_device *netdev);
+void __fbnic_set_rx_mode(struct fbnic_dev *fbd);
+void fbnic_clear_rx_mode(struct fbnic_dev *fbd);
 
 void fbnic_phylink_get_pauseparam(struct net_device *netdev,
 				  struct ethtool_pauseparam *pause);
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_pci.c b/drivers/net/ethernet/meta/fbnic/fbnic_pci.c
index b70e4cadb37b..06645183be08 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_pci.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_pci.c
@@ -137,7 +137,7 @@ void fbnic_up(struct fbnic_net *fbn)
 
 	fbnic_rss_reinit_hw(fbn->fbd, fbn);
 
-	__fbnic_set_rx_mode(fbn->netdev);
+	__fbnic_set_rx_mode(fbn->fbd);
 
 	/* Enable Tx/Rx processing */
 	fbnic_napi_enable(fbn);
@@ -154,7 +154,7 @@ void fbnic_down_noidle(struct fbnic_net *fbn)
 	fbnic_napi_disable(fbn);
 	netif_tx_disable(fbn->netdev);
 
-	fbnic_clear_rx_mode(fbn->netdev);
+	fbnic_clear_rx_mode(fbn->fbd);
 	fbnic_clear_rules(fbn->fbd);
 	fbnic_rss_disable_hw(fbn->fbd);
 	fbnic_disable(fbn);

Re: [net-next PATCH 2/4] fbnic: Pass fbnic_dev instead of netdev to __fbnic_set/clear_rx_mode

[Simon Horman]

On Tue, Aug 26, 2025 at 12:44:54PM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexanderduyck@fb.com>
> 
> To make the __fbnic_set_rx_mode and __fbnic_clear_rx_mode calls usable by
> more points in the code we can make to that they expect a fbnic_dev pointer
> instead of a netdev pointer.
> 
> Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[net-next PATCH 3/4] fbnic: Add logic to repopulate RPC TCAM if BMC enables channel

[Alexander Duyck]

From: Alexander Duyck <alexanderduyck@fb.com>

The BMC itself can decide to abandon a link and move onto another link in
the event of things such as a link flap. As a result the driver may load
with the BMC not present, and then needs to update things to support the
BMC being present while the link is up and the NIC is passing traffic.

To support this we add support to the watchdog to reinitialize the RPC to
support adding the BMC unicast, multicast, and multicast promiscuous
filters while the link is up and the NIC owns the link.

Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
---
 drivers/net/ethernet/meta/fbnic/fbnic_fw.c  |    3 +++
 drivers/net/ethernet/meta/fbnic/fbnic_fw.h  |    5 +++--
 drivers/net/ethernet/meta/fbnic/fbnic_pci.c |    2 ++
 drivers/net/ethernet/meta/fbnic/fbnic_rpc.c |   19 ++++++++++++-------
 drivers/net/ethernet/meta/fbnic/fbnic_rpc.h |    1 +
 5 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_fw.c b/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
index 0c55be7d2547..c7d255a095f0 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
@@ -653,6 +653,9 @@ static int fbnic_fw_parse_cap_resp(void *opaque, struct fbnic_tlv_msg **results)
 	fbd->fw_cap.anti_rollback_version =
 		fta_get_uint(results, FBNIC_FW_CAP_RESP_ANTI_ROLLBACK_VERSION);
 
+	/* Always assume we need a BMC reinit */
+	fbd->fw_cap.need_bmc_tcam_reinit = true;
+
 	return 0;
 }
 
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_fw.h b/drivers/net/ethernet/meta/fbnic/fbnic_fw.h
index fde331696fdd..e9a2bf489944 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_fw.h
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_fw.h
@@ -51,8 +51,9 @@ struct fbnic_fw_cap {
 	} stored;
 	u8	active_slot;
 	u8	bmc_mac_addr[4][ETH_ALEN];
-	u8	bmc_present	: 1;
-	u8	all_multi	: 1;
+	u8	bmc_present		: 1;
+	u8	need_bmc_tcam_reinit	: 1;
+	u8	all_multi		: 1;
 	u8	link_speed;
 	u8	link_fec;
 	u32	anti_rollback_version;
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_pci.c b/drivers/net/ethernet/meta/fbnic/fbnic_pci.c
index 06645183be08..1221a06961b0 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_pci.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_pci.c
@@ -206,6 +206,8 @@ static void fbnic_service_task(struct work_struct *work)
 
 	fbnic_health_check(fbd);
 
+	fbnic_bmc_rpc_check(fbd);
+
 	if (netif_carrier_ok(fbd->netdev))
 		fbnic_napi_depletion_check(fbd->netdev);
 
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_rpc.c b/drivers/net/ethernet/meta/fbnic/fbnic_rpc.c
index d5badaced6c3..d821625d602c 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_rpc.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_rpc.c
@@ -6,6 +6,7 @@
 #include <net/ipv6.h>
 
 #include "fbnic.h"
+#include "fbnic_fw.h"
 #include "fbnic_netdev.h"
 #include "fbnic_rpc.h"
 
@@ -131,12 +132,9 @@ void fbnic_bmc_rpc_all_multi_config(struct fbnic_dev *fbd,
 		else
 			clear_bit(FBNIC_MAC_ADDR_T_ALLMULTI,
 				  mac_addr->act_tcam);
-	} else if (!test_bit(FBNIC_MAC_ADDR_T_BMC, mac_addr->act_tcam) &&
-		   !is_zero_ether_addr(mac_addr->mask.addr8) &&
-		   mac_addr->state == FBNIC_TCAM_S_VALID) {
-		clear_bit(FBNIC_MAC_ADDR_T_ALLMULTI, mac_addr->act_tcam);
-		clear_bit(FBNIC_MAC_ADDR_T_BMC, mac_addr->act_tcam);
-		mac_addr->state = FBNIC_TCAM_S_DELETE;
+	} else {
+		__fbnic_xc_unsync(mac_addr, FBNIC_MAC_ADDR_T_BMC);
+		__fbnic_xc_unsync(mac_addr, FBNIC_MAC_ADDR_T_ALLMULTI);
 	}
 
 	/* We have to add a special handler for multicast as the
@@ -238,8 +236,15 @@ void fbnic_bmc_rpc_init(struct fbnic_dev *fbd)
 		act_tcam->mask.tcam[j] = 0xffff;
 
 	act_tcam->state = FBNIC_TCAM_S_UPDATE;
+}
 
-	fbnic_bmc_rpc_all_multi_config(fbd, false);
+void fbnic_bmc_rpc_check(struct fbnic_dev *fbd)
+{
+	if (fbd->fw_cap.need_bmc_tcam_reinit) {
+		fbnic_bmc_rpc_init(fbd);
+		__fbnic_set_rx_mode(fbd);
+		fbd->fw_cap.need_bmc_tcam_reinit = false;
+	}
 }
 
 #define FBNIC_ACT1_INIT(_l4, _udp, _ip, _v6)		\
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_rpc.h b/drivers/net/ethernet/meta/fbnic/fbnic_rpc.h
index d9db7781a49b..3d4925b2ac75 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_rpc.h
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_rpc.h
@@ -184,6 +184,7 @@ struct fbnic_net;
 
 void fbnic_bmc_rpc_init(struct fbnic_dev *fbd);
 void fbnic_bmc_rpc_all_multi_config(struct fbnic_dev *fbd, bool enable_host);
+void fbnic_bmc_rpc_check(struct fbnic_dev *fbd);
 
 void fbnic_reset_indir_tbl(struct fbnic_net *fbn);
 void fbnic_rss_key_fill(u32 *buffer);

Re: [net-next PATCH 3/4] fbnic: Add logic to repopulate RPC TCAM if BMC enables channel

[Simon Horman]

On Tue, Aug 26, 2025 at 12:45:01PM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexanderduyck@fb.com>
> 
> The BMC itself can decide to abandon a link and move onto another link in
> the event of things such as a link flap. As a result the driver may load
> with the BMC not present, and then needs to update things to support the
> BMC being present while the link is up and the NIC is passing traffic.
> 
> To support this we add support to the watchdog to reinitialize the RPC to
> support adding the BMC unicast, multicast, and multicast promiscuous
> filters while the link is up and the NIC owns the link.
> 
> Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[net-next PATCH 4/4] fbnic: Push local unicast MAC addresses to FW to populate TCAMs

[Alexander Duyck]

From: Alexander Duyck <alexanderduyck@fb.com>

The MACDA TCAM can only be accessed by one entity at a time and as such we
cannot have simultaneous reads from the firmware to probe for changes from
the host. As such we have to send a message indicating what the state of
the MACDA is to the firmware when we updated it so that the firmware can
sync up the TCAMs it owns to route BMC packets to the host.

To support that we are adding a new message that is invoked when we write
the MACDA that will notify the firmware of updates from the host and allow
it to sync up the TCAM configuration to match the one on the host side.

Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
---
 drivers/net/ethernet/meta/fbnic/fbnic_fw.c  |  103 +++++++++++++++++++++++++++
 drivers/net/ethernet/meta/fbnic/fbnic_fw.h  |   18 +++++
 drivers/net/ethernet/meta/fbnic/fbnic_rpc.c |   23 ++++++
 3 files changed, 143 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_fw.c b/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
index c7d255a095f0..6e580654493c 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
@@ -1413,6 +1413,109 @@ void fbnic_mbx_flush_tx(struct fbnic_dev *fbd)
 	} while (time_is_after_jiffies(timeout));
 }
 
+int fbnic_fw_xmit_rpc_macda_sync(struct fbnic_dev *fbd)
+{
+	struct fbnic_tlv_msg *mac_array;
+	int i, addr_count = 0, err;
+	struct fbnic_tlv_msg *msg;
+	u32 rx_flags = 0;
+
+	/* Nothing to do if there is no FW to sync with */
+	if (!fbd->mbx[FBNIC_IPC_MBX_TX_IDX].ready)
+		return 0;
+
+	msg = fbnic_tlv_msg_alloc(FBNIC_TLV_MSG_ID_RPC_MAC_SYNC_REQ);
+	if (!msg)
+		return -ENOMEM;
+
+	mac_array = fbnic_tlv_attr_nest_start(msg,
+					      FBNIC_FW_RPC_MAC_SYNC_UC_ARRAY);
+	if (!mac_array)
+		goto free_message_nospc;
+
+	/* Populate the unicast MAC addrs and capture PROMISC/ALLMULTI flags */
+	for (addr_count = 0, i = FBNIC_RPC_TCAM_MACDA_PROMISC_IDX;
+	     i >= fbd->mac_addr_boundary; i--) {
+		struct fbnic_mac_addr *mac_addr = &fbd->mac_addr[i];
+
+		if (mac_addr->state != FBNIC_TCAM_S_VALID)
+			continue;
+		if (test_bit(FBNIC_MAC_ADDR_T_ALLMULTI, mac_addr->act_tcam))
+			rx_flags |= FW_RPC_MAC_SYNC_RX_FLAGS_ALLMULTI;
+		if (test_bit(FBNIC_MAC_ADDR_T_PROMISC, mac_addr->act_tcam))
+			rx_flags |= FW_RPC_MAC_SYNC_RX_FLAGS_PROMISC;
+		if (!test_bit(FBNIC_MAC_ADDR_T_UNICAST, mac_addr->act_tcam))
+			continue;
+		if (addr_count == FW_RPC_MAC_SYNC_UC_ARRAY_SIZE) {
+			rx_flags |= FW_RPC_MAC_SYNC_RX_FLAGS_PROMISC;
+			continue;
+		}
+
+		err = fbnic_tlv_attr_put_value(mac_array,
+					       FBNIC_FW_RPC_MAC_SYNC_MAC_ADDR,
+					       mac_addr->value.addr8,
+					       ETH_ALEN);
+		if (err)
+			goto free_message;
+		addr_count++;
+	}
+
+	/* Close array */
+	fbnic_tlv_attr_nest_stop(msg);
+
+	mac_array = fbnic_tlv_attr_nest_start(msg,
+					      FBNIC_FW_RPC_MAC_SYNC_MC_ARRAY);
+	if (!mac_array)
+		goto free_message_nospc;
+
+	/* Repeat for multicast addrs, record BROADCAST/ALLMULTI flags */
+	for (addr_count = 0, i = FBNIC_RPC_TCAM_MACDA_BROADCAST_IDX;
+	     i < fbd->mac_addr_boundary; i++) {
+		struct fbnic_mac_addr *mac_addr = &fbd->mac_addr[i];
+
+		if (mac_addr->state != FBNIC_TCAM_S_VALID)
+			continue;
+		if (test_bit(FBNIC_MAC_ADDR_T_BROADCAST, mac_addr->act_tcam))
+			rx_flags |= FW_RPC_MAC_SYNC_RX_FLAGS_BROADCAST;
+		if (test_bit(FBNIC_MAC_ADDR_T_ALLMULTI, mac_addr->act_tcam))
+			rx_flags |= FW_RPC_MAC_SYNC_RX_FLAGS_ALLMULTI;
+		if (!test_bit(FBNIC_MAC_ADDR_T_MULTICAST, mac_addr->act_tcam))
+			continue;
+		if (addr_count == FW_RPC_MAC_SYNC_MC_ARRAY_SIZE) {
+			rx_flags |= FW_RPC_MAC_SYNC_RX_FLAGS_ALLMULTI;
+			continue;
+		}
+
+		err = fbnic_tlv_attr_put_value(mac_array,
+					       FBNIC_FW_RPC_MAC_SYNC_MAC_ADDR,
+					       mac_addr->value.addr8,
+					       ETH_ALEN);
+		if (err)
+			goto free_message;
+		addr_count++;
+	}
+
+	/* Close array */
+	fbnic_tlv_attr_nest_stop(msg);
+
+	/* Report flags at end of list */
+	err = fbnic_tlv_attr_put_int(msg, FBNIC_FW_RPC_MAC_SYNC_RX_FLAGS,
+				     rx_flags);
+	if (err)
+		goto free_message;
+
+	/* Send message of to FW notifying it of current RPC config */
+	err = fbnic_mbx_map_tlv_msg(fbd, msg);
+	if (err)
+		goto free_message;
+	return 0;
+free_message_nospc:
+	err = -ENOSPC;
+free_message:
+	free_page((unsigned long)msg);
+	return err;
+}
+
 void fbnic_get_fw_ver_commit_str(struct fbnic_dev *fbd, char *fw_version,
 				 const size_t str_sz)
 {
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_fw.h b/drivers/net/ethernet/meta/fbnic/fbnic_fw.h
index e9a2bf489944..ec67b80809b0 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_fw.h
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_fw.h
@@ -53,6 +53,7 @@ struct fbnic_fw_cap {
 	u8	bmc_mac_addr[4][ETH_ALEN];
 	u8	bmc_present		: 1;
 	u8	need_bmc_tcam_reinit	: 1;
+	u8	need_bmc_macda_sync	: 1;
 	u8	all_multi		: 1;
 	u8	link_speed;
 	u8	link_fec;
@@ -98,6 +99,7 @@ int fbnic_fw_xmit_tsene_read_msg(struct fbnic_dev *fbd,
 				 struct fbnic_fw_completion *cmpl_data);
 int fbnic_fw_xmit_send_logs(struct fbnic_dev *fbd, bool enable,
 			    bool send_log_history);
+int fbnic_fw_xmit_rpc_macda_sync(struct fbnic_dev *fbd);
 struct fbnic_fw_completion *fbnic_fw_alloc_cmpl(u32 msg_type);
 void fbnic_fw_put_cmpl(struct fbnic_fw_completion *cmpl_data);
 
@@ -144,6 +146,7 @@ enum {
 	FBNIC_TLV_MSG_ID_LOG_SEND_LOGS_REQ		= 0x43,
 	FBNIC_TLV_MSG_ID_LOG_MSG_REQ			= 0x44,
 	FBNIC_TLV_MSG_ID_LOG_MSG_RESP			= 0x45,
+	FBNIC_TLV_MSG_ID_RPC_MAC_SYNC_REQ		= 0x46,
 };
 
 #define FBNIC_FW_CAP_RESP_VERSION_MAJOR		CSR_GENMASK(31, 24)
@@ -236,4 +239,19 @@ enum {
 	FBNIC_FW_LOG_MSG_MAX
 };
 
+enum {
+	FBNIC_FW_RPC_MAC_SYNC_RX_FLAGS		= 0x0,
+	FBNIC_FW_RPC_MAC_SYNC_UC_ARRAY		= 0x1,
+	FBNIC_FW_RPC_MAC_SYNC_MC_ARRAY		= 0x2,
+	FBNIC_FW_RPC_MAC_SYNC_MAC_ADDR		= 0x3,
+	FBNIC_FW_RPC_MAC_SYNC_MSG_MAX
+};
+
+#define FW_RPC_MAC_SYNC_RX_FLAGS_PROMISC	1
+#define FW_RPC_MAC_SYNC_RX_FLAGS_ALLMULTI	2
+#define FW_RPC_MAC_SYNC_RX_FLAGS_BROADCAST	4
+
+#define FW_RPC_MAC_SYNC_UC_ARRAY_SIZE		8
+#define FW_RPC_MAC_SYNC_MC_ARRAY_SIZE		8
+
 #endif /* _FBNIC_FW_H_ */
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_rpc.c b/drivers/net/ethernet/meta/fbnic/fbnic_rpc.c
index d821625d602c..4284b3cb7fcc 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_rpc.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_rpc.c
@@ -240,11 +240,21 @@ void fbnic_bmc_rpc_init(struct fbnic_dev *fbd)
 
 void fbnic_bmc_rpc_check(struct fbnic_dev *fbd)
 {
+	int err;
+
 	if (fbd->fw_cap.need_bmc_tcam_reinit) {
 		fbnic_bmc_rpc_init(fbd);
 		__fbnic_set_rx_mode(fbd);
 		fbd->fw_cap.need_bmc_tcam_reinit = false;
 	}
+
+	if (fbd->fw_cap.need_bmc_macda_sync) {
+		err = fbnic_fw_xmit_rpc_macda_sync(fbd);
+		if (err)
+			dev_warn(fbd->dev,
+				 "Writing MACDA table to FW failed, err: %d\n", err);
+		fbd->fw_cap.need_bmc_macda_sync = false;
+	}
 }
 
 #define FBNIC_ACT1_INIT(_l4, _udp, _ip, _v6)		\
@@ -607,7 +617,7 @@ static void fbnic_write_macda_entry(struct fbnic_dev *fbd, unsigned int idx,
 
 void fbnic_write_macda(struct fbnic_dev *fbd)
 {
-	int idx;
+	int idx, updates = 0;
 
 	for (idx = ARRAY_SIZE(fbd->mac_addr); idx--;) {
 		struct fbnic_mac_addr *mac_addr = &fbd->mac_addr[idx];
@@ -616,6 +626,9 @@ void fbnic_write_macda(struct fbnic_dev *fbd)
 		if (!(mac_addr->state & FBNIC_TCAM_S_UPDATE))
 			continue;
 
+		/* Record update count */
+		updates++;
+
 		/* Clear by writing 0s. */
 		if (mac_addr->state == FBNIC_TCAM_S_DELETE) {
 			/* Invalidate entry and clear addr state info */
@@ -629,6 +642,14 @@ void fbnic_write_macda(struct fbnic_dev *fbd)
 
 		mac_addr->state = FBNIC_TCAM_S_VALID;
 	}
+
+	/* If reinitializing the BMC TCAM we are doing an initial update */
+	if (fbd->fw_cap.need_bmc_tcam_reinit)
+		updates++;
+
+	/* If needed notify firmware of changes to MACDA TCAM */
+	if (updates != 0 && fbnic_bmc_present(fbd))
+		fbd->fw_cap.need_bmc_macda_sync = true;
 }
 
 static void fbnic_clear_act_tcam(struct fbnic_dev *fbd, unsigned int idx)

Re: [net-next PATCH 4/4] fbnic: Push local unicast MAC addresses to FW to populate TCAMs

[Simon Horman]

On Tue, Aug 26, 2025 at 12:45:07PM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexanderduyck@fb.com>
> 
> The MACDA TCAM can only be accessed by one entity at a time and as such we
> cannot have simultaneous reads from the firmware to probe for changes from
> the host. As such we have to send a message indicating what the state of
> the MACDA is to the firmware when we updated it so that the firmware can
> sync up the TCAMs it owns to route BMC packets to the host.
> 
> To support that we are adding a new message that is invoked when we write
> the MACDA that will notify the firmware of updates from the host and allow
> it to sync up the TCAM configuration to match the one on the host side.
> 
> Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>

Reviewed-by: Simon Horman <horms@kernel.org>

Re: [net-next PATCH 0/4] fbnic: Synchronize address handling with BMC

[Paolo Abeni]

On 8/26/25 9:44 PM, Alexander Duyck wrote:
> The fbnic driver needs to communicate with the BMC if it is operating on
> the RMII-based transport (RBT) of the same port the host is on. To enable
> this we need to add rules that will route BMC traffic to the RBT/BMC and
> the BMC and firmware need to configure rules on the RBT side of the
> interface to route traffic from the BMC to the host instead of the MAC.
> 
> To enable that this patch set addresses two issues. First it will cause the
> TCAM to be reconfigured in the event that the BMC was not previously
> present when the driver was loaded, but the FW sends a notification that
> the FW capabilities have changed and a BMC w/ various MAC addresses is now
> present. Second it adds support for sending a message to the firmware so
> that if the host adds additional MAC addresses the FW can be made aware and
> route traffic for those addresses from the RBT to the host instead of the
> MAC.

The CI is observing a few possible leaks on top of this series:

unreferenced object 0xffff888011146040 (size 216):
  comm "napi/enp1s0-0", pid 4116, jiffies 4295559830
  hex dump (first 32 bytes):
    c0 bc a0 08 80 88 ff ff 00 00 00 00 00 00 00 00  ................
    00 40 02 08 80 88 ff ff 00 00 00 00 00 00 00 00  .@..............
  backtrace (crc d10d3409):
    kmem_cache_alloc_bulk_noprof+0x115/0x160
    napi_skb_cache_get+0x423/0x750
    napi_build_skb+0x19/0x210
    xdp_build_skb_from_buff+0xda/0x820
    fbnic_run_xdp+0x36c/0x550
    fbnic_clean_rcq+0x540/0x1790
    fbnic_poll+0x142/0x290
    __napi_poll.constprop.0+0x9f/0x460
    napi_threaded_poll_loop+0x44d/0x610
    napi_threaded_poll+0x17/0x30
    kthread+0x37b/0x5f0
    ret_from_fork+0x240/0x320
    ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888008a0bcc0 (size 216):
  comm "napi/enp1s0-0", pid 4116, jiffies 4295560865
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 40 02 08 80 88 ff ff 00 00 00 00 00 00 00 00  .@..............
  backtrace (crc d69e2bd9):
    kmem_cache_alloc_node_noprof+0x289/0x330
    __alloc_skb+0x20f/0x2e0
    __tcp_send_ack.part.0+0x68/0x6b0
    tcp_rcv_established+0x69c/0x2340
    tcp_v6_do_rcv+0x9b4/0x1370
    tcp_v6_rcv+0x1bc5/0x2f90
    ip6_protocol_deliver_rcu+0x112/0x1140
    ip6_input+0x201/0x5e0
    ip6_sublist_rcv_finish+0x91/0x260
    ip6_list_rcv_finish.constprop.0+0x55b/0xa10
    ipv6_list_rcv+0x318/0x4b0
    __netif_receive_skb_list_core+0x4c6/0x980
    netif_receive_skb_list_internal+0x63c/0xe50
    gro_complete.constprop.0+0x54d/0x750
    __gro_flush+0x14a/0x490
    __napi_poll.constprop.0+0x319/0x460

But AFAICS they don't look related to the changes in this series, even
if I'm not able to spot real suspects in the changes tested in the
relevant batch:

https://netdev.bots.linux.dev/static/nipa/branch_deltas/net-next-hw-2025-08-28--08-00.html

Some feeling towards the RPS patches, but they look safe to me.

/P

Re: [net-next PATCH 0/4] fbnic: Synchronize address handling with BMC

[Paolo Abeni]

On 8/28/25 12:46 PM, Paolo Abeni wrote:
> On 8/26/25 9:44 PM, Alexander Duyck wrote:
>> The fbnic driver needs to communicate with the BMC if it is operating on
>> the RMII-based transport (RBT) of the same port the host is on. To enable
>> this we need to add rules that will route BMC traffic to the RBT/BMC and
>> the BMC and firmware need to configure rules on the RBT side of the
>> interface to route traffic from the BMC to the host instead of the MAC.
>>
>> To enable that this patch set addresses two issues. First it will cause the
>> TCAM to be reconfigured in the event that the BMC was not previously
>> present when the driver was loaded, but the FW sends a notification that
>> the FW capabilities have changed and a BMC w/ various MAC addresses is now
>> present. Second it adds support for sending a message to the firmware so
>> that if the host adds additional MAC addresses the FW can be made aware and
>> route traffic for those addresses from the RBT to the host instead of the
>> MAC.
> 
> The CI is observing a few possible leaks on top of this series:
> 
> unreferenced object 0xffff888011146040 (size 216):
>   comm "napi/enp1s0-0", pid 4116, jiffies 4295559830
>   hex dump (first 32 bytes):
>     c0 bc a0 08 80 88 ff ff 00 00 00 00 00 00 00 00  ................
>     00 40 02 08 80 88 ff ff 00 00 00 00 00 00 00 00  .@..............
>   backtrace (crc d10d3409):
>     kmem_cache_alloc_bulk_noprof+0x115/0x160
>     napi_skb_cache_get+0x423/0x750
>     napi_build_skb+0x19/0x210
>     xdp_build_skb_from_buff+0xda/0x820
>     fbnic_run_xdp+0x36c/0x550
>     fbnic_clean_rcq+0x540/0x1790
>     fbnic_poll+0x142/0x290
>     __napi_poll.constprop.0+0x9f/0x460
>     napi_threaded_poll_loop+0x44d/0x610
>     napi_threaded_poll+0x17/0x30
>     kthread+0x37b/0x5f0
>     ret_from_fork+0x240/0x320
>     ret_from_fork_asm+0x11/0x20
> unreferenced object 0xffff888008a0bcc0 (size 216):
>   comm "napi/enp1s0-0", pid 4116, jiffies 4295560865
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>     00 40 02 08 80 88 ff ff 00 00 00 00 00 00 00 00  .@..............
>   backtrace (crc d69e2bd9):
>     kmem_cache_alloc_node_noprof+0x289/0x330
>     __alloc_skb+0x20f/0x2e0
>     __tcp_send_ack.part.0+0x68/0x6b0
>     tcp_rcv_established+0x69c/0x2340
>     tcp_v6_do_rcv+0x9b4/0x1370
>     tcp_v6_rcv+0x1bc5/0x2f90
>     ip6_protocol_deliver_rcu+0x112/0x1140
>     ip6_input+0x201/0x5e0
>     ip6_sublist_rcv_finish+0x91/0x260
>     ip6_list_rcv_finish.constprop.0+0x55b/0xa10
>     ipv6_list_rcv+0x318/0x4b0
>     __netif_receive_skb_list_core+0x4c6/0x980
>     netif_receive_skb_list_internal+0x63c/0xe50
>     gro_complete.constprop.0+0x54d/0x750
>     __gro_flush+0x14a/0x490
>     __napi_poll.constprop.0+0x319/0x460
> 
> But AFAICS they don't look related to the changes in this series, 

I went over the series with more attention, I'm reasonably sure the leak
are unrelated. Possibly is kmemleak fouled by some unfortunate timing?

In any case I'm applying this series now.

/P

Re: [net-next PATCH 0/4] fbnic: Synchronize address handling with BMC

[Alexander Duyck]

On Thu, Aug 28, 2025 at 5:50 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On 8/28/25 12:46 PM, Paolo Abeni wrote:
> > On 8/26/25 9:44 PM, Alexander Duyck wrote:
> >> The fbnic driver needs to communicate with the BMC if it is operating on
> >> the RMII-based transport (RBT) of the same port the host is on. To enable
> >> this we need to add rules that will route BMC traffic to the RBT/BMC and
> >> the BMC and firmware need to configure rules on the RBT side of the
> >> interface to route traffic from the BMC to the host instead of the MAC.
> >>
> >> To enable that this patch set addresses two issues. First it will cause the
> >> TCAM to be reconfigured in the event that the BMC was not previously
> >> present when the driver was loaded, but the FW sends a notification that
> >> the FW capabilities have changed and a BMC w/ various MAC addresses is now
> >> present. Second it adds support for sending a message to the firmware so
> >> that if the host adds additional MAC addresses the FW can be made aware and
> >> route traffic for those addresses from the RBT to the host instead of the
> >> MAC.
> >
> > The CI is observing a few possible leaks on top of this series:
> >
> > unreferenced object 0xffff888011146040 (size 216):
> >   comm "napi/enp1s0-0", pid 4116, jiffies 4295559830
> >   hex dump (first 32 bytes):
> >     c0 bc a0 08 80 88 ff ff 00 00 00 00 00 00 00 00  ................
> >     00 40 02 08 80 88 ff ff 00 00 00 00 00 00 00 00  .@..............
> >   backtrace (crc d10d3409):
> >     kmem_cache_alloc_bulk_noprof+0x115/0x160
> >     napi_skb_cache_get+0x423/0x750
> >     napi_build_skb+0x19/0x210
> >     xdp_build_skb_from_buff+0xda/0x820
> >     fbnic_run_xdp+0x36c/0x550
> >     fbnic_clean_rcq+0x540/0x1790
> >     fbnic_poll+0x142/0x290
> >     __napi_poll.constprop.0+0x9f/0x460
> >     napi_threaded_poll_loop+0x44d/0x610
> >     napi_threaded_poll+0x17/0x30
> >     kthread+0x37b/0x5f0
> >     ret_from_fork+0x240/0x320
> >     ret_from_fork_asm+0x11/0x20
> > unreferenced object 0xffff888008a0bcc0 (size 216):
> >   comm "napi/enp1s0-0", pid 4116, jiffies 4295560865
> >   hex dump (first 32 bytes):
> >     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> >     00 40 02 08 80 88 ff ff 00 00 00 00 00 00 00 00  .@..............
> >   backtrace (crc d69e2bd9):
> >     kmem_cache_alloc_node_noprof+0x289/0x330
> >     __alloc_skb+0x20f/0x2e0
> >     __tcp_send_ack.part.0+0x68/0x6b0
> >     tcp_rcv_established+0x69c/0x2340
> >     tcp_v6_do_rcv+0x9b4/0x1370
> >     tcp_v6_rcv+0x1bc5/0x2f90
> >     ip6_protocol_deliver_rcu+0x112/0x1140
> >     ip6_input+0x201/0x5e0
> >     ip6_sublist_rcv_finish+0x91/0x260
> >     ip6_list_rcv_finish.constprop.0+0x55b/0xa10
> >     ipv6_list_rcv+0x318/0x4b0
> >     __netif_receive_skb_list_core+0x4c6/0x980
> >     netif_receive_skb_list_internal+0x63c/0xe50
> >     gro_complete.constprop.0+0x54d/0x750
> >     __gro_flush+0x14a/0x490
> >     __napi_poll.constprop.0+0x319/0x460
> >
> > But AFAICS they don't look related to the changes in this series,
>
> I went over the series with more attention, I'm reasonably sure the leak
> are unrelated. Possibly is kmemleak fouled by some unfortunate timing?
>
> In any case I'm applying this series now.
>
> /P

Yeah, as far as I can tell this would most likely be related to the
recent XDP changes that were added by Mohsin. I added him to the Cc
just so he is aware. As far as I know we haven't seen anything similar
in our CI, but we will keep an eye out for it and will track it
internally as a sighting in the event that we start seeing similar
issues.

Thanks,

- Alex

Re: [net-next PATCH 0/4] fbnic: Synchronize address handling with BMC

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:

On Tue, 26 Aug 2025 12:44:41 -0700 you wrote:
> The fbnic driver needs to communicate with the BMC if it is operating on
> the RMII-based transport (RBT) of the same port the host is on. To enable
> this we need to add rules that will route BMC traffic to the RBT/BMC and
> the BMC and firmware need to configure rules on the RBT side of the
> interface to route traffic from the BMC to the host instead of the MAC.
> 
> To enable that this patch set addresses two issues. First it will cause the
> TCAM to be reconfigured in the event that the BMC was not previously
> present when the driver was loaded, but the FW sends a notification that
> the FW capabilities have changed and a BMC w/ various MAC addresses is now
> present. Second it adds support for sending a message to the firmware so
> that if the host adds additional MAC addresses the FW can be made aware and
> route traffic for those addresses from the RBT to the host instead of the
> MAC.
> 
> [...]

Here is the summary with links:
  - [net-next,1/4] fbnic: Move promisc_sync out of netdev code and into RPC path
    https://git.kernel.org/netdev/net-next/c/cf79bd449511
  - [net-next,2/4] fbnic: Pass fbnic_dev instead of netdev to __fbnic_set/clear_rx_mode
    https://git.kernel.org/netdev/net-next/c/284a67d59f39
  - [net-next,3/4] fbnic: Add logic to repopulate RPC TCAM if BMC enables channel
    https://git.kernel.org/netdev/net-next/c/04a230b27d8f
  - [net-next,4/4] fbnic: Push local unicast MAC addresses to FW to populate TCAMs
    https://git.kernel.org/netdev/net-next/c/cee8d21d8091

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html