From: Joe Damato <joe@dama.to>
To: netdev@vger.kernel.org, Michael Chan <michael.chan@broadcom.com>,
Pavan Chebbi <pavan.chebbi@broadcom.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>,
Prashant Sreedharan <prashant@broadcom.com>
Cc: edumazet@google.com, horms@kernel.org,
linux-kernel@vger.kernel.org, Joe Damato <joe@dama.to>
Subject: [RFC net v4 2/4] bnxt_en: check HWRM response if completion never arrives
Date: Fri, 25 Sep 2026 10:43:59 -0700 [thread overview]
Message-ID: <20260925174404.2789072-3-joe@dama.to> (raw)
In-Reply-To: <20260925174404.2789072-1-joe@dama.to>
When a command is sent over a completion ring, __hwrm_send() waits for
NAPI to consume the completion and gives up if it never arrives, without
looking at the response.
If a completion is not posted within the timeout, check the response
before giving up. If resp_len is set, the sequence id matches, and the
valid byte is set then the firmware completed the command and only the
notification was lost. Fall through to the normal error_code handling in
that case.
Several seconds are spent waiting for the completion, so a response that
was written at all is complete by the time the wait gives up. There is no
need to poll for the valid byte here the way the polling path below has
to, where the poll is for a non-zero length and the valid byte at the end
of the message may still be on its way.
Log the response state on both paths so there is more data when this rare
event occurs.
Fixes: 74608fc98d28 ("bnxt_en: Ring free response from close path should use completion ring")
Signed-off-by: Joe Damato <joe@dama.to>
---
.../net/ethernet/broadcom/bnxt/bnxt_hwrm.c | 33 ++++++++++++++++---
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c
index 5bfabdca7d0e..4feba90f0bf6 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c
@@ -582,11 +582,36 @@ static int __hwrm_send(struct bnxt *bp, struct bnxt_hwrm_ctx *ctx)
}
if (READ_ONCE(token->state) != BNXT_HWRM_COMPLETE) {
- hwrm_err(bp, ctx, "Resp cmpl intr err msg: 0x%x\n",
- req_type);
- goto exit;
+ __le16 resp_seq_id;
+ u8 valid_byte = 0;
+
+ /* The completion ring entry was not delivered for
+ * some reason. It might be possible that the command
+ * was carried out even without a completion being
+ * posted. Check the response before giving up and log
+ * the state.
+ */
+ dma_rmb();
+ resp_seq_id = READ_ONCE(ctx->resp->seq_id);
+ len = le16_to_cpu(READ_ONCE(ctx->resp->resp_len));
+ if (len && resp_seq_id == ctx->req->seq_id)
+ valid_byte = *((u8 *)ctx->resp + len - 1);
+
+ if (!valid_byte) {
+ hwrm_err(bp, ctx,
+ "Resp cmpl intr err msg: 0x%x len:%d seq:0x%x/0x%x\n",
+ req_type, len,
+ le16_to_cpu(resp_seq_id),
+ le16_to_cpu(ctx->req->seq_id));
+ goto exit;
+ }
+ netdev_warn(bp->dev,
+ "Resp cmpl intr not delivered, msg: 0x%x completed anyway (len:%d valid:0x%x err:0x%x)\n",
+ req_type, len, valid_byte,
+ le16_to_cpu(ctx->resp->error_code));
+ } else {
+ len = le16_to_cpu(READ_ONCE(ctx->resp->resp_len));
}
- len = le16_to_cpu(READ_ONCE(ctx->resp->resp_len));
valid = ((u8 *)ctx->resp) + len - 1;
} else {
__le16 seen_out_of_seq = ctx->req->seq_id; /* will never see */
--
2.53.0-Meta
next prev parent reply other threads:[~2026-09-25 17:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 17:43 [RFC net v4 0/4] bnxt_en: Make RING FREE more robust Joe Damato
2026-09-25 17:43 ` [RFC net v4 1/4] bnxt_en: return the RING_FREE status to callers Joe Damato
2026-09-25 17:43 ` Joe Damato [this message]
2026-09-25 17:44 ` [RFC net v4 3/4] bnxt_en: stop DMA before releasing rings the firmware did not free Joe Damato
2026-09-25 17:44 ` [RFC net v4 4/4] bnxt_en: refuse to open a device with stopped DMA Joe Damato
2026-09-29 0:20 ` Joe Damato
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=20260925174404.2789072-3-joe@dama.to \
--to=joe@dama.to \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=prashant@broadcom.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
all inboxes | Powered by JetHome®