From: Jakub Kicinski <kuba@kernel.org>
To: eric.joyner@amd.com
Cc: Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, brett.creeley@amd.com,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com
Subject: Re: [PATCH net-next v2 1/5] ionic: Small improvements in devcmd retry logic
Date: Fri, 8 May 2026 15:55:08 -0700 [thread overview]
Message-ID: <20260508225508.3420208-1-kuba@kernel.org> (raw)
In-Reply-To: <20260506043526.64301-2-eric.joyner@amd.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
ionic: Small improvements in devcmd retry logic
This commit aims to preserve the -EAGAIN error code when a device command
times out on its final retry. It also reduces the sleep time between retries
from 1000ms to 50ms to allow more attempts before timing out.
> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_main.c b/drivers/net/ethernet/pensando/ionic/ionic_main.c
> index 3c5200e2fdb7d..92f2ec0bd5af9 100644
> --- a/drivers/net/ethernet/pensando/ionic/ionic_main.c
> +++ b/drivers/net/ethernet/pensando/ionic/ionic_main.c
> @@ -554,6 +554,11 @@ static int __ionic_dev_cmd_wait(struct ionic *ionic, unsigned long max_seconds,
>
> if (!done && !time_before(jiffies, max_wait)) {
> ionic_dev_cmd_clean(ionic);
> +
> + /* allow caller to manage EAGAIN from previous attempt */
> + if (err == IONIC_RC_EAGAIN)
> + return -EAGAIN;
Could err be uninitialized here?
Looking at __ionic_dev_cmd_wait(), err is declared at the start of the
function but is not assigned until later via ionic_dev_cmd_status(). If the
initial wait loop times out on the very first attempt (for example, if the
firmware is unresponsive or the system stalls), execution falls through to
this block. Checking err here would read an uninitialized stack variable,
potentially leading to unpredictable driver initialization behavior.
> +
> dev_warn(ionic->dev, "DEVCMD %s (%d) timeout after %ld secs\n",
> ionic_opcode_to_str(opcode), opcode, max_seconds);
> return -ETIMEDOUT;
[ ... ]
> @@ -568,7 +573,7 @@ static int __ionic_dev_cmd_wait(struct ionic *ionic, unsigned long max_seconds,
> ionic_error_to_str(err), err);
>
> iowrite32(0, &idev->dev_cmd_regs->done);
> - msleep(1000);
> + msleep(50);
Does this logic abandon retries prematurely?
The surrounding retry condition still requires at least one full second of
remaining time:
if (err == IONIC_RC_EAGAIN &&
time_before(jiffies, (max_wait - HZ))) {
The - HZ check was likely originally added to ensure there was enough time
left for the 1000ms sleep. Now that the sleep is reduced to 50ms, requiring
a full second of remaining time means the driver will abort retries during
the final second of the timeout. If max_seconds is small, it may not retry
at all, which seems to contradict the intent of increasing the number of
retries.
> iowrite32(1, &idev->dev_cmd_regs->doorbell);
> goto try_again;
> }
--
pw-bot: cr
next prev parent reply other threads:[~2026-05-08 22:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 4:35 [PATCH net-next v2 0/5] Expose more port stats to ethtool Eric Joyner
2026-05-06 4:35 ` [PATCH net-next v2 1/5] ionic: Small improvements in devcmd retry logic Eric Joyner
2026-05-08 22:55 ` Jakub Kicinski [this message]
2026-05-06 4:35 ` [PATCH net-next v2 2/5] ionic: Get "link_down_count" ext link stat from firmware Eric Joyner
2026-05-08 22:54 ` Jakub Kicinski
2026-05-08 22:55 ` Jakub Kicinski
2026-05-06 4:35 ` [PATCH net-next v2 3/5] ionic: Update ionic_if.h with new extra port stats structure Eric Joyner
2026-05-06 4:35 ` [PATCH net-next v2 4/5] ionic: Report rx_bits_phy stat to ethtool Eric Joyner
2026-05-06 4:35 ` [PATCH net-next v2 5/5] ionic: Add .get_fec_stats ethtool handler Eric Joyner
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=20260508225508.3420208-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=brett.creeley@amd.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.joyner@amd.com \
--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