[PATCH net 0/3][pull request] Intel Wired LAN Driver Updates 2026-06-02 (i40e, ice, idpf)

[PATCH net 0/3][pull request] Intel Wired LAN Driver Updates 2026-06-02 (i40e, ice, idpf)

[Tony Nguyen]

Maciej fixes i40e to keep q_vectors in sync through channel changes
which caused issues with reconfiguration.

Petr Oros adds missing callbacks for U.FL DPLL pins on ice.

Alok Tiwari corrects copy/paste error causing incorrect reporting of PTP
mailbox capability for idpf.

The following are changes since commit 3522b21fd7e1863d0734537737bd59f1b90d0190:
  devlink: Release nested relation on devlink free
and are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue 40GbE

Alok Tiwari (1):
  idpf: fix mailbox capability for set device clock time

Maciej Fijalkowski (1):
  i40e: keep q_vectors array in sync with channel count changes

Petr Oros (1):
  ice: fix missing priority callbacks for U.FL DPLL pins

 drivers/net/ethernet/intel/i40e/i40e_main.c | 73 +++++++++++++--------
 drivers/net/ethernet/intel/ice/ice_dpll.c   |  2 +
 drivers/net/ethernet/intel/idpf/idpf_ptp.c  |  2 +-
 3 files changed, 47 insertions(+), 30 deletions(-)

-- 
2.47.1

[PATCH net 1/3] i40e: keep q_vectors array in sync with channel count changes

[Tony Nguyen]

From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>

For the main VSI, i40e_set_num_rings_in_vsi() always derives
num_q_vectors from pf->num_lan_msix. At the same time, ethtool -L stores
the user requested channel count in vsi->req_queue_pairs and the queue
setup path uses that value for the effective number of queue pairs.

This leaves queue and vector counts out of sync after shrinking channel
count via ethtool -L. The active queue configuration is reduced, but the
VSI still keeps the full PF-sized q_vector topology.

That mismatch breaks reconfiguration flows which rely on vector/NAPI
state matching the effective channel configuration. In particular,
toggling /sys/class/net/<dev>/threaded after reducing the channel count
can hang, and later channel-count changes can fail because VSI reinit
does not rebuild q_vectors to match the new vector count.

Fix this by making the main VSI num_q_vectors follow the effective
requested channel count, capped by the available MSI-X vectors. Update
i40e_vsi_reinit_setup() to rebuild q_vectors during VSI reinit so the
vector topology is refreshed together with the ring arrays when channel
count changes.

Keep alloc_queue_pairs unchanged and based on pf->num_lan_qps so the VSI
retains its full queue capacity.

Selftest napi_threaded.py was originally used when Jakub reported hang
on /sys/class/net/<dev>/threaded toggle. In order to make it pass on
i40e, use persistent NAPI configuration for q_vector NAPIs so NAPI
identity and threaded settings survive q_vector reallocation across
channel-count changes. This is achieved by using netif_napi_add_config()
when configuring q_vectors.

$ export NETIF=ens259f1np1
$ sudo -E env PATH="$PATH" ./tools/testing/selftests/drivers/net/napi_threaded.py
TAP version 13
1..3
ok 1 napi_threaded.napi_init
ok 2 napi_threaded.change_num_queues
ok 3 napi_threaded.enable_dev_threaded_disable_napi_threaded
Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0

Reported-by: Jakub Kicinski <kuba@kernel.org>
Closes: https://lore.kernel.org/intel-wired-lan/20260316133100.6054a11f@kernel.org/
Fixes: d2a69fefd756 ("i40e: Fix changing previously set num_queue_pairs for PFs")
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com>
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 73 +++++++++++++--------
 1 file changed, 44 insertions(+), 29 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 6d4f9218dc68..c3fbe14ff2d3 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -11403,10 +11403,14 @@ static void i40e_service_timer(struct timer_list *t)
 static int i40e_set_num_rings_in_vsi(struct i40e_vsi *vsi)
 {
 	struct i40e_pf *pf = vsi->back;
+	u16 qps;
 
 	switch (vsi->type) {
 	case I40E_VSI_MAIN:
 		vsi->alloc_queue_pairs = pf->num_lan_qps;
+		qps = vsi->req_queue_pairs ?
+		      min(vsi->req_queue_pairs, pf->num_lan_qps) :
+		      pf->num_lan_qps;
 		if (!vsi->num_tx_desc)
 			vsi->num_tx_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
 						 I40E_REQ_DESCRIPTOR_MULTIPLE);
@@ -11414,7 +11418,7 @@ static int i40e_set_num_rings_in_vsi(struct i40e_vsi *vsi)
 			vsi->num_rx_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
 						 I40E_REQ_DESCRIPTOR_MULTIPLE);
 		if (test_bit(I40E_FLAG_MSIX_ENA, pf->flags))
-			vsi->num_q_vectors = pf->num_lan_msix;
+			vsi->num_q_vectors = clamp(qps, 1, pf->num_lan_msix);
 		else
 			vsi->num_q_vectors = 1;
 
@@ -11466,12 +11470,11 @@ static int i40e_set_num_rings_in_vsi(struct i40e_vsi *vsi)
 /**
  * i40e_vsi_alloc_arrays - Allocate queue and vector pointer arrays for the vsi
  * @vsi: VSI pointer
- * @alloc_qvectors: a bool to specify if q_vectors need to be allocated.
  *
  * On error: returns error code (negative)
  * On success: returns 0
  **/
-static int i40e_vsi_alloc_arrays(struct i40e_vsi *vsi, bool alloc_qvectors)
+static int i40e_vsi_alloc_arrays(struct i40e_vsi *vsi)
 {
 	struct i40e_ring **next_rings;
 	int size;
@@ -11490,19 +11493,18 @@ static int i40e_vsi_alloc_arrays(struct i40e_vsi *vsi, bool alloc_qvectors)
 	}
 	vsi->rx_rings = next_rings;
 
-	if (alloc_qvectors) {
-		/* allocate memory for q_vector pointers */
-		size = sizeof(struct i40e_q_vector *) * vsi->num_q_vectors;
-		vsi->q_vectors = kzalloc(size, GFP_KERNEL);
-		if (!vsi->q_vectors) {
-			ret = -ENOMEM;
-			goto err_vectors;
-		}
+	/* allocate memory for q_vector pointers */
+	size = sizeof(struct i40e_q_vector *) * vsi->num_q_vectors;
+	vsi->q_vectors = kzalloc(size, GFP_KERNEL);
+	if (!vsi->q_vectors) {
+		ret = -ENOMEM;
+		goto err_vectors;
 	}
 	return ret;
 
 err_vectors:
 	kfree(vsi->tx_rings);
+	vsi->tx_rings = NULL;
 	return ret;
 }
 
@@ -11575,7 +11577,7 @@ static int i40e_vsi_mem_alloc(struct i40e_pf *pf, enum i40e_vsi_type type)
 	if (ret)
 		goto err_rings;
 
-	ret = i40e_vsi_alloc_arrays(vsi, true);
+	ret = i40e_vsi_alloc_arrays(vsi);
 	if (ret)
 		goto err_rings;
 
@@ -11600,18 +11602,15 @@ static int i40e_vsi_mem_alloc(struct i40e_pf *pf, enum i40e_vsi_type type)
 /**
  * i40e_vsi_free_arrays - Free queue and vector pointer arrays for the VSI
  * @vsi: VSI pointer
- * @free_qvectors: a bool to specify if q_vectors need to be freed.
  *
  * On error: returns error code (negative)
  * On success: returns 0
  **/
-static void i40e_vsi_free_arrays(struct i40e_vsi *vsi, bool free_qvectors)
+static void i40e_vsi_free_arrays(struct i40e_vsi *vsi)
 {
 	/* free the ring and vector containers */
-	if (free_qvectors) {
-		kfree(vsi->q_vectors);
-		vsi->q_vectors = NULL;
-	}
+	kfree(vsi->q_vectors);
+	vsi->q_vectors = NULL;
 	kfree(vsi->tx_rings);
 	vsi->tx_rings = NULL;
 	vsi->rx_rings = NULL;
@@ -11671,7 +11670,7 @@ static int i40e_vsi_clear(struct i40e_vsi *vsi)
 	i40e_put_lump(pf->irq_pile, vsi->base_vector, vsi->idx);
 
 	bitmap_free(vsi->af_xdp_zc_qps);
-	i40e_vsi_free_arrays(vsi, true);
+	i40e_vsi_free_arrays(vsi);
 	i40e_clear_rss_config_user(vsi);
 
 	pf->vsi[vsi->idx] = NULL;
@@ -12043,7 +12042,8 @@ static int i40e_vsi_alloc_q_vector(struct i40e_vsi *vsi, int v_idx)
 	cpumask_copy(&q_vector->affinity_mask, cpu_possible_mask);
 
 	if (vsi->netdev)
-		netif_napi_add(vsi->netdev, &q_vector->napi, i40e_napi_poll);
+		netif_napi_add_config(vsi->netdev, &q_vector->napi,
+				      i40e_napi_poll, v_idx);
 
 	/* tie q_vector and vsi together */
 	vsi->q_vectors[v_idx] = q_vector;
@@ -14264,12 +14264,26 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
 
 	pf = vsi->back;
 
+	if (test_bit(I40E_FLAG_MSIX_ENA, pf->flags)) {
+		i40e_put_lump(pf->irq_pile, vsi->base_vector, vsi->idx);
+		vsi->base_vector = 0;
+	}
+
 	i40e_put_lump(pf->qp_pile, vsi->base_queue, vsi->idx);
+	i40e_vsi_free_q_vectors(vsi);
 	i40e_vsi_clear_rings(vsi);
+	i40e_vsi_free_arrays(vsi);
 
-	i40e_vsi_free_arrays(vsi, false);
 	i40e_set_num_rings_in_vsi(vsi);
-	ret = i40e_vsi_alloc_arrays(vsi, false);
+	ret = i40e_vsi_alloc_arrays(vsi);
+	if (ret)
+		goto err_vsi;
+
+	/* Rebuild q_vectors during VSI reinit because the effective channel
+	 * count may change num_q_vectors. Keep vector topology aligned with the
+	 * queue configuration after ethtool's .set_channels() callback.
+	 */
+	ret = i40e_vsi_setup_vectors(vsi);
 	if (ret)
 		goto err_vsi;
 
@@ -14281,7 +14295,7 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
 		dev_info(&pf->pdev->dev,
 			 "failed to get tracking for %d queues for VSI %d err %d\n",
 			 alloc_queue_pairs, vsi->seid, ret);
-		goto err_vsi;
+		goto err_lump;
 	}
 	vsi->base_queue = ret;
 
@@ -14305,7 +14319,6 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
 	return vsi;
 
 err_rings:
-	i40e_vsi_free_q_vectors(vsi);
 	if (vsi->netdev_registered) {
 		vsi->netdev_registered = false;
 		unregister_netdev(vsi->netdev);
@@ -14315,6 +14328,8 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
 	if (vsi->type == I40E_VSI_MAIN)
 		i40e_devlink_destroy_port(pf);
 	i40e_aq_delete_element(&pf->hw, vsi->seid, NULL);
+err_lump:
+	i40e_vsi_free_q_vectors(vsi);
 err_vsi:
 	i40e_vsi_clear(vsi);
 	return NULL;
@@ -14456,12 +14471,12 @@ struct i40e_vsi *i40e_vsi_setup(struct i40e_pf *pf, u8 type,
 #endif /* CONFIG_I40E_DCB */
 		fallthrough;
 	case I40E_VSI_FDIR:
-		/* set up vectors and rings if needed */
-		ret = i40e_vsi_setup_vectors(vsi);
+		ret = i40e_alloc_rings(vsi);
 		if (ret)
 			goto err_msix;
 
-		ret = i40e_alloc_rings(vsi);
+		/* set up vectors and rings if needed */
+		ret = i40e_vsi_setup_vectors(vsi);
 		if (ret)
 			goto err_rings;
 
@@ -14484,9 +14499,9 @@ struct i40e_vsi *i40e_vsi_setup(struct i40e_pf *pf, u8 type,
 	return vsi;
 
 err_config:
-	i40e_vsi_clear_rings(vsi);
-err_rings:
 	i40e_vsi_free_q_vectors(vsi);
+err_rings:
+	i40e_vsi_clear_rings(vsi);
 err_msix:
 	if (vsi->netdev_registered) {
 		vsi->netdev_registered = false;
-- 
2.47.1

Re: [PATCH net 1/3] i40e: keep q_vectors array in sync with channel count changes

[Jakub Kicinski]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
i40e: keep q_vectors array in sync with channel count changes

This patch makes the main VSI's num_q_vectors track the effective
requested channel count and rebuilds q_vectors during VSI reinit so the
vector topology is refreshed together with the ring arrays. It also
switches to netif_napi_add_config() so NAPI identity survives q_vector
reallocation across channel-count changes.

Link: https://lore.kernel.org/intel-wired-lan/20260316133100.6054a11f@kernel.org/

> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index 6d4f9218dc68..c3fbe14ff2d3 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c

[ ... ]

> @@ -14264,12 +14264,26 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
>  
>  	pf = vsi->back;
>  
> +	if (test_bit(I40E_FLAG_MSIX_ENA, pf->flags)) {
> +		i40e_put_lump(pf->irq_pile, vsi->base_vector, vsi->idx);
> +		vsi->base_vector = 0;
> +	}
> +
>  	i40e_put_lump(pf->qp_pile, vsi->base_queue, vsi->idx);
> +	i40e_vsi_free_q_vectors(vsi);
>  	i40e_vsi_clear_rings(vsi);
> +	i40e_vsi_free_arrays(vsi);
>  
> -	i40e_vsi_free_arrays(vsi, false);
>  	i40e_set_num_rings_in_vsi(vsi);
> -	ret = i40e_vsi_alloc_arrays(vsi, false);
> +	ret = i40e_vsi_alloc_arrays(vsi);
> +	if (ret)
> +		goto err_vsi;
> +
> +	/* Rebuild q_vectors during VSI reinit because the effective channel
> +	 * count may change num_q_vectors. Keep vector topology aligned with the
> +	 * queue configuration after ethtool's .set_channels() callback.
> +	 */
> +	ret = i40e_vsi_setup_vectors(vsi);
>  	if (ret)
>  		goto err_vsi;

[High]
Can the err_vsi path here cause a use-after-free of vsi via netdev_priv?

Reinit is invoked from i40e_rebuild() -> i40e_setup_pf_switch(pf, true,
...) on an already-registered netdev (vsi->netdev_registered == true),
and struct i40e_netdev_priv keeps a pointer at the vsi. The err_vsi
label only calls i40e_vsi_clear() which kfrees the vsi without
unregistering vsi->netdev, destroying the devlink port, or deleting
the FW VSI element:

drivers/net/ethernet/intel/i40e/i40e_main.c:i40e_vsi_clear() {
    ...
    i40e_put_lump(pf->qp_pile, vsi->base_queue, vsi->idx);
    i40e_put_lump(pf->irq_pile, vsi->base_vector, vsi->idx);

    bitmap_free(vsi->af_xdp_zc_qps);
    i40e_vsi_free_arrays(vsi);
    i40e_clear_rss_config_user(vsi);
    ...
    kfree(vsi);
    ...
}

If i40e_vsi_alloc_arrays() or the newly added i40e_vsi_setup_vectors()
fails (e.g. kzalloc of q_vectors, kzalloc of an individual q_vector,
or i40e_get_lump(irq_pile)), would a subsequent ndo_* callback on the
still-registered netdev dereference the freed vsi through
netdev_priv()?

Two new failure points the patch routes into err_vsi were not reachable
before: the unconditional q_vectors kzalloc in i40e_vsi_alloc_arrays()
and the entire i40e_vsi_setup_vectors() call.

> @@ -14281,7 +14295,7 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
>  		dev_info(&pf->pdev->dev,
>  			 "failed to get tracking for %d queues for VSI %d err %d\n",
>  			 alloc_queue_pairs, vsi->seid, ret);
> -		goto err_vsi;
> +		goto err_lump;
>  	}
>  	vsi->base_queue = ret;
>  
> @@ -14305,7 +14319,6 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
>  	return vsi;
>  
>  err_rings:
> -	i40e_vsi_free_q_vectors(vsi);
>  	if (vsi->netdev_registered) {
>  		vsi->netdev_registered = false;
>  		unregister_netdev(vsi->netdev);
> @@ -14315,6 +14328,8 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
>  	if (vsi->type == I40E_VSI_MAIN)
>  		i40e_devlink_destroy_port(pf);
>  	i40e_aq_delete_element(&pf->hw, vsi->seid, NULL);
> +err_lump:
> +	i40e_vsi_free_q_vectors(vsi);
>  err_vsi:
>  	i40e_vsi_clear(vsi);
>  	return NULL;

Should the new err_lump label, and the existing err_vsi exits from the
two allocation steps above, instead unwind through the err_rings block
(unregister_netdev / free_netdev / i40e_devlink_destroy_port /
i40e_aq_delete_element) the way i40e_vsi_setup()'s err_msix path does?

The pre-patch code had the same defective err_vsi target for the
qp_pile and arrays paths, but the patch adds two new failure points
(the unconditional q_vectors kzalloc and the new
i40e_vsi_setup_vectors() call) that route into it during reset
rebuild, where vsi->netdev is already registered.

Re: [PATCH net 1/3] i40e: keep q_vectors array in sync with channel count changes

[Tony Nguyen]

On 6/3/2026 6:27 PM, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> i40e: keep q_vectors array in sync with channel count changes
> 
> This patch makes the main VSI's num_q_vectors track the effective
> requested channel count and rebuilds q_vectors during VSI reinit so the
> vector topology is refreshed together with the ring arrays. It also
> switches to netif_napi_add_config() so NAPI identity survives q_vector
> reallocation across channel-count changes.
> 
> Link: https://lore.kernel.org/intel-wired-lan/20260316133100.6054a11f@kernel.org/
> 
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
>> index 6d4f9218dc68..c3fbe14ff2d3 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
>> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> 
> [ ... ]
> 
>> @@ -14264,12 +14264,26 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
>>   
>>   	pf = vsi->back;
>>   
>> +	if (test_bit(I40E_FLAG_MSIX_ENA, pf->flags)) {
>> +		i40e_put_lump(pf->irq_pile, vsi->base_vector, vsi->idx);
>> +		vsi->base_vector = 0;
>> +	}
>> +
>>   	i40e_put_lump(pf->qp_pile, vsi->base_queue, vsi->idx);
>> +	i40e_vsi_free_q_vectors(vsi);
>>   	i40e_vsi_clear_rings(vsi);
>> +	i40e_vsi_free_arrays(vsi);
>>   
>> -	i40e_vsi_free_arrays(vsi, false);
>>   	i40e_set_num_rings_in_vsi(vsi);
>> -	ret = i40e_vsi_alloc_arrays(vsi, false);
>> +	ret = i40e_vsi_alloc_arrays(vsi);
>> +	if (ret)
>> +		goto err_vsi;
>> +
>> +	/* Rebuild q_vectors during VSI reinit because the effective channel
>> +	 * count may change num_q_vectors. Keep vector topology aligned with the
>> +	 * queue configuration after ethtool's .set_channels() callback.
>> +	 */
>> +	ret = i40e_vsi_setup_vectors(vsi);
>>   	if (ret)
>>   		goto err_vsi;
> 
> [High]
> Can the err_vsi path here cause a use-after-free of vsi via netdev_priv?
> 
> Reinit is invoked from i40e_rebuild() -> i40e_setup_pf_switch(pf, true,
> ...) on an already-registered netdev (vsi->netdev_registered == true),
> and struct i40e_netdev_priv keeps a pointer at the vsi. The err_vsi
> label only calls i40e_vsi_clear() which kfrees the vsi without
> unregistering vsi->netdev, destroying the devlink port, or deleting
> the FW VSI element:
> 
> drivers/net/ethernet/intel/i40e/i40e_main.c:i40e_vsi_clear() {
>      ...
>      i40e_put_lump(pf->qp_pile, vsi->base_queue, vsi->idx);
>      i40e_put_lump(pf->irq_pile, vsi->base_vector, vsi->idx);
> 
>      bitmap_free(vsi->af_xdp_zc_qps);
>      i40e_vsi_free_arrays(vsi);
>      i40e_clear_rss_config_user(vsi);
>      ...
>      kfree(vsi);
>      ...
> }
> 
> If i40e_vsi_alloc_arrays() or the newly added i40e_vsi_setup_vectors()
> fails (e.g. kzalloc of q_vectors, kzalloc of an individual q_vector,
> or i40e_get_lump(irq_pile)), would a subsequent ndo_* callback on the
> still-registered netdev dereference the freed vsi through
> netdev_priv()?
> 
> Two new failure points the patch routes into err_vsi were not reachable
> before: the unconditional q_vectors kzalloc in i40e_vsi_alloc_arrays()
> and the entire i40e_vsi_setup_vectors() call.
> 
>> @@ -14281,7 +14295,7 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
>>   		dev_info(&pf->pdev->dev,
>>   			 "failed to get tracking for %d queues for VSI %d err %d\n",
>>   			 alloc_queue_pairs, vsi->seid, ret);
>> -		goto err_vsi;
>> +		goto err_lump;
>>   	}
>>   	vsi->base_queue = ret;
>>   
>> @@ -14305,7 +14319,6 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
>>   	return vsi;
>>   
>>   err_rings:
>> -	i40e_vsi_free_q_vectors(vsi);
>>   	if (vsi->netdev_registered) {
>>   		vsi->netdev_registered = false;
>>   		unregister_netdev(vsi->netdev);
>> @@ -14315,6 +14328,8 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
>>   	if (vsi->type == I40E_VSI_MAIN)
>>   		i40e_devlink_destroy_port(pf);
>>   	i40e_aq_delete_element(&pf->hw, vsi->seid, NULL);
>> +err_lump:
>> +	i40e_vsi_free_q_vectors(vsi);
>>   err_vsi:
>>   	i40e_vsi_clear(vsi);
>>   	return NULL;
> 
> Should the new err_lump label, and the existing err_vsi exits from the
> two allocation steps above, instead unwind through the err_rings block
> (unregister_netdev / free_netdev / i40e_devlink_destroy_port /
> i40e_aq_delete_element) the way i40e_vsi_setup()'s err_msix path does?
> 
> The pre-patch code had the same defective err_vsi target for the
> qp_pile and arrays paths, but the patch adds two new failure points
> (the unconditional q_vectors kzalloc and the new
> i40e_vsi_setup_vectors() call) that route into it during reset
> rebuild, where vsi->netdev is already registered.

Hi Jakub,

This does seem valid, but as mentioned by Sashiko the pre-patch code has 
the same target/issue. There's a recent submission [1], with changes 
requested, that should cover this. Did you want to take this now or wait 
and have it sent with this other one?

Thanks,
Tony

[1] 
https://lore.kernel.org/intel-wired-lan/eb74ae1c-3027-42f5-ad5b-a6f2c2cd6a98@onemain.com/

Re: [PATCH net 1/3] i40e: keep q_vectors array in sync with channel count changes

[Jakub Kicinski]

On Fri, 5 Jun 2026 11:01:19 -0700 Tony Nguyen wrote:
> > Should the new err_lump label, and the existing err_vsi exits from the
> > two allocation steps above, instead unwind through the err_rings block
> > (unregister_netdev / free_netdev / i40e_devlink_destroy_port /
> > i40e_aq_delete_element) the way i40e_vsi_setup()'s err_msix path does?
> > 
> > The pre-patch code had the same defective err_vsi target for the
> > qp_pile and arrays paths, but the patch adds two new failure points
> > (the unconditional q_vectors kzalloc and the new
> > i40e_vsi_setup_vectors() call) that route into it during reset
> > rebuild, where vsi->netdev is already registered.  
>  
> This does seem valid, but as mentioned by Sashiko the pre-patch code has 
> the same target/issue. There's a recent submission [1], with changes 
> requested, that should cover this. Did you want to take this now or wait 
> and have it sent with this other one?

Hm. I convinced myself yesterday that the old code did _not_ 
have the issue because it was pass false as the second arg to
i40e_vsi_{alloc,free}_arrays() ? Good chance that I misread,
it's tricky code. As much as I would love to apply this to prevent 
the deadlock in NIPA - let's wait for the follow up. I'll pick up 
the other two patches from this series off the list.

[PATCH net 2/3] ice: fix missing priority callbacks for U.FL DPLL pins

[Tony Nguyen]

From: Petr Oros <poros@redhat.com>

The U.FL2 input pin advertises DPLL_PIN_CAPABILITIES_PRIORITY_CAN_CHANGE
in its capability mask, but ice_dpll_pin_ufl_ops does not provide
.prio_get and .prio_set callbacks. As a result the DPLL subsystem
cannot report or accept priority for U.FL pins: pin-get omits the prio
field on U.FL2 and pin-set with prio is rejected as invalid, even
though the capability is present. This prevents user space from using
priority to select or disable U.FL2 as a DPLL input source.

Reproducer with iproute2 (dpll command):

  # dpll pin show board-label U.FL2
  pin id 16:
    module-name ice
    board-label U.FL2
    type ext
    capabilities priority-can-change|state-can-change
    parent-device:
      id 0 direction input state selectable phase-offset 0
    /* note: no "prio" between "direction" and "state",
       even though priority-can-change is advertised */

  # dpll pin set id 16 parent-device 0 prio 5
  RTNETLINK answers: Operation not supported

After the fix the prio field is reported by pin show and pin set with
prio is accepted on U.FL2.

Add the missing .prio_get and .prio_set callbacks to
ice_dpll_pin_ufl_ops, reusing ice_dpll_sw_input_prio_{get,set}. The
same ops struct is shared by U.FL1 and U.FL2: U.FL2 (input) delegates
to the backing hardware input pin, while U.FL1 (output) does not
advertise DPLL_PIN_CAPABILITIES_PRIORITY_CAN_CHANGE so the dpll core
capability gate never invokes prio_set for it, and prio_get reports
the OUTPUT sentinel (ICE_DPLL_PIN_PRIO_OUTPUT) on the output side
exactly like the SMA path does today.

Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Petr Oros <poros@redhat.com>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_dpll.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c
index 892bc7c2e28b..0704e92ab043 100644
--- a/drivers/net/ethernet/intel/ice/ice_dpll.c
+++ b/drivers/net/ethernet/intel/ice/ice_dpll.c
@@ -2633,6 +2633,8 @@ static const struct dpll_pin_ops ice_dpll_pin_ufl_ops = {
 	.state_on_dpll_set = ice_dpll_ufl_pin_state_set,
 	.state_on_dpll_get = ice_dpll_sw_pin_state_get,
 	.direction_get = ice_dpll_pin_sw_direction_get,
+	.prio_get = ice_dpll_sw_input_prio_get,
+	.prio_set = ice_dpll_sw_input_prio_set,
 	.frequency_get = ice_dpll_sw_pin_frequency_get,
 	.frequency_set = ice_dpll_sw_pin_frequency_set,
 	.esync_set = ice_dpll_sw_esync_set,
-- 
2.47.1

[PATCH net 3/3] idpf: fix mailbox capability for set device clock time

[Tony Nguyen]

From: Alok Tiwari <alok.a.tiwari@oracle.com>

The current code incorrectly uses VIRTCHNL2_CAP_PTP_SET_DEVICE_CLK_TIME
for both direct and mailbox capabilities, causing mailbox-only support
to be ignored and potentially reporting IDPF_PTP_NONE.

Fixes: d5dba8f7206da ("idpf: add PTP clock configuration")
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/idpf/idpf_ptp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/idpf/idpf_ptp.c b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
index 4a51d2727547..71fe8b2a8b4e 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_ptp.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
@@ -51,7 +51,7 @@ void idpf_ptp_get_features_access(const struct idpf_adapter *adapter)
 
 	/* Set the device clock time */
 	direct = VIRTCHNL2_CAP_PTP_SET_DEVICE_CLK_TIME;
-	mailbox = VIRTCHNL2_CAP_PTP_SET_DEVICE_CLK_TIME;
+	mailbox = VIRTCHNL2_CAP_PTP_SET_DEVICE_CLK_TIME_MB;
 	ptp->set_dev_clk_time_access = idpf_ptp_get_access(adapter,
 							   direct,
 							   mailbox);
-- 
2.47.1

Re: [PATCH net 0/3][pull request] Intel Wired LAN Driver Updates 2026-06-02 (i40e, ice, idpf)

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Tue,  2 Jun 2026 15:55:08 -0700 you wrote:
> Maciej fixes i40e to keep q_vectors in sync through channel changes
> which caused issues with reconfiguration.
> 
> Petr Oros adds missing callbacks for U.FL DPLL pins on ice.
> 
> Alok Tiwari corrects copy/paste error causing incorrect reporting of PTP
> mailbox capability for idpf.
> 
> [...]

Here is the summary with links:
  - [net,1/3] i40e: keep q_vectors array in sync with channel count changes
    (no matching commit)
  - [net,2/3] ice: fix missing priority callbacks for U.FL DPLL pins
    https://git.kernel.org/netdev/net/c/f1fa677e428e
  - [net,3/3] idpf: fix mailbox capability for set device clock time
    https://git.kernel.org/netdev/net/c/85b0cbc1f38b

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