[PATCH iwl-net 00/10] ice: port missing i40e fixes

[PATCH iwl-net 00/10] ice: port missing i40e fixes

[Petr Oros]

This series fixes bugs in ice that have been fixed in i40e, some of them
years ago, but are still present in ice. They were found by going
through the i40e history and checking each fix against the current ice
code.

Patches 3, 6 and 8 have no i40e counterpart. They showed up while
verifying the ports and are kept in the series. Patch 3 was found while
testing patch 2. With the IRQ unwind fixed the netdev still could not be
opened again after the failed ndo_open, so patch 2 alone does not make
that error path recoverable. Patch 6 was found while building a
reproducer for the i40e MAC filter overflow fixes. Those are not part of
this series, because a full switch table on E810 leaves no room for the
promiscuous rule either. Patch 8 was found while checking the i40e PF
reset fixes. It is an ice regression of the poll loop timeout check,
which i40e does correctly.

Every patch was checked on E810 before and after the change. Patches 1,
4, 5 and 6 have plain reproducers, which show UDP tunnel offload lost
after CORER, an always empty default XPS map, VF tx_dropped stuck at
zero and multicast filters silently not programmed. Patches 2, 3, 8, 9
and 10 need conditions the test box does not hit on its own (a failing
request_irq, a hung PFR, a WoL capable port, counters past 2^32) and
were verified with fault injection. Patch 7 was verified by filling the
switch table, with debug prints for the failure analysis.

An LLM was used to go through the i40e history, to write the
reproducers and fault injection hooks and to draft the patches and
changelogs. All of it was reviewed, and every fix was tested on E810 as
described above.

Petr Oros (10):
  ice: replay UDP tunnel ports after a core or global reset
  ice: fix IRQ freeing in ice_vsi_req_irq_msix() error path
  ice: stop the LAN Tx queues when ice_vsi_open() fails
  ice: restore the default XPS map after a netdev TC change
  ice: report VF tx_dropped with tx_errors instead of tx_discards
  ice: keep adding MAC filters after one that already exists
  ice: take the switch rule AQ error from the response descriptor
  ice: detect a PF reset that does not complete
  ice: program multicast magic wake before tearing down the main VSI
  ice: fix unsigned stat widths

 drivers/net/ethernet/intel/ice/ice.h        |  8 ++---
 drivers/net/ethernet/intel/ice/ice_common.c |  2 +-
 drivers/net/ethernet/intel/ice/ice_lib.c    |  6 ++++
 drivers/net/ethernet/intel/ice/ice_main.c   | 36 ++++++++++++++-------
 drivers/net/ethernet/intel/ice/ice_sriov.c  |  2 +-
 drivers/net/ethernet/intel/ice/ice_switch.c | 17 +++++++---
 6 files changed, 49 insertions(+), 22 deletions(-)

-- 
2.55.0

[PATCH iwl-net 01/10] ice: replay UDP tunnel ports after a core or global reset

[Petr Oros]

A CORER, GLOBR or EMPR reloads the DDP package in ice_rebuild() and
ice_init_pkg_hints() clears hw->tnl, so every offloaded VXLAN and GENEVE
port is gone from both the boost TCAM and the driver table. The
udp_tunnel_nic core is never told about it and still considers the ports
programmed, so the Rx tunnel offloads silently stop working after the
reset. With VXLAN port 4789 offloaded, 64 flows that differ only in the
inner headers are spread over all six Rx queues of the test port by
RSS, after a CORER they all land in a single queue, the same as without
the port. Removing the port later trips the WARN_ON() in
ice_destroy_tunnel() because its table entry is no longer valid:

  WARNING: ice_flex_pipe.c:524 at ice_udp_tunnel_unset_port+0x56/0x280 [ice]
  ice 0000:04:00.3 enp4s0f3np3: Error removing UDP tunnel - -5
  ice 0000:04:00.3 enp4s0f3np3: UDP tunnel port sync failed port 4789 type vxlan: -5

Call udp_tunnel_nic_reset_ntf() once the main VSI is rebuilt so the core
programs the ports again. A PF reset keeps the package and the table, so
it is left alone. No rtnl_lock is needed since commit 1ead7501094c
("udp_tunnel: remove rtnl_lock dependency").

i40e fixed the same problem in commit 1f190d936948 ("i40e: Reprogram
port offloads after reset").

Fixes: a4e82a81f573 ("ice: Add support for tunnel offloads")
Assisted-by: LLM
Signed-off-by: Petr Oros <poros@redhat.com>
---
 drivers/net/ethernet/intel/ice/ice_main.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 8c4b0fbc790644..f2121e79fca993 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -7859,8 +7859,11 @@ static void ice_rebuild(struct ice_pf *pf, enum ice_reset_req reset_type)
 		ice_rebuild_arfs(pf);
 	}
 
-	if (vsi && vsi->netdev)
+	if (vsi && vsi->netdev) {
 		netif_device_attach(vsi->netdev);
+		if (reset_type != ICE_RESET_PFR)
+			udp_tunnel_nic_reset_ntf(vsi->netdev);
+	}
 
 	ice_update_pf_netdev_link(pf);
 
-- 
2.55.0

[PATCH iwl-net 02/10] ice: fix IRQ freeing in ice_vsi_req_irq_msix() error path

[Petr Oros]

The vectors are requested with the q_vector as dev_id, but the error
path frees them with &vsi->q_vectors[vector], which is the address of
the array slot. devm_free_irq() finds no matching devres entry, warns
and leaves the IRQ requested. The unwind also tries to free vectors that
the request loop skipped because they have no rings.

Forcing request_irq to fail on the fourth vector during ndo_open gives:

  ice 0000:04:00.2 enp4s0f2np2: MSIX request_irq failed, error: -16
  WARNING: kernel/irq/devres.c:191 at devm_free_irq+0x30/0x40
  WARNING: kernel/irq/devres.c:191 at devm_free_irq+0x30/0x40
  WARNING: kernel/irq/devres.c:191 at devm_free_irq+0x30/0x40

and the three IRQs stay registered in /proc/interrupts while the
interface is down.

Pass the q_vector as dev_id and skip the vectors without rings, which
the request loop never requested.

i40e fixed the same mistake in commit 915470e1b44e ("i40e: fix IRQ
freeing in i40e_vsi_request_irq_msix error path").

Fixes: cdedef59deb0 ("ice: Configure VSIs for Tx/Rx")
Assisted-by: LLM
Signed-off-by: Petr Oros <poros@redhat.com>
---
 drivers/net/ethernet/intel/ice/ice_main.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index f2121e79fca993..d246cde36ae726 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -2582,8 +2582,12 @@ static int ice_vsi_req_irq_msix(struct ice_vsi *vsi, char *basename)
 
 free_q_irqs:
 	while (vector--) {
-		irq_num = vsi->q_vectors[vector]->irq.virq;
-		devm_free_irq(dev, irq_num, &vsi->q_vectors[vector]);
+		struct ice_q_vector *q_vector = vsi->q_vectors[vector];
+
+		if (!q_vector->tx.tx_ring && !q_vector->rx.rx_ring)
+			continue;
+
+		devm_free_irq(dev, q_vector->irq.virq, q_vector);
 	}
 	return err;
 }
-- 
2.55.0

[PATCH iwl-net 03/10] ice: stop the LAN Tx queues when ice_vsi_open() fails

[Petr Oros]

ice_vsi_cfg_lan() adds the LAN (and XDP) Tx queues to the scheduler and
enables them in hardware. If anything after it fails in ice_vsi_open(),
for example requesting the MSI-X vectors, the error path only frees the
ring memory and leaves the queues configured. Every following open then
fails to add the same queues again and the netdev can not be brought up
until the driver is reloaded:

  ice 0000:04:00.2: Failed to set LAN Tx queue context, error: -5
  ice 0000:04:00.2 enp4s0f2np2: Failed to open VSI 0x0010 on switch 0x0002

Stop the Tx queues on the error paths that run after ice_vsi_cfg_lan().
The ice_up_complete() failure path already does it through ice_down(),
so let it skip the new step.

There is no i40e counterpart of this fix, i40e does not add its Tx
queues through the admin queue. It was found while verifying the
previous patch. With the IRQ unwind fixed the warnings were gone, but
the netdev still could not be opened again after the forced
request_irq failure.

Fixes: cdedef59deb0 ("ice: Configure VSIs for Tx/Rx")
Assisted-by: LLM
Signed-off-by: Petr Oros <poros@redhat.com>
---
 drivers/net/ethernet/intel/ice/ice_main.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index d246cde36ae726..e62a8f544345a3 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -7561,13 +7561,13 @@ int ice_vsi_open(struct ice_vsi *vsi)
 
 	err = ice_vsi_cfg_lan(vsi);
 	if (err)
-		goto err_setup_rx;
+		goto err_stop_tx;
 
 	snprintf(int_name, sizeof(int_name) - 1, "%s-%s",
 		 dev_driver_string(ice_pf_to_dev(pf)), vsi->netdev->name);
 	err = ice_vsi_req_irq_msix(vsi, int_name);
 	if (err)
-		goto err_setup_rx;
+		goto err_stop_tx;
 
 	if (bitmap_empty(pf->txtime_txqs, pf->max_pf_txqs))
 		ice_vsi_cfg_netdev_tc(vsi, vsi->tc_cfg.ena_tc);
@@ -7593,8 +7593,14 @@ int ice_vsi_open(struct ice_vsi *vsi)
 
 err_up_complete:
 	ice_down(vsi);
+	ice_vsi_free_irq(vsi);
+	goto err_setup_rx;
 err_set_qs:
 	ice_vsi_free_irq(vsi);
+err_stop_tx:
+	ice_vsi_stop_lan_tx_rings(vsi, ICE_NO_RESET, 0);
+	if (vsi->xdp_rings)
+		ice_vsi_stop_xdp_tx_rings(vsi);
 err_setup_rx:
 	ice_vsi_free_rx_rings(vsi);
 err_setup_tx:
-- 
2.55.0

[PATCH iwl-net 04/10] ice: restore the default XPS map after a netdev TC change

[Petr Oros]

ice_cfg_xps_tx_ring() programs the default XPS map only once per ring,
guarded by ICE_TX_XPS_INIT_DONE. netdev_reset_tc() and
netdev_set_num_tc() drop all XPS maps of the device, but the bit is never
cleared, so the default map is not programmed again.

Since commit 122045ca7704 ("ice: config netdev tc before setting queues
number") ice_vsi_open() calls ice_vsi_cfg_netdev_tc() after the Tx
queues have been configured, so the map is wiped right after it was
written on every open and stays empty:

  # cat /sys/class/net/enp4s0f0np0/queues/tx-*/xps_cpus
  0000
  0000
  ...

A DCB reconfiguration ends the same way through ice_vsi_cfg_tc().

Clear ICE_TX_XPS_INIT_DONE in ice_vsi_cfg_netdev_tc(), which resets the
netdev TC state, and configure the netdev TCs in ice_vsi_open() before
the Tx queues so the default map is applied after the reset, not before
it.

i40e fixed the same stale bit in commit 82e0572b2302 ("i40e: Fix not
setting default xps_cpus after reset").

Fixes: 122045ca7704 ("ice: config netdev tc before setting queues number")
Assisted-by: LLM
Signed-off-by: Petr Oros <poros@redhat.com>
---
 drivers/net/ethernet/intel/ice/ice_lib.c  | 6 ++++++
 drivers/net/ethernet/intel/ice/ice_main.c | 6 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
index 5e183314e0d792..416e2d6a6f1709 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -3218,6 +3218,12 @@ void ice_vsi_cfg_netdev_tc(struct ice_vsi *vsi, u8 ena_tc)
 	if (vsi->type == ICE_VSI_CHNL)
 		return;
 
+	if (vsi->tx_rings)
+		ice_for_each_txq(vsi, i)
+			if (vsi->tx_rings[i])
+				clear_bit(ICE_TX_XPS_INIT_DONE,
+					  vsi->tx_rings[i]->xps_state);
+
 	if (!ena_tc) {
 		netdev_reset_tc(netdev);
 		return;
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index e62a8f544345a3..8a21f87eb6ca21 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -7559,6 +7559,9 @@ int ice_vsi_open(struct ice_vsi *vsi)
 	if (err)
 		goto err_setup_rx;
 
+	if (bitmap_empty(pf->txtime_txqs, pf->max_pf_txqs))
+		ice_vsi_cfg_netdev_tc(vsi, vsi->tc_cfg.ena_tc);
+
 	err = ice_vsi_cfg_lan(vsi);
 	if (err)
 		goto err_stop_tx;
@@ -7569,9 +7572,6 @@ int ice_vsi_open(struct ice_vsi *vsi)
 	if (err)
 		goto err_stop_tx;
 
-	if (bitmap_empty(pf->txtime_txqs, pf->max_pf_txqs))
-		ice_vsi_cfg_netdev_tc(vsi, vsi->tc_cfg.ena_tc);
-
 	if (vsi->type == ICE_VSI_PF || vsi->type == ICE_VSI_SF) {
 		/* Notify the stack of the actual queue counts. */
 		err = netif_set_real_num_tx_queues(vsi->netdev, vsi->num_txq);
-- 
2.55.0

[PATCH iwl-net 05/10] ice: report VF tx_dropped with tx_errors instead of tx_discards

[Petr Oros]

ice_get_vf_stats() fills tx_dropped from eth_stats.tx_discards, which
ice_update_eth_stats() never updates because the GLV_TDPC register it
would come from is not implemented in E810 hardware. The Tx drops of a
VF, such as switch drops on an anti spoof violation, malicious driver
drops or TTL expiry, are counted by GLV_TEPC into eth_stats.tx_errors
instead, so the VF always reports zero dropped packets.

With spoof checking on, a VF sending 60 valid frames and 30 frames with
a forged source MAC shows:

  vf 0 ... spoof checking on, link-state auto, trust off
    TX: bytes  packets   dropped
          3600       60        0

Report tx_errors as tx_dropped, the VF stats have no separate error
field. With the change the same test reports 30 dropped packets.

i40e fixed the same issue in commit 50b2af451597 ("i40e: report VF
tx_dropped with tx_errors instead of tx_discards").

Fixes: 730fdea40bef ("ice: implement VF stats NDO")
Assisted-by: LLM
Signed-off-by: Petr Oros <poros@redhat.com>
---
 drivers/net/ethernet/intel/ice/ice_sriov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index b21279f0f5f1e1..8faddf8ba0d523 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -1640,7 +1640,7 @@ int ice_get_vf_stats(struct net_device *netdev, int vf_id,
 	vf_stats->broadcast  = stats->rx_broadcast;
 	vf_stats->multicast  = stats->rx_multicast;
 	vf_stats->rx_dropped = stats->rx_discards;
-	vf_stats->tx_dropped = stats->tx_discards;
+	vf_stats->tx_dropped = stats->tx_errors;
 
 out_put_vf:
 	ice_put_vf(vf);
-- 
2.55.0

[PATCH iwl-net 06/10] ice: keep adding MAC filters after one that already exists

[Petr Oros]

ice_add_mac() returns as soon as one entry of the list fails, including
-EEXIST for a filter that is already programmed for the VSI. The rest of
the list is never added. ice_vsi_sync_fltr() treats -EEXIST as success,
so the skipped addresses are considered synced and their traffic is
dropped until they are removed and added again.

In a test that adds 50 multicast addresses to a port in a burst with
the port MAC address in the middle of it, 19 of them were left without
a filter.

Continue with the next entry on -EEXIST and report it once the whole
list has been processed. Other errors still stop the loop.

There is no i40e counterpart of this fix, i40e keeps its MAC filters in
a hash with a state per filter and syncs them differently. It was found
while building a reproducer for the MAC filter overflow handling that
i40e fixed in commit e58872398684 ("i40e: fix disabling overflow
promiscuous mode") and commit 7363115efb04 ("i40e: do not force filter
failure in overflow promiscuous").

Commit bbb968e8b34c ("ice: Fix issues updating VSI MAC filters") dealt
with the same problem for the VF MAC filter requests, which are now
added one by one with -EEXIST tolerated, but left ice_add_mac() and the
PF filter sync as they were.

Fixes: 89f3e4a5b762 ("ice: Do not bail out when filter already exists")
Assisted-by: LLM
Signed-off-by: Petr Oros <poros@redhat.com>
---
 drivers/net/ethernet/intel/ice/ice_switch.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c
index 2ee5cb6ffdab1f..239d4d9633baa6 100644
--- a/drivers/net/ethernet/intel/ice/ice_switch.c
+++ b/drivers/net/ethernet/intel/ice/ice_switch.c
@@ -3659,7 +3659,9 @@ int ice_add_mac(struct ice_hw *hw, struct list_head *m_list)
 
 		m_list_itr->status = ice_add_rule_internal(hw, ICE_SW_LKUP_MAC,
 							   m_list_itr);
-		if (m_list_itr->status)
+		if (m_list_itr->status == -EEXIST)
+			status = -EEXIST;
+		else if (m_list_itr->status)
 			return m_list_itr->status;
 	}
 
-- 
2.55.0

[PATCH iwl-net 07/10] ice: take the switch rule AQ error from the response descriptor

[Petr Oros]

ice_aq_sw_rules() decides whether a rule removal failed with ENOENT by
reading hw->adminq.sq_last_status after ice_aq_send_cmd() returned. That
field is shared by every admin queue user and is only stable while the
send queue lock is held. Another AQ command completing in between can
overwrite it, so a failed removal is reported as a generic error, and a
successful one can even be turned into -ENOENT, because the check is
not limited to the failure case. A caller that sees -ENOENT keeps its
rule bookkeeping while the rule is gone from the hardware.

ice_vsi_sync_fltr() has the same problem with ENOSPC. It checks
sq_last_status only after it has freed the list of filters it tried to
add. Every entry is a separate devres allocation, so freeing a list of
thousands of entries takes seconds, and by then the value usually
belongs to a different command, so the MAC filter overflow handling is
never entered. With debug prints of the error and sq_last_status added
to both places:

  ice_aq_sw_rules: opc 0x2a0 status -5 aq 16
  ice 0000:04:00.0 enp4s0f0np0: Failed to add MAC filters err -5 aq 0

Use the retval of the descriptor that ice_aq_send_cmd() copies back,
only when the command failed, translate ENOSPC on add to -ENOSPC and
let ice_vsi_sync_fltr() check the return code instead of
sq_last_status.

i40e fixed the same kind of race in commit 53a9e346e159 ("i40e: Fix race
condition while adding/deleting MAC/VLAN filters").

Fixes: ca1fdb885e5f ("ice: return correct error code from ice_aq_sw_rules")
Assisted-by: LLM
Signed-off-by: Petr Oros <poros@redhat.com>
---
 drivers/net/ethernet/intel/ice/ice_main.c   |  4 +---
 drivers/net/ethernet/intel/ice/ice_switch.c | 13 ++++++++++---
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 8a21f87eb6ca21..ceb9fec2af21e7 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -396,8 +396,6 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi)
 	struct device *dev = ice_pf_to_dev(vsi->back);
 	struct net_device *netdev = vsi->netdev;
 	bool promisc_forced_on = false;
-	struct ice_pf *pf = vsi->back;
-	struct ice_hw *hw = &pf->hw;
 	u32 changed_flags = 0;
 	int err;
 
@@ -450,7 +448,7 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi)
 		 * should go into promiscuous mode. There should be some
 		 * space reserved for promiscuous filters.
 		 */
-		if (hw->adminq.sq_last_status == LIBIE_AQ_RC_ENOSPC &&
+		if (err == -ENOSPC &&
 		    !test_and_set_bit(ICE_FLTR_OVERFLOW_PROMISC,
 				      vsi->state)) {
 			promisc_forced_on = true;
diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c
index 239d4d9633baa6..ae96a2003d5c5e 100644
--- a/drivers/net/ethernet/intel/ice/ice_switch.c
+++ b/drivers/net/ethernet/intel/ice/ice_switch.c
@@ -1959,9 +1959,16 @@ ice_aq_sw_rules(struct ice_hw *hw, void *rule_list, u16 rule_list_sz,
 	desc.flags |= cpu_to_le16(LIBIE_AQ_FLAG_RD);
 	cmd->num_rules_fltr_entry_index = cpu_to_le16(num_rules);
 	status = ice_aq_send_cmd(hw, &desc, rule_list, rule_list_sz, cd);
-	if (opc != ice_aqc_opc_add_sw_rules &&
-	    hw->adminq.sq_last_status == LIBIE_AQ_RC_ENOENT)
-		status = -ENOENT;
+	if (status) {
+		enum libie_aq_err aq_err = le16_to_cpu(desc.retval) & 0xff;
+
+		if (opc != ice_aqc_opc_add_sw_rules &&
+		    aq_err == LIBIE_AQ_RC_ENOENT)
+			status = -ENOENT;
+		else if (opc == ice_aqc_opc_add_sw_rules &&
+			 aq_err == LIBIE_AQ_RC_ENOSPC)
+			status = -ENOSPC;
+	}
 
 	if (!status) {
 		if (opc == ice_aqc_opc_add_sw_rules)
-- 
2.55.0

[PATCH iwl-net 08/10] ice: detect a PF reset that does not complete

[Petr Oros]

ice_pf_reset() polls PFGEN_CTRL.PFSWR for up to
ICE_GLOBAL_CFG_LOCK_TIMEOUT + ICE_PF_RESET_WAIT_COUNT iterations, but
the timeout check after the loop still compares the counter with
ICE_PF_RESET_WAIT_COUNT alone. When the reset never completes the loop
ends with cnt == 5300, the check does not match and the function
returns success with PFSWR still set. A reset that completes just when
the counter reaches ICE_PF_RESET_WAIT_COUNT is reported as a failure
instead.

Check the PFSWR bit read last instead of the loop counter, the same
way i40e_pf_reset() does after its poll loop.

Fixes: c9a12d6d2091 ("ice: Increase timeout after PFR")
Assisted-by: LLM
Signed-off-by: Petr Oros <poros@redhat.com>
---
 drivers/net/ethernet/intel/ice/ice_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
index 04633103e3e610..0ffd6b5b81239e 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.c
+++ b/drivers/net/ethernet/intel/ice/ice_common.c
@@ -1291,7 +1291,7 @@ static int ice_pf_reset(struct ice_hw *hw)
 		mdelay(1);
 	}
 
-	if (cnt == ICE_PF_RESET_WAIT_COUNT) {
+	if (reg & PFGEN_CTRL_PFSWR_M) {
 		ice_debug(hw, ICE_DBG_INIT, "PF reset polling failed to complete.\n");
 		return -EIO;
 	}
-- 
2.55.0

[PATCH iwl-net 09/10] ice: program multicast magic wake before tearing down the main VSI

[Petr Oros]

Since commit 5b246e533d01 ("ice: split probe into smaller functions")
ice_remove() calls ice_setup_mc_magic_wake() after ice_deinit(), which
frees pf->vsi. ice_get_main_vsi() then returns NULL and the function
returns before it sends the Manage MAC Write command, so multicast magic
packet wake and keeping a locally administered address across the PF
reset are never set up on shutdown with WoL enabled.

Program it before the netdev and the VSIs are torn down, as it was done
before that commit, so the current netdev address is used again.

i40e had a similar problem, where the multicast magic wake setup ran
after the admin queue had already been shut down, and fixed it in
commit e661414c98df ("i40e: Remove duplicated prepare call in
i40e_shutdown").

Fixes: 5b246e533d01 ("ice: split probe into smaller functions")
Assisted-by: LLM
Signed-off-by: Petr Oros <poros@redhat.com>
---
 drivers/net/ethernet/intel/ice/ice_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index ceb9fec2af21e7..a885b3e0baaa5d 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -5456,6 +5456,8 @@ static void ice_remove(struct pci_dev *pdev)
 	if (!ice_is_safe_mode(pf))
 		ice_remove_arfs(pf);
 
+	ice_setup_mc_magic_wake(pf);
+
 	devl_lock(priv_to_devlink(pf));
 	ice_dealloc_all_dynamic_ports(pf);
 	ice_deinit_devlink(pf);
@@ -5466,7 +5468,6 @@ static void ice_remove(struct pci_dev *pdev)
 	ice_deinit(pf);
 	ice_vsi_release_all(pf);
 
-	ice_setup_mc_magic_wake(pf);
 	ice_set_wake(pf);
 
 	ice_adapter_put(pdev);
-- 
2.55.0

[PATCH iwl-net 10/10] ice: fix unsigned stat widths

[Petr Oros]

tx_restart, tx_busy, rx_buf_failed and rx_page_failed in struct ice_vsi
are u32, but ice_update_vsi_ring_stats() fills them with sums of the
64-bit per ring counters. The values are truncated and the ethtool
statistics exported from them wrap at 2^32 while the ring counters keep
counting.

Make them u64 like tx_linearize next to them.

i40e fixed the same truncation in commit 3b8428b84539 ("i40e: fix
unsigned stat widths").

Fixes: fcea6f3da546 ("ice: Add stats and ethtool support")
Assisted-by: LLM
Signed-off-by: Petr Oros <poros@redhat.com>
---
 drivers/net/ethernet/intel/ice/ice.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
index 6c596e5a315175..a985b81efbe2d6 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -344,10 +344,10 @@ struct ice_vsi {
 	u64 tx_linearize;
 	DECLARE_BITMAP(state, ICE_VSI_STATE_NBITS);
 	unsigned int current_netdev_flags;
-	u32 tx_restart;
-	u32 tx_busy;
-	u32 rx_buf_failed;
-	u32 rx_page_failed;
+	u64 tx_restart;
+	u64 tx_busy;
+	u64 rx_buf_failed;
+	u64 rx_page_failed;
 	u16 num_q_vectors;
 	/* tell if only dynamic irq allocation is allowed */
 	bool irq_dyn_alloc;
-- 
2.55.0

RE: [PATCH iwl-net 10/10] ice: fix unsigned stat widths

[Loktionov, Aleksandr]

> -----Original Message-----
> From: Petr Oros <poros@redhat.com>
> Sent: Friday, October 2, 2026 3:08 PM
> To: netdev@vger.kernel.org
> Cc: Oros, Petr <poros@redhat.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@kernel.org>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Lobakin, Aleksander
> <aleksander.lobakin@intel.com>; Alexei Starovoitov <ast@kernel.org>;
> Daniel Borkmann <daniel@iogearbox.net>; Jesper Dangaard Brouer
> <hawk@kernel.org>; John Fastabend <john.fastabend@gmail.com>;
> Stanislav Fomichev <sdf@fomichev.me>; Henry Tieman
> <henry.w.tieman@intel.com>; Anirudh Venkataramanan
> <anirudh.venkataramanan@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Jesse Brandeburg
> <jbrandeb@kernel.org>; Preethi Banala <preethi.banala@intel.com>;
> Kiran Patil <kiran.patil@intel.com>; Dan Nowlin
> <dan.nowlin@intel.com>; Stephen Hemminger
> <stephen@networkplumber.org>; intel-wired-lan@lists.osuosl.org; linux-
> kernel@vger.kernel.org; bpf@vger.kernel.org
> Subject: [PATCH iwl-net 10/10] ice: fix unsigned stat widths
> 
> tx_restart, tx_busy, rx_buf_failed and rx_page_failed in struct
> ice_vsi are u32, but ice_update_vsi_ring_stats() fills them with sums
> of the 64-bit per ring counters. The values are truncated and the
> ethtool statistics exported from them wrap at 2^32 while the ring
> counters keep counting.
> 
> Make them u64 like tx_linearize next to them.
> 
> i40e fixed the same truncation in commit 3b8428b84539 ("i40e: fix
> unsigned stat widths").
> 
> Fixes: fcea6f3da546 ("ice: Add stats and ethtool support")
> Assisted-by: LLM
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
>  drivers/net/ethernet/intel/ice/ice.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice.h
> b/drivers/net/ethernet/intel/ice/ice.h
> index 6c596e5a315175..a985b81efbe2d6 100644
> --- a/drivers/net/ethernet/intel/ice/ice.h
> +++ b/drivers/net/ethernet/intel/ice/ice.h
> @@ -344,10 +344,10 @@ struct ice_vsi {
>  	u64 tx_linearize;
>  	DECLARE_BITMAP(state, ICE_VSI_STATE_NBITS);
>  	unsigned int current_netdev_flags;
> -	u32 tx_restart;
> -	u32 tx_busy;
> -	u32 rx_buf_failed;
> -	u32 rx_page_failed;
> +	u64 tx_restart;
> +	u64 tx_busy;
> +	u64 rx_buf_failed;
> +	u64 rx_page_failed;
>  	u16 num_q_vectors;
>  	/* tell if only dynamic irq allocation is allowed */
>  	bool irq_dyn_alloc;
> --
> 2.55.0

Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Re: [PATCH iwl-net 01/10] ice: replay UDP tunnel ports after a core or global reset

[Ivan Vecera]

On October 2, 2026 3:07:43 PM GMT+02:00, Petr Oros <poros@redhat.com> wrote:
>A CORER, GLOBR or EMPR reloads the DDP package in ice_rebuild() and
>ice_init_pkg_hints() clears hw->tnl, so every offloaded VXLAN and GENEVE
>port is gone from both the boost TCAM and the driver table. The
>udp_tunnel_nic core is never told about it and still considers the ports
>programmed, so the Rx tunnel offloads silently stop working after the
>reset. With VXLAN port 4789 offloaded, 64 flows that differ only in the
>inner headers are spread over all six Rx queues of the test port by
>RSS, after a CORER they all land in a single queue, the same as without
>the port. Removing the port later trips the WARN_ON() in
>ice_destroy_tunnel() because its table entry is no longer valid:
>
>  WARNING: ice_flex_pipe.c:524 at ice_udp_tunnel_unset_port+0x56/0x280 [ice]
>  ice 0000:04:00.3 enp4s0f3np3: Error removing UDP tunnel - -5
>  ice 0000:04:00.3 enp4s0f3np3: UDP tunnel port sync failed port 4789 type vxlan: -5
>
>Call udp_tunnel_nic_reset_ntf() once the main VSI is rebuilt so the core
>programs the ports again. A PF reset keeps the package and the table, so
>it is left alone. No rtnl_lock is needed since commit 1ead7501094c
>("udp_tunnel: remove rtnl_lock dependency").
>
>i40e fixed the same problem in commit 1f190d936948 ("i40e: Reprogram
>port offloads after reset").
>
>Fixes: a4e82a81f573 ("ice: Add support for tunnel offloads")
>Assisted-by: LLM
>Signed-off-by: Petr Oros <poros@redhat.com>
>---
> drivers/net/ethernet/intel/ice/ice_main.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
>index 8c4b0fbc790644..f2121e79fca993 100644
>--- a/drivers/net/ethernet/intel/ice/ice_main.c
>+++ b/drivers/net/ethernet/intel/ice/ice_main.c
>@@ -7859,8 +7859,11 @@ static void ice_rebuild(struct ice_pf *pf, enum ice_reset_req reset_type)
> 		ice_rebuild_arfs(pf);
> 	}
> 
>-	if (vsi && vsi->netdev)
>+	if (vsi && vsi->netdev) {
> 		netif_device_attach(vsi->netdev);
>+		if (reset_type != ICE_RESET_PFR)
>+			udp_tunnel_nic_reset_ntf(vsi->netdev);
>+	}
> 
> 	ice_update_pf_netdev_link(pf);
> 

Reviewed-by: Ivan Vecera <ivecera@redhat.com>

Re: [PATCH iwl-net 02/10] ice: fix IRQ freeing in ice_vsi_req_irq_msix() error path

[Ivan Vecera]

On October 2, 2026 3:07:44 PM GMT+02:00, Petr Oros <poros@redhat.com> wrote:
>The vectors are requested with the q_vector as dev_id, but the error
>path frees them with &vsi->q_vectors[vector], which is the address of
>the array slot. devm_free_irq() finds no matching devres entry, warns
>and leaves the IRQ requested. The unwind also tries to free vectors that
>the request loop skipped because they have no rings.
>
>Forcing request_irq to fail on the fourth vector during ndo_open gives:
>
>  ice 0000:04:00.2 enp4s0f2np2: MSIX request_irq failed, error: -16
>  WARNING: kernel/irq/devres.c:191 at devm_free_irq+0x30/0x40
>  WARNING: kernel/irq/devres.c:191 at devm_free_irq+0x30/0x40
>  WARNING: kernel/irq/devres.c:191 at devm_free_irq+0x30/0x40
>
>and the three IRQs stay registered in /proc/interrupts while the
>interface is down.
>
>Pass the q_vector as dev_id and skip the vectors without rings, which
>the request loop never requested.
>
>i40e fixed the same mistake in commit 915470e1b44e ("i40e: fix IRQ
>freeing in i40e_vsi_request_irq_msix error path").
>
>Fixes: cdedef59deb0 ("ice: Configure VSIs for Tx/Rx")
>Assisted-by: LLM
>Signed-off-by: Petr Oros <poros@redhat.com>
>---
> drivers/net/ethernet/intel/ice/ice_main.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
>index f2121e79fca993..d246cde36ae726 100644
>--- a/drivers/net/ethernet/intel/ice/ice_main.c
>+++ b/drivers/net/ethernet/intel/ice/ice_main.c
>@@ -2582,8 +2582,12 @@ static int ice_vsi_req_irq_msix(struct ice_vsi *vsi, char *basename)
> 
> free_q_irqs:
> 	while (vector--) {
>-		irq_num = vsi->q_vectors[vector]->irq.virq;
>-		devm_free_irq(dev, irq_num, &vsi->q_vectors[vector]);
>+		struct ice_q_vector *q_vector = vsi->q_vectors[vector];
>+
>+		if (!q_vector->tx.tx_ring && !q_vector->rx.rx_ring)
>+			continue;
>+
>+		devm_free_irq(dev, q_vector->irq.virq, q_vector);
> 	}
> 	return err;
> }

Reviewed-by: Ivan Vecera <ivecera@redhat.com>

Re: [PATCH iwl-net 03/10] ice: stop the LAN Tx queues when ice_vsi_open() fails

[Ivan Vecera]

On October 2, 2026 3:07:45 PM GMT+02:00, Petr Oros <poros@redhat.com> wrote:
>ice_vsi_cfg_lan() adds the LAN (and XDP) Tx queues to the scheduler and
>enables them in hardware. If anything after it fails in ice_vsi_open(),
>for example requesting the MSI-X vectors, the error path only frees the
>ring memory and leaves the queues configured. Every following open then
>fails to add the same queues again and the netdev can not be brought up
>until the driver is reloaded:
>
>  ice 0000:04:00.2: Failed to set LAN Tx queue context, error: -5
>  ice 0000:04:00.2 enp4s0f2np2: Failed to open VSI 0x0010 on switch 0x0002
>
>Stop the Tx queues on the error paths that run after ice_vsi_cfg_lan().
>The ice_up_complete() failure path already does it through ice_down(),
>so let it skip the new step.
>
>There is no i40e counterpart of this fix, i40e does not add its Tx
>queues through the admin queue. It was found while verifying the
>previous patch. With the IRQ unwind fixed the warnings were gone, but
>the netdev still could not be opened again after the forced
>request_irq failure.
>
>Fixes: cdedef59deb0 ("ice: Configure VSIs for Tx/Rx")
>Assisted-by: LLM

Which one?

Otherwise...

Reviewed-by: Ivan Vecera <ivecera@redhat.com>


>Signed-off-by: Petr Oros <poros@redhat.com>
>---
> drivers/net/ethernet/intel/ice/ice_main.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
>index d246cde36ae726..e62a8f544345a3 100644
>--- a/drivers/net/ethernet/intel/ice/ice_main.c
>+++ b/drivers/net/ethernet/intel/ice/ice_main.c
>@@ -7561,13 +7561,13 @@ int ice_vsi_open(struct ice_vsi *vsi)
> 
> 	err = ice_vsi_cfg_lan(vsi);
> 	if (err)
>-		goto err_setup_rx;
>+		goto err_stop_tx;
> 
> 	snprintf(int_name, sizeof(int_name) - 1, "%s-%s",
> 		 dev_driver_string(ice_pf_to_dev(pf)), vsi->netdev->name);
> 	err = ice_vsi_req_irq_msix(vsi, int_name);
> 	if (err)
>-		goto err_setup_rx;
>+		goto err_stop_tx;
> 
> 	if (bitmap_empty(pf->txtime_txqs, pf->max_pf_txqs))
> 		ice_vsi_cfg_netdev_tc(vsi, vsi->tc_cfg.ena_tc);
>@@ -7593,8 +7593,14 @@ int ice_vsi_open(struct ice_vsi *vsi)
> 
> err_up_complete:
> 	ice_down(vsi);
>+	ice_vsi_free_irq(vsi);
>+	goto err_setup_rx;
> err_set_qs:
> 	ice_vsi_free_irq(vsi);
>+err_stop_tx:
>+	ice_vsi_stop_lan_tx_rings(vsi, ICE_NO_RESET, 0);
>+	if (vsi->xdp_rings)
>+		ice_vsi_stop_xdp_tx_rings(vsi);
> err_setup_rx:
> 	ice_vsi_free_rx_rings(vsi);
> err_setup_tx:

Re: [PATCH iwl-net 04/10] ice: restore the default XPS map after a netdev TC change

[Ivan Vecera]

On October 2, 2026 3:07:46 PM GMT+02:00, Petr Oros <poros@redhat.com> wrote:
>ice_cfg_xps_tx_ring() programs the default XPS map only once per ring,
>guarded by ICE_TX_XPS_INIT_DONE. netdev_reset_tc() and
>netdev_set_num_tc() drop all XPS maps of the device, but the bit is never
>cleared, so the default map is not programmed again.
>
>Since commit 122045ca7704 ("ice: config netdev tc before setting queues
>number") ice_vsi_open() calls ice_vsi_cfg_netdev_tc() after the Tx
>queues have been configured, so the map is wiped right after it was
>written on every open and stays empty:
>
>  # cat /sys/class/net/enp4s0f0np0/queues/tx-*/xps_cpus
>  0000
>  0000
>  ...
>
>A DCB reconfiguration ends the same way through ice_vsi_cfg_tc().
>
>Clear ICE_TX_XPS_INIT_DONE in ice_vsi_cfg_netdev_tc(), which resets the
>netdev TC state, and configure the netdev TCs in ice_vsi_open() before
>the Tx queues so the default map is applied after the reset, not before
>it.
>
>i40e fixed the same stale bit in commit 82e0572b2302 ("i40e: Fix not
>setting default xps_cpus after reset").
>
>Fixes: 122045ca7704 ("ice: config netdev tc before setting queues number")
>Assisted-by: LLM
>Signed-off-by: Petr Oros <poros@redhat.com>
>---
> drivers/net/ethernet/intel/ice/ice_lib.c  | 6 ++++++
> drivers/net/ethernet/intel/ice/ice_main.c | 6 +++---
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
>index 5e183314e0d792..416e2d6a6f1709 100644
>--- a/drivers/net/ethernet/intel/ice/ice_lib.c
>+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
>@@ -3218,6 +3218,12 @@ void ice_vsi_cfg_netdev_tc(struct ice_vsi *vsi, u8 ena_tc)
> 	if (vsi->type == ICE_VSI_CHNL)
> 		return;
> 
>+	if (vsi->tx_rings)
>+		ice_for_each_txq(vsi, i)
>+			if (vsi->tx_rings[i])
>+				clear_bit(ICE_TX_XPS_INIT_DONE,
>+					  vsi->tx_rings[i]->xps_state);
>+
> 	if (!ena_tc) {
> 		netdev_reset_tc(netdev);
> 		return;
>diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
>index e62a8f544345a3..8a21f87eb6ca21 100644
>--- a/drivers/net/ethernet/intel/ice/ice_main.c
>+++ b/drivers/net/ethernet/intel/ice/ice_main.c
>@@ -7559,6 +7559,9 @@ int ice_vsi_open(struct ice_vsi *vsi)
> 	if (err)
> 		goto err_setup_rx;
> 
>+	if (bitmap_empty(pf->txtime_txqs, pf->max_pf_txqs))
>+		ice_vsi_cfg_netdev_tc(vsi, vsi->tc_cfg.ena_tc);
>+
> 	err = ice_vsi_cfg_lan(vsi);
> 	if (err)
> 		goto err_stop_tx;
>@@ -7569,9 +7572,6 @@ int ice_vsi_open(struct ice_vsi *vsi)
> 	if (err)
> 		goto err_stop_tx;
> 
>-	if (bitmap_empty(pf->txtime_txqs, pf->max_pf_txqs))
>-		ice_vsi_cfg_netdev_tc(vsi, vsi->tc_cfg.ena_tc);
>-
> 	if (vsi->type == ICE_VSI_PF || vsi->type == ICE_VSI_SF) {
> 		/* Notify the stack of the actual queue counts. */
> 		err = netif_set_real_num_tx_queues(vsi->netdev, vsi->num_txq);

Reviewed-by: Ivan Vecera <ivecera@redhat.com>

Re: [PATCH iwl-net 05/10] ice: report VF tx_dropped with tx_errors instead of tx_discards

[Ivan Vecera]

On October 2, 2026 3:07:47 PM GMT+02:00, Petr Oros <poros@redhat.com> wrote:
>ice_get_vf_stats() fills tx_dropped from eth_stats.tx_discards, which
>ice_update_eth_stats() never updates because the GLV_TDPC register it
>would come from is not implemented in E810 hardware. The Tx drops of a
>VF, such as switch drops on an anti spoof violation, malicious driver
>drops or TTL expiry, are counted by GLV_TEPC into eth_stats.tx_errors
>instead, so the VF always reports zero dropped packets.
>
>With spoof checking on, a VF sending 60 valid frames and 30 frames with
>a forged source MAC shows:
>
>  vf 0 ... spoof checking on, link-state auto, trust off
>    TX: bytes  packets   dropped
>          3600       60        0
>
>Report tx_errors as tx_dropped, the VF stats have no separate error
>field. With the change the same test reports 30 dropped packets.
>
>i40e fixed the same issue in commit 50b2af451597 ("i40e: report VF
>tx_dropped with tx_errors instead of tx_discards").
>
>Fixes: 730fdea40bef ("ice: implement VF stats NDO")
>Assisted-by: LLM
>Signed-off-by: Petr Oros <poros@redhat.com>
>---
> drivers/net/ethernet/intel/ice/ice_sriov.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
>index b21279f0f5f1e1..8faddf8ba0d523 100644
>--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
>+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
>@@ -1640,7 +1640,7 @@ int ice_get_vf_stats(struct net_device *netdev, int vf_id,
> 	vf_stats->broadcast  = stats->rx_broadcast;
> 	vf_stats->multicast  = stats->rx_multicast;
> 	vf_stats->rx_dropped = stats->rx_discards;
>-	vf_stats->tx_dropped = stats->tx_discards;
>+	vf_stats->tx_dropped = stats->tx_errors;
> 
> out_put_vf:
> 	ice_put_vf(vf);

Reviewed-by: Ivan Vecera <ivecera@redhat.com>

Re: [PATCH iwl-net 06/10] ice: keep adding MAC filters after one that already exists

[Ivan Vecera]

On October 2, 2026 3:07:48 PM GMT+02:00, Petr Oros <poros@redhat.com> wrote:
>ice_add_mac() returns as soon as one entry of the list fails, including
>-EEXIST for a filter that is already programmed for the VSI. The rest of
>the list is never added. ice_vsi_sync_fltr() treats -EEXIST as success,
>so the skipped addresses are considered synced and their traffic is
>dropped until they are removed and added again.
>
>In a test that adds 50 multicast addresses to a port in a burst with
>the port MAC address in the middle of it, 19 of them were left without
>a filter.
>
>Continue with the next entry on -EEXIST and report it once the whole
>list has been processed. Other errors still stop the loop.
>
>There is no i40e counterpart of this fix, i40e keeps its MAC filters in
>a hash with a state per filter and syncs them differently. It was found
>while building a reproducer for the MAC filter overflow handling that
>i40e fixed in commit e58872398684 ("i40e: fix disabling overflow
>promiscuous mode") and commit 7363115efb04 ("i40e: do not force filter
>failure in overflow promiscuous").
>
>Commit bbb968e8b34c ("ice: Fix issues updating VSI MAC filters") dealt
>with the same problem for the VF MAC filter requests, which are now
>added one by one with -EEXIST tolerated, but left ice_add_mac() and the
>PF filter sync as they were.
>
>Fixes: 89f3e4a5b762 ("ice: Do not bail out when filter already exists")
>Assisted-by: LLM
>Signed-off-by: Petr Oros <poros@redhat.com>
>---
> drivers/net/ethernet/intel/ice/ice_switch.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c
>index 2ee5cb6ffdab1f..239d4d9633baa6 100644
>--- a/drivers/net/ethernet/intel/ice/ice_switch.c
>+++ b/drivers/net/ethernet/intel/ice/ice_switch.c
>@@ -3659,7 +3659,9 @@ int ice_add_mac(struct ice_hw *hw, struct list_head *m_list)
> 
> 		m_list_itr->status = ice_add_rule_internal(hw, ICE_SW_LKUP_MAC,
> 							   m_list_itr);
>-		if (m_list_itr->status)
>+		if (m_list_itr->status == -EEXIST)
>+			status = -EEXIST;
>+		else if (m_list_itr->status)
> 			return m_list_itr->status;
> 	}
> 

Reviewed-by: Ivan Vecera <ivecera@redhat.com>

Re: [PATCH iwl-net 07/10] ice: take the switch rule AQ error from the response descriptor

[Ivan Vecera]

On October 2, 2026 3:07:49 PM GMT+02:00, Petr Oros <poros@redhat.com> wrote:
>ice_aq_sw_rules() decides whether a rule removal failed with ENOENT by
>reading hw->adminq.sq_last_status after ice_aq_send_cmd() returned. That
>field is shared by every admin queue user and is only stable while the
>send queue lock is held. Another AQ command completing in between can
>overwrite it, so a failed removal is reported as a generic error, and a
>successful one can even be turned into -ENOENT, because the check is
>not limited to the failure case. A caller that sees -ENOENT keeps its
>rule bookkeeping while the rule is gone from the hardware.
>
>ice_vsi_sync_fltr() has the same problem with ENOSPC. It checks
>sq_last_status only after it has freed the list of filters it tried to
>add. Every entry is a separate devres allocation, so freeing a list of
>thousands of entries takes seconds, and by then the value usually
>belongs to a different command, so the MAC filter overflow handling is
>never entered. With debug prints of the error and sq_last_status added
>to both places:
>
>  ice_aq_sw_rules: opc 0x2a0 status -5 aq 16
>  ice 0000:04:00.0 enp4s0f0np0: Failed to add MAC filters err -5 aq 0
>
>Use the retval of the descriptor that ice_aq_send_cmd() copies back,
>only when the command failed, translate ENOSPC on add to -ENOSPC and
>let ice_vsi_sync_fltr() check the return code instead of
>sq_last_status.
>
>i40e fixed the same kind of race in commit 53a9e346e159 ("i40e: Fix race
>condition while adding/deleting MAC/VLAN filters").
>
>Fixes: ca1fdb885e5f ("ice: return correct error code from ice_aq_sw_rules")
>Assisted-by: LLM
>Signed-off-by: Petr Oros <poros@redhat.com>
>---
> drivers/net/ethernet/intel/ice/ice_main.c   |  4 +---
> drivers/net/ethernet/intel/ice/ice_switch.c | 13 ++++++++++---
> 2 files changed, 11 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
>index 8a21f87eb6ca21..ceb9fec2af21e7 100644
>--- a/drivers/net/ethernet/intel/ice/ice_main.c
>+++ b/drivers/net/ethernet/intel/ice/ice_main.c
>@@ -396,8 +396,6 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi)
> 	struct device *dev = ice_pf_to_dev(vsi->back);
> 	struct net_device *netdev = vsi->netdev;
> 	bool promisc_forced_on = false;
>-	struct ice_pf *pf = vsi->back;
>-	struct ice_hw *hw = &pf->hw;
> 	u32 changed_flags = 0;
> 	int err;
> 
>@@ -450,7 +448,7 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi)
> 		 * should go into promiscuous mode. There should be some
> 		 * space reserved for promiscuous filters.
> 		 */
>-		if (hw->adminq.sq_last_status == LIBIE_AQ_RC_ENOSPC &&
>+		if (err == -ENOSPC &&
> 		    !test_and_set_bit(ICE_FLTR_OVERFLOW_PROMISC,
> 				      vsi->state)) {
> 			promisc_forced_on = true;
>diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c
>index 239d4d9633baa6..ae96a2003d5c5e 100644
>--- a/drivers/net/ethernet/intel/ice/ice_switch.c
>+++ b/drivers/net/ethernet/intel/ice/ice_switch.c
>@@ -1959,9 +1959,16 @@ ice_aq_sw_rules(struct ice_hw *hw, void *rule_list, u16 rule_list_sz,
> 	desc.flags |= cpu_to_le16(LIBIE_AQ_FLAG_RD);
> 	cmd->num_rules_fltr_entry_index = cpu_to_le16(num_rules);
> 	status = ice_aq_send_cmd(hw, &desc, rule_list, rule_list_sz, cd);
>-	if (opc != ice_aqc_opc_add_sw_rules &&
>-	    hw->adminq.sq_last_status == LIBIE_AQ_RC_ENOENT)
>-		status = -ENOENT;
>+	if (status) {
>+		enum libie_aq_err aq_err = le16_to_cpu(desc.retval) & 0xff;
>+
>+		if (opc != ice_aqc_opc_add_sw_rules &&
>+		    aq_err == LIBIE_AQ_RC_ENOENT)
>+			status = -ENOENT;
>+		else if (opc == ice_aqc_opc_add_sw_rules &&
>+			 aq_err == LIBIE_AQ_RC_ENOSPC)
>+			status = -ENOSPC;
>+	}
> 
> 	if (!status) {
> 		if (opc == ice_aqc_opc_add_sw_rules)

Reviewed-by: Ivan Vecera <ivecera@redhat.com>

Re: [PATCH iwl-net 08/10] ice: detect a PF reset that does not complete

[Ivan Vecera]

On October 2, 2026 3:07:50 PM GMT+02:00, Petr Oros <poros@redhat.com> wrote:
>ice_pf_reset() polls PFGEN_CTRL.PFSWR for up to
>ICE_GLOBAL_CFG_LOCK_TIMEOUT + ICE_PF_RESET_WAIT_COUNT iterations, but
>the timeout check after the loop still compares the counter with
>ICE_PF_RESET_WAIT_COUNT alone. When the reset never completes the loop
>ends with cnt == 5300, the check does not match and the function
>returns success with PFSWR still set. A reset that completes just when
>the counter reaches ICE_PF_RESET_WAIT_COUNT is reported as a failure
>instead.
>
>Check the PFSWR bit read last instead of the loop counter, the same
>way i40e_pf_reset() does after its poll loop.
>
>Fixes: c9a12d6d2091 ("ice: Increase timeout after PFR")
>Assisted-by: LLM
>Signed-off-by: Petr Oros <poros@redhat.com>
>---
> drivers/net/ethernet/intel/ice/ice_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
>index 04633103e3e610..0ffd6b5b81239e 100644
>--- a/drivers/net/ethernet/intel/ice/ice_common.c
>+++ b/drivers/net/ethernet/intel/ice/ice_common.c
>@@ -1291,7 +1291,7 @@ static int ice_pf_reset(struct ice_hw *hw)
> 		mdelay(1);
> 	}
> 
>-	if (cnt == ICE_PF_RESET_WAIT_COUNT) {
>+	if (reg & PFGEN_CTRL_PFSWR_M) {
> 		ice_debug(hw, ICE_DBG_INIT, "PF reset polling failed to complete.\n");
> 		return -EIO;
> 	}

Reviewed-by: Ivan Vecera <ivecera@redhat.com>

Re: [PATCH iwl-net 09/10] ice: program multicast magic wake before tearing down the main VSI

[Ivan Vecera]

On October 2, 2026 3:07:51 PM GMT+02:00, Petr Oros <poros@redhat.com> wrote:
>Since commit 5b246e533d01 ("ice: split probe into smaller functions")
>ice_remove() calls ice_setup_mc_magic_wake() after ice_deinit(), which
>frees pf->vsi. ice_get_main_vsi() then returns NULL and the function
>returns before it sends the Manage MAC Write command, so multicast magic
>packet wake and keeping a locally administered address across the PF
>reset are never set up on shutdown with WoL enabled.
>
>Program it before the netdev and the VSIs are torn down, as it was done
>before that commit, so the current netdev address is used again.
>
>i40e had a similar problem, where the multicast magic wake setup ran
>after the admin queue had already been shut down, and fixed it in
>commit e661414c98df ("i40e: Remove duplicated prepare call in
>i40e_shutdown").
>
>Fixes: 5b246e533d01 ("ice: split probe into smaller functions")
>Assisted-by: LLM
>Signed-off-by: Petr Oros <poros@redhat.com>
>---
> drivers/net/ethernet/intel/ice/ice_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
>index ceb9fec2af21e7..a885b3e0baaa5d 100644
>--- a/drivers/net/ethernet/intel/ice/ice_main.c
>+++ b/drivers/net/ethernet/intel/ice/ice_main.c
>@@ -5456,6 +5456,8 @@ static void ice_remove(struct pci_dev *pdev)
> 	if (!ice_is_safe_mode(pf))
> 		ice_remove_arfs(pf);
> 
>+	ice_setup_mc_magic_wake(pf);
>+
> 	devl_lock(priv_to_devlink(pf));
> 	ice_dealloc_all_dynamic_ports(pf);
> 	ice_deinit_devlink(pf);
>@@ -5466,7 +5468,6 @@ static void ice_remove(struct pci_dev *pdev)
> 	ice_deinit(pf);
> 	ice_vsi_release_all(pf);
> 
>-	ice_setup_mc_magic_wake(pf);
> 	ice_set_wake(pf);
> 
> 	ice_adapter_put(pdev);

Reviewed-by: Ivan Vecera <ivecera@redhat.com>

Re: [PATCH iwl-net 10/10] ice: fix unsigned stat widths

[Ivan Vecera]

On October 2, 2026 3:07:52 PM GMT+02:00, Petr Oros <poros@redhat.com> wrote:
>tx_restart, tx_busy, rx_buf_failed and rx_page_failed in struct ice_vsi
>are u32, but ice_update_vsi_ring_stats() fills them with sums of the
>64-bit per ring counters. The values are truncated and the ethtool
>statistics exported from them wrap at 2^32 while the ring counters keep
>counting.
>
>Make them u64 like tx_linearize next to them.
>
>i40e fixed the same truncation in commit 3b8428b84539 ("i40e: fix
>unsigned stat widths").
>
>Fixes: fcea6f3da546 ("ice: Add stats and ethtool support")
>Assisted-by: LLM
>Signed-off-by: Petr Oros <poros@redhat.com>
>---
> drivers/net/ethernet/intel/ice/ice.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
>index 6c596e5a315175..a985b81efbe2d6 100644
>--- a/drivers/net/ethernet/intel/ice/ice.h
>+++ b/drivers/net/ethernet/intel/ice/ice.h
>@@ -344,10 +344,10 @@ struct ice_vsi {
> 	u64 tx_linearize;
> 	DECLARE_BITMAP(state, ICE_VSI_STATE_NBITS);
> 	unsigned int current_netdev_flags;
>-	u32 tx_restart;
>-	u32 tx_busy;
>-	u32 rx_buf_failed;
>-	u32 rx_page_failed;
>+	u64 tx_restart;
>+	u64 tx_busy;
>+	u64 rx_buf_failed;
>+	u64 rx_page_failed;
> 	u16 num_q_vectors;
> 	/* tell if only dynamic irq allocation is allowed */
> 	bool irq_dyn_alloc;

Reviewed-by: Ivan Vecera <ivecera@redhat.com>