linux-stable.git/drivers/net, branch v6.17.4 Linux kernel stable tree wifi: mt76: mt7921u: Add VID/PID for Netgear A7500 2025-10-19T14:37:38+00:00 Nick Morrow morrownr@gmail.com 2025-09-12T20:45:56+00:00 1a4b0c26e1b0472153564d3bf5e893929f317b8b commit fc6627ca8a5f811b601aea74e934cf8a048c88ac upstream. Add VID/PID 0846/9065 for Netgear A7500. Reported-by: Autumn Dececco <autumndececco@gmail.com> Tested-by: Autumn Dececco <autumndececco@gmail.com> Signed-off-by: Nick Morrow <morrownr@gmail.com> Cc: stable@vger.kernel.org Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/80bacfd6-6073-4ce5-be32-ae9580832337@gmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fc6627ca8a5f811b601aea74e934cf8a048c88ac upstream.

Add VID/PID 0846/9065 for Netgear A7500.

Reported-by: Autumn Dececco <autumndececco@gmail.com>
Tested-by: Autumn Dececco <autumndececco@gmail.com>
Signed-off-by: Nick Morrow <morrownr@gmail.com>
Cc: stable@vger.kernel.org
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/80bacfd6-6073-4ce5-be32-ae9580832337@gmail.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
wifi: mt76: mt7925u: Add VID/PID for Netgear A9000 2025-10-19T14:37:37+00:00 Nick Morrow morrownr@gmail.com 2025-07-08T21:40:42+00:00 34a7b7a4c1eb9853bc02e93bcd6c371d2c72189b commit f6159b2051e157550d7609e19d04471609c6050b upstream. Add VID/PID 0846/9072 for recently released Netgear A9000. Signed-off-by: Nick Morrow <morrownr@gmail.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/7afd3c3c-e7cf-4bd9-801d-bdfc76def506@gmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f6159b2051e157550d7609e19d04471609c6050b upstream.

Add VID/PID 0846/9072 for recently released Netgear A9000.

Signed-off-by: Nick Morrow <morrownr@gmail.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/7afd3c3c-e7cf-4bd9-801d-bdfc76def506@gmail.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
wifi: rtw89: avoid possible TX wait initialization race 2025-10-19T14:37:37+00:00 Fedor Pchelkin pchelkin@ispras.ru 2025-09-19T21:08:48+00:00 b5204956ab74c1139dc33d9754e2ea0714d01f01 commit c24248ed78f33ea299ea61d105355ba47157d49f upstream. The value of skb_data->wait indicates whether skb is passed on to the core mac80211 stack or released by the driver itself. Make sure that by the time skb is added to txwd queue and becomes visible to the completing side, it has already allocated and initialized TX wait related data (in case it's needed). This is found by code review and addresses a possible race scenario described below: Waiting thread Completing thread rtw89_core_send_nullfunc() rtw89_core_tx_write_link() ... rtw89_pci_txwd_submit() skb_data->wait = NULL /* add skb to the queue */ skb_queue_tail(&txwd->queue, skb) /* another thread (e.g. rtw89_ops_tx) performs TX kick off for the same queue */ rtw89_pci_napi_poll() ... rtw89_pci_release_txwd_skb() /* get skb from the queue */ skb_unlink(skb, &txwd->queue) rtw89_pci_tx_status() rtw89_core_tx_wait_complete() /* use incorrect skb_data->wait */ rtw89_core_tx_kick_off_and_wait() /* assign skb_data->wait but too late */ Found by Linux Verification Center (linuxtesting.org). Fixes: 1ae5ca615285 ("wifi: rtw89: add function to wait for completion of TX skbs") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250919210852.823912-3-pchelkin@ispras.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit c24248ed78f33ea299ea61d105355ba47157d49f upstream.

The value of skb_data->wait indicates whether skb is passed on to the
core mac80211 stack or released by the driver itself.  Make sure that by
the time skb is added to txwd queue and becomes visible to the completing
side, it has already allocated and initialized TX wait related data (in
case it's needed).

This is found by code review and addresses a possible race scenario
described below:

      Waiting thread                          Completing thread

rtw89_core_send_nullfunc()
  rtw89_core_tx_write_link()
    ...
    rtw89_pci_txwd_submit()
      skb_data->wait = NULL
      /* add skb to the queue */
      skb_queue_tail(&txwd->queue, skb)

  /* another thread (e.g. rtw89_ops_tx) performs TX kick off for the same queue */

                                            rtw89_pci_napi_poll()
                                            ...
                                              rtw89_pci_release_txwd_skb()
                                                /* get skb from the queue */
                                                skb_unlink(skb, &txwd->queue)
                                                rtw89_pci_tx_status()
                                                  rtw89_core_tx_wait_complete()
                                                  /* use incorrect skb_data->wait */
  rtw89_core_tx_kick_off_and_wait()
  /* assign skb_data->wait but too late */

Found by Linux Verification Center (linuxtesting.org).

Fixes: 1ae5ca615285 ("wifi: rtw89: add function to wait for completion of TX skbs")
Cc: stable@vger.kernel.org
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250919210852.823912-3-pchelkin@ispras.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
wifi: iwlwifi: Fix dentry reference leak in iwl_mld_add_link_debugfs 2025-10-19T14:37:37+00:00 Miaoqian Lin linmq006@gmail.com 2025-09-02T04:09:49+00:00 15b31e8b87fd1d57bfc0f2f8cacc1d0e9dbdc90d commit ff46e2e7034c78489fa7a6bc35f7c9dd8ab82905 upstream. The debugfs_lookup() function increases the dentry reference count. Add missing dput() call to release the reference when the "iwlmld" directory already exists. Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Link: https://patch.msgid.link/20250902040955.2362472-1-linmq006@gmail.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ff46e2e7034c78489fa7a6bc35f7c9dd8ab82905 upstream.

The debugfs_lookup() function increases the dentry reference count.
Add missing dput() call to release the reference when the "iwlmld"
directory already exists.

Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver")
Cc: stable@vger.kernel.org
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Link: https://patch.msgid.link/20250902040955.2362472-1-linmq006@gmail.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again 2025-10-19T14:37:37+00:00 Muhammad Usama Anjum usama.anjum@collabora.com 2025-07-22T05:31:21+00:00 79266fd78df15585e2fd6c9b8a0ee122749a4b77 commit 32be3ca4cf78b309dfe7ba52fe2d7cc3c23c5634 upstream. Don't deinitialize and reinitialize the HAL helpers. The dma memory is deallocated and there is high possibility that we'll not be able to get the same memory allocated from dma when there is high memory pressure. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.6 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Cc: stable@vger.kernel.org Cc: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Link: https://patch.msgid.link/20250722053121.1145001-1-usama.anjum@collabora.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 32be3ca4cf78b309dfe7ba52fe2d7cc3c23c5634 upstream.

Don't deinitialize and reinitialize the HAL helpers. The dma memory is
deallocated and there is high possibility that we'll not be able to get
the same memory allocated from dma when there is high memory pressure.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.6

Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Cc: stable@vger.kernel.org
Cc: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
Link: https://patch.msgid.link/20250722053121.1145001-1-usama.anjum@collabora.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: airoha: Fix loopback mode configuration for GDM2 port 2025-10-19T14:37:14+00:00 Lorenzo Bianconi lorenzo@kernel.org 2025-10-08T09:27:43+00:00 d8ae3cd5e4051acd376dfd6ceb98a109fc9bef2d [ Upstream commit fea8cdf6738a8b25fccbb7b109b440795a0892cb ] Add missing configuration for loopback mode in airhoha_set_gdm2_loopback routine. Fixes: 9cd451d414f6e ("net: airoha: Add loopback support for GDM2") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20251008-airoha-loopback-mode-fix-v2-1-045694fe7f60@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit fea8cdf6738a8b25fccbb7b109b440795a0892cb ]

Add missing configuration for loopback mode in airhoha_set_gdm2_loopback
routine.

Fixes: 9cd451d414f6e ("net: airoha: Add loopback support for GDM2")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251008-airoha-loopback-mode-fix-v2-1-045694fe7f60@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net: pse-pd: tps23881: Fix current measurement scaling 2025-10-19T14:37:13+00:00 Thomas Wismer thomas.wismer@scs.ch 2025-10-06T20:40:29+00:00 cb71007c4d1610d6fd65470372e266b2d7ed3b57 [ Upstream commit 2c95a756e0cfc19af6d0b32b0c6cf3bada334998 ] The TPS23881 improves on the TPS23880 with current sense resistors reduced from 255 mOhm to 200 mOhm. This has a direct impact on the scaling of the current measurement. However, the latest TPS23881 data sheet from May 2023 still shows the scaling of the TPS23880 model. Fixes: 7f076ce3f1733 ("net: pse-pd: tps23881: Add support for power limit and measurement features") Signed-off-by: Thomas Wismer <thomas.wismer@scs.ch> Acked-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20251006204029.7169-2-thomas@wismer.xyz Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2c95a756e0cfc19af6d0b32b0c6cf3bada334998 ]

The TPS23881 improves on the TPS23880 with current sense resistors reduced
from 255 mOhm to 200 mOhm. This has a direct impact on the scaling of the
current measurement. However, the latest TPS23881 data sheet from May 2023
still shows the scaling of the TPS23880 model.

Fixes: 7f076ce3f1733 ("net: pse-pd: tps23881: Add support for power limit and measurement features")
Signed-off-by: Thomas Wismer <thomas.wismer@scs.ch>
Acked-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://patch.msgid.link/20251006204029.7169-2-thomas@wismer.xyz
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net/mlx5e: Prevent tunnel reformat when tunnel mode not allowed 2025-10-19T14:37:12+00:00 Carolina Jubran cjubran@nvidia.com 2025-10-05T08:29:58+00:00 993c4ba71596c30418ba5a0ddcf4f9c2f431466a [ Upstream commit 22239eb258bc1e6ccdb2d3502fce1cc2b2a88386 ] When configuring IPsec packet offload in tunnel mode, the driver tries to create tunnel reformat objects unconditionally. This is incorrect, because tunnel mode is only permitted under specific encapsulation settings, and that decision is already made when the flow table is created. The offending commit attempted to block this case in the state add path, but the check there happens too late and does not prevent the reformat from being configured. Fix by taking short reservations for both the eswitch mode and the encap at the start of state setup. This preserves the block ordering (mode --> encap) used later: the mode is blocked during RX/TX get, and the encap is blocked during flow-table creation. This lets us fail early if either reservation cannot be obtained, it means a mode transition is underway or a conflicting configuration already owns encap. If both succeed, the flow-table path later takes the ownership and the reservations are released on exit. Fixes: 146c196b60e4 ("net/mlx5e: Create IPsec table with tunnel support only when encap is disabled") Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1759652999-858513-3-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 22239eb258bc1e6ccdb2d3502fce1cc2b2a88386 ]

When configuring IPsec packet offload in tunnel mode, the driver tries
to create tunnel reformat objects unconditionally. This is incorrect,
because tunnel mode is only permitted under specific encapsulation
settings, and that decision is already made when the flow table is
created.

The offending commit attempted to block this case in the state add
path, but the check there happens too late and does not prevent the
reformat from being configured.

Fix by taking short reservations for both the eswitch mode and the
encap at the start of state setup. This preserves the block ordering
(mode --> encap) used later: the mode is blocked during RX/TX get, and
the encap is blocked during flow-table creation. This lets us fail
early if either reservation cannot be obtained, it means a mode
transition is underway or a conflicting configuration already owns
encap. If both succeed, the flow-table path later takes the ownership
and the reservations are released on exit.

Fixes: 146c196b60e4 ("net/mlx5e: Create IPsec table with tunnel support only when encap is disabled")
Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Jianbo Liu <jianbol@nvidia.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/1759652999-858513-3-git-send-email-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net/mlx5: Prevent tunnel mode conflicts between FDB and NIC IPsec tables 2025-10-19T14:37:12+00:00 Carolina Jubran cjubran@nvidia.com 2025-10-05T08:29:57+00:00 b56aee2c3ed5ad6ad97006a1fb21ac4993488abb [ Upstream commit 7593439c13933164f701eed9c83d89358f203469 ] When creating IPsec flow tables with tunnel mode enabled, the driver uses mlx5_eswitch_block_encap() to prevent tunnel encapsulation conflicts across different domains (NIC_RX/NIC_TX and FDB), since the firmware doesn’t allow both at the same time. Currently, the driver attempts to reserve tunnel mode unconditionally for both NIC and FDB IPsec tables. This can lead to conflicting tunnel mode setups, for example, if a flow table was created in the FDB domain with tunnel offload enabled, and we later try to create another one in the NIC, or vice versa. To resolve this, adjust the blocking logic so that tunnel mode is only reserved by NIC flows. This ensures that tunnel offload is exclusively used in either the NIC or the FDB, and avoids unintended offload conflicts. Fixes: 1762f132d542 ("net/mlx5e: Support IPsec packet offload for RX in switchdev mode") Fixes: c6c2bf5db4ea ("net/mlx5e: Support IPsec packet offload for TX in switchdev mode") Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1759652999-858513-2-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 7593439c13933164f701eed9c83d89358f203469 ]

When creating IPsec flow tables with tunnel mode enabled, the driver
uses mlx5_eswitch_block_encap() to prevent tunnel encapsulation
conflicts across different domains (NIC_RX/NIC_TX and FDB), since the
firmware doesn’t allow both at the same time.

Currently, the driver attempts to reserve tunnel mode unconditionally
for both NIC and FDB IPsec tables. This can lead to conflicting tunnel
mode setups, for example, if a flow table was created in the FDB
domain with tunnel offload enabled, and we later try to create another
one in the NIC, or vice versa.

To resolve this, adjust the blocking logic so that tunnel mode is only
reserved by NIC flows. This ensures that tunnel offload is exclusively
used in either the NIC or the FDB, and avoids unintended offload
conflicts.

Fixes: 1762f132d542 ("net/mlx5e: Support IPsec packet offload for RX in switchdev mode")
Fixes: c6c2bf5db4ea ("net/mlx5e: Support IPsec packet offload for TX in switchdev mode")
Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Jianbo Liu <jianbol@nvidia.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/1759652999-858513-2-git-send-email-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net: sparx5/lan969x: fix flooding configuration on bridge join/leave 2025-10-19T14:37:12+00:00 Daniel Machon daniel.machon@microchip.com 2025-10-03T12:35:59+00:00 20883557dc90d95b38e3f1a6ac90514c8c612103 [ Upstream commit c9d1b0b54258ba13b567dd116ead3c7c30cba7d8 ] The sparx5 driver programs UC/MC/BC flooding in sparx5_update_fwd() by unconditionally applying bridge_fwd_mask to all flood PGIDs. Any bridge topology change that triggers sparx5_update_fwd() (for example enslaving another port) therefore reinstalls flooding in hardware for already bridged ports, regardless of their per-port flood flags. This results in clobbering of the flood masks, and desynchronization between software and hardware: the bridge still reports “flood off” for the port, but hardware has flooding enabled due to unconditional PGID reprogramming. Steps to reproduce: $ ip link add br0 type bridge $ ip link set br0 up $ ip link set eth0 master br0 $ ip link set eth0 up $ bridge link set dev eth0 flood off $ ip link set eth1 master br0 $ ip link set eth1 up At this point, flooding is silently re-enabled for eth0. Software still shows “flood off” for eth0, but hardware has flooding enabled. To fix this, flooding is now set explicitly during bridge join/leave, through sparx5_port_attr_bridge_flags(): On bridge join, UC/MC/BC flooding is enabled by default. On bridge leave, UC/MC/BC flooding is disabled. sparx5_update_fwd() no longer touches the flood PGIDs, clobbering the flood masks, and desynchronizing software and hardware. Initialization of the flooding PGIDs have been moved to sparx5_start(). This is required as flooding PGIDs defaults to 0x3fffffff in hardware and the initialization was previously handled in sparx5_update_fwd(), which was removed. With this change, user-configured flooding flags persist across bridge updates and are no longer overridden by sparx5_update_fwd(). Fixes: d6fce5141929 ("net: sparx5: add switching support") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251003-fix-flood-fwd-v1-1-48eb478b2904@microchip.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c9d1b0b54258ba13b567dd116ead3c7c30cba7d8 ]

The sparx5 driver programs UC/MC/BC flooding in sparx5_update_fwd() by
unconditionally applying bridge_fwd_mask to all flood PGIDs. Any bridge
topology change that triggers sparx5_update_fwd() (for example enslaving
another port) therefore reinstalls flooding in hardware for already
bridged ports, regardless of their per-port flood flags.

This results in clobbering of the flood masks, and desynchronization
between software and hardware: the bridge still reports “flood off” for
the port, but hardware has flooding enabled due to unconditional PGID
reprogramming.

Steps to reproduce:

    $ ip link add br0 type bridge
    $ ip link set br0 up
    $ ip link set eth0 master br0
    $ ip link set eth0 up
    $ bridge link set dev eth0 flood off
    $ ip link set eth1 master br0
    $ ip link set eth1 up

At this point, flooding is silently re-enabled for eth0. Software still
shows “flood off” for eth0, but hardware has flooding enabled.

To fix this, flooding is now set explicitly during bridge join/leave,
through sparx5_port_attr_bridge_flags():

    On bridge join, UC/MC/BC flooding is enabled by default.

    On bridge leave, UC/MC/BC flooding is disabled.

    sparx5_update_fwd() no longer touches the flood PGIDs, clobbering
    the flood masks, and desynchronizing software and hardware.

    Initialization of the flooding PGIDs have been moved to
    sparx5_start(). This is required as flooding PGIDs defaults to
    0x3fffffff in hardware and the initialization was previously handled
    in sparx5_update_fwd(), which was removed.

With this change, user-configured flooding flags persist across bridge
updates and are no longer overridden by sparx5_update_fwd().

Fixes: d6fce5141929 ("net: sparx5: add switching support")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20251003-fix-flood-fwd-v1-1-48eb478b2904@microchip.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>