netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
	pabeni@redhat.com
Subject: Re: [net PATCH 5/6] fbnic: Cleanup handling of completions
Date: Fri, 2 May 2025 11:45:23 +0100	[thread overview]
Message-ID: <20250502104523.GH3339421@horms.kernel.org> (raw)
In-Reply-To: <174614222289.126317.15583861344398410489.stgit@ahduyck-xeon-server.home.arpa>

On Thu, May 01, 2025 at 04:30:22PM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexanderduyck@fb.com>
> 
> There was an issue in that if we were to shutdown we could be left with
> a completion in flight as the mailbox went away. To address that I have
> added an fbnic_mbx_evict_all_cmpl function that is meant to essentially
> create a "broken pipe" type response so that all callers will receive an
> error indicating that the connection has been broken as a result of us
> shutting down the mailbox.
> 
> In addition the naming was inconsistent between the creation and clearing
> of completions. Since the cmpl seems to be the common suffix to use for the
> handling of cmpl_data I went through and renamed fbnic_fw_clear_compl to
> fbnic_fw_clear_cmpl.

I do see this is somehow related to the fix described in the first
paragraph. But I don't think renaming functions like this is appropriate
for net.

> Fixes: 378e5cc1c6c6 ("eth: fbnic: hwmon: Add completion infrastructure for firmware requests")
> 
> Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
> ---
>  drivers/net/ethernet/meta/fbnic/fbnic_fw.c  |   22 +++++++++++++++++++++-
>  drivers/net/ethernet/meta/fbnic/fbnic_fw.h  |    2 +-
>  drivers/net/ethernet/meta/fbnic/fbnic_mac.c |    2 +-
>  3 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_fw.c b/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
> index d019191d6ae9..efc0176f1a9a 100644
> --- a/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
> +++ b/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
> @@ -928,6 +928,23 @@ int fbnic_mbx_poll_tx_ready(struct fbnic_dev *fbd)
>  	return attempts ? 0 : -ETIMEDOUT;
>  }
>  
> +static void __fbnic_fw_evict_cmpl(struct fbnic_fw_completion *cmpl_data)
> +{
> +	cmpl_data->result = -EPIPE;
> +	complete(&cmpl_data->done);
> +}
> +
> +static void fbnic_mbx_evict_all_cmpl(struct fbnic_dev *fbd)
> +{
> +	struct fbnic_fw_completion *cmpl_data;
> +
> +	cmpl_data = fbd->cmpl_data;
> +	if (cmpl_data)
> +		__fbnic_fw_evict_cmpl(cmpl_data);
> +
> +	memset(&fbd->cmpl_data, 0, sizeof(fbd->cmpl_data));

Maybe I've been staring at my screen for too long, but could this
be expressed more succinctly as:

	fbd->cmpl_data = NULL;

And if so, it seems that step can be skipped if cmpl_data is already
NULL, which is already checked.

Leading to the following, which is somehow easier on my brain.

static void fbnic_mbx_evict_all_cmpl(struct fbnic_dev *fbd)
{
	if (fbd->cmpl_data) {
		__fbnic_fw_evict_cmpl(fbd->cmpl_data);
		fbd->cmpl_data = NULL;
	}
}

> +}
> +
>  void fbnic_mbx_flush_tx(struct fbnic_dev *fbd)
>  {
>  	unsigned long timeout = jiffies + 10 * HZ + 1;
> @@ -945,6 +962,9 @@ void fbnic_mbx_flush_tx(struct fbnic_dev *fbd)
>  	/* Read tail to determine the last tail state for the ring */
>  	tail = tx_mbx->tail;
>  
> +	/* Flush any completions as we are no longer processing Rx */
> +	fbnic_mbx_evict_all_cmpl(fbd);
> +
>  	spin_unlock_irq(&fbd->fw_tx_lock);
>  
>  	/* Give firmware time to process packet,
> @@ -983,7 +1003,7 @@ void fbnic_fw_init_cmpl(struct fbnic_fw_completion *fw_cmpl,
>  	kref_init(&fw_cmpl->ref_count);
>  }
>  
> -void fbnic_fw_clear_compl(struct fbnic_dev *fbd)
> +void fbnic_fw_clear_cmpl(struct fbnic_dev *fbd)
>  {
>  	unsigned long flags;
>  
> diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_fw.h b/drivers/net/ethernet/meta/fbnic/fbnic_fw.h
> index a3618e7826c2..2d5e0ff1982c 100644
> --- a/drivers/net/ethernet/meta/fbnic/fbnic_fw.h
> +++ b/drivers/net/ethernet/meta/fbnic/fbnic_fw.h
> @@ -69,7 +69,7 @@ int fbnic_fw_xmit_tsene_read_msg(struct fbnic_dev *fbd,
>  				 struct fbnic_fw_completion *cmpl_data);
>  void fbnic_fw_init_cmpl(struct fbnic_fw_completion *cmpl_data,
>  			u32 msg_type);
> -void fbnic_fw_clear_compl(struct fbnic_dev *fbd);
> +void fbnic_fw_clear_cmpl(struct fbnic_dev *fbd);
>  void fbnic_fw_put_cmpl(struct fbnic_fw_completion *cmpl_data);
>  
>  #define fbnic_mk_full_fw_ver_str(_rev_id, _delim, _commit, _str, _str_sz) \
> diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_mac.c b/drivers/net/ethernet/meta/fbnic/fbnic_mac.c
> index dde4a37116e2..7e54f82535f6 100644
> --- a/drivers/net/ethernet/meta/fbnic/fbnic_mac.c
> +++ b/drivers/net/ethernet/meta/fbnic/fbnic_mac.c
> @@ -744,7 +744,7 @@ static int fbnic_mac_get_sensor_asic(struct fbnic_dev *fbd, int id,
>  
>  	*val = *sensor;
>  exit_cleanup:
> -	fbnic_fw_clear_compl(fbd);
> +	fbnic_fw_clear_cmpl(fbd);
>  exit_free:
>  	fbnic_fw_put_cmpl(fw_cmpl);
>  
> 
> 
> 

  reply	other threads:[~2025-05-02 10:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-01 23:29 [net PATCH 0/6] fbnic: FW IPC Mailbox fixes Alexander Duyck
2025-05-01 23:29 ` [net PATCH 1/6] fbnic: Fix initialization of mailbox descriptor rings Alexander Duyck
2025-05-02 10:49   ` Simon Horman
2025-05-01 23:30 ` [net PATCH 2/6] fbnic: Gate AXI read/write enabling on FW mailbox Alexander Duyck
2025-05-02 10:50   ` Simon Horman
2025-05-01 23:30 ` [net PATCH 3/6] fbnic: Add additional handling of IRQs Alexander Duyck
2025-05-02 13:51   ` Simon Horman
2025-05-01 23:30 ` [net PATCH 4/6] fbnic: Actually flush_tx instead of stalling out Alexander Duyck
2025-05-02 10:54   ` Simon Horman
2025-05-01 23:30 ` [net PATCH 5/6] fbnic: Cleanup handling of completions Alexander Duyck
2025-05-02 10:45   ` Simon Horman [this message]
2025-05-04 14:37     ` Alexander Duyck
2025-05-01 23:30 ` [net PATCH 6/6] fbnic: Pull fbnic_fw_xmit_cap_msg use out of interrupt context Alexander Duyck
2025-05-02 16:54   ` Simon Horman
2025-05-04 14:53     ` Alexander Duyck
2025-05-06 15:50       ` Simon Horman

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=20250502104523.GH3339421@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).