All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Valerio <pvalerio@redhat.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
	davem@davemloft.net, claudiu.beznea@tuxon.dev,
	nicolas.ferre@microchip.com, edumazet@google.com,
	pabeni@redhat.com, theo.lebrun@bootlin.com,
	netdev@vger.kernel.org, lorenzo@kernel.org,
	andrew+netdev@lunn.ch
Subject: Re: [net-next,v2,1/8] net: macb: move Rx buffers alloc from link up to open
Date: Wed, 25 Feb 2026 19:29:24 +0100	[thread overview]
Message-ID: <87a4wwn0cb.fsf@redhat.com> (raw)
In-Reply-To: <20260224000841.140390-1-kuba@kernel.org>

On 23 Feb 2026 at 04:08:32 PM, Jakub Kicinski <kuba@kernel.org> 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.
>
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
> net: macb: move Rx buffers alloc from link up to open
>
> This commit moves Rx buffer allocation to macb_open() to enable early
> error propagation, adding a fail_early parameter to control whether ring
> initialization fails fast or continues on error.
>
>> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
>> index 87414a2ddf6e..2cb65ec37d44 100644
>> --- a/drivers/net/ethernet/cadence/macb.h
>> +++ b/drivers/net/ethernet/cadence/macb.h
>> @@ -1180,7 +1180,7 @@ struct macb_queue;
>>  struct macb_or_gem_ops {
>>  	int	(*mog_alloc_rx_buffers)(struct macb *bp);
>>  	void	(*mog_free_rx_buffers)(struct macb *bp);
>> -	void	(*mog_init_rings)(struct macb *bp);
>> +	int	(*mog_init_rings)(struct macb *bp, bool fail_early);
>>  	int	(*mog_rx)(struct macb_queue *queue, struct napi_struct *napi,
>>  			  int budget);
>>  };
>
> [ ... ]
>
>> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
>> index 43cd013bb70e..8cc16f2b4024 100644
>> --- a/drivers/net/ethernet/cadence/macb_main.c
>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>
> [ ... ]
>
>> @@ -2544,8 +2547,6 @@ static int macb_alloc_consistent(struct macb *bp)
>>  		if (!queue->tx_skb)
>>  			goto out_err;
>>  	}
>> -	if (bp->macbgem_ops.mog_alloc_rx_buffers(bp))
>> -		goto out_err;
>>
>>  	/* Required for tie off descriptor for PM cases */
>>  	if (!(bp->caps & MACB_CAPS_QUEUE_DISABLE)) {
>> @@ -2557,6 +2558,11 @@ static int macb_alloc_consistent(struct macb *bp)
>>  			goto out_err;
>>  	}
>>
>> +	if (bp->macbgem_ops.mog_alloc_rx_buffers(bp))
>> +		goto out_err;
>> +	if (bp->macbgem_ops.mog_init_rings(bp, true))
>> +		goto out_err;
>> +
>>  	return 0;
>>
>>  out_err:
>
> [ ... ]
>
>> @@ -2951,7 +2971,7 @@ static int macb_open(struct net_device *dev)
>>  		goto pm_exit;
>>  	}
>>
>> -	bp->macbgem_ops.mog_init_rings(bp);
>> +	bp->macbgem_ops.mog_init_rings(bp, true);
>>  	macb_init_buffers(bp);
>>
>>  	for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
>
> Is mog_init_rings() being called twice in the macb_open() path? Looking at
> the code flow:
>
> macb_open()
>   macb_alloc_consistent() at line 2967
>     mog_init_rings(bp, true) at line 2563
>   mog_init_rings(bp, true) at line 2974
>
> The first call inside macb_alloc_consistent() initializes the rings and
> checks the return value. The second call in macb_open() appears to be
> redundant: by the time macb_open() reaches line 2974, gem_init_rings() has
> already refilled all Rx slots via the earlier call.
>
> When gem_init_rings() runs the second time, CIRC_SPACE returns 0 because
> all slots are filled, so gem_rx_refill() effectively does nothing. The
> second call reinitializes head/tail pointers that are already set and runs
> a no-op refill.
>
> Should this second call be removed to avoid the redundancy?
>
> Additionally, the return value from the second mog_init_rings(bp, true)
> call is silently discarded. The stated purpose of this patch is to "fail
> early and loudly rather than init the device with Rx mostly broken," but
> this call site doesn't check for errors while the call in
> macb_alloc_consistent() does.
>
> If the second call is intentional, should its return value be checked?
>
> This was noted in the v2 review by Théo Lebrun (Jan 8, 2026) who pointed
> out that commit 99537d5c476c relocated mog_init_rings() from
> macb_mac_link_up() to macb_open(), making this second call redundant. Paolo
> acknowledged this with "will do" but the duplicate call remains.

yes, this definitely is not intentional. Must have been left/reintroduced
by mistake while rebasing v2, sorry.

> -- 
> pw-bot: cr


  reply	other threads:[~2026-02-25 18:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23 18:26 [PATCH net-next v2 0/8] net: macb: Add XDP support and page pool integration Paolo Valerio
2026-02-23 18:26 ` [PATCH net-next v2 1/8] net: macb: move Rx buffers alloc from link up to open Paolo Valerio
2026-02-24  0:08   ` [net-next,v2,1/8] " Jakub Kicinski
2026-02-25 18:29     ` Paolo Valerio [this message]
2026-02-23 18:26 ` [PATCH net-next v2 2/8] net: macb: rename rx_skbuff into rx_buff Paolo Valerio
2026-02-23 18:26 ` [PATCH net-next v2 3/8] net: macb: Add page pool support handle multi-descriptor frame rx Paolo Valerio
2026-02-23 18:26 ` [PATCH net-next v2 4/8] net: macb: use the current queue number for stats Paolo Valerio
2026-02-23 18:26 ` [PATCH net-next v2 5/8] net: macb: add XDP support for gem Paolo Valerio
2026-02-23 23:23   ` kernel test robot
2026-02-24  0:08   ` [net-next,v2,5/8] " Jakub Kicinski
2026-02-25 18:30     ` Paolo Valerio
2026-02-27 10:52       ` Théo Lebrun
2026-02-28 13:49         ` Claudiu Beznea
2026-02-23 18:26 ` [PATCH net-next v2 6/8] net: macb: make macb_tx_skb generic Paolo Valerio
2026-02-24  0:08   ` [net-next,v2,6/8] " Jakub Kicinski
2026-02-23 18:26 ` [PATCH net-next v2 7/8] net: macb: make tx path skb agnostic Paolo Valerio
2026-02-24  0:09   ` [net-next,v2,7/8] " Jakub Kicinski
2026-02-25 18:36     ` Paolo Valerio
2026-02-23 18:26 ` [PATCH net-next v2 8/8] net: macb: introduce xmit support Paolo Valerio
2026-02-24  0:09   ` [net-next,v2,8/8] " Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a4wwn0cb.fsf@redhat.com \
    --to=pvalerio@redhat.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=pabeni@redhat.com \
    --cc=theo.lebrun@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.