From: Bart Van Assche <bart.vanassche@gmail.com>
To: Michael Chan <michael.chan@broadcom.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Jakub Kicinski <kuba@kernel.org>,
Shantiprasad Shettar <shantiprasad.shettar@broadcom.com>,
Stanislav Fomichev <sdf@fomichev.me>,
netdev@vger.kernel.org
Subject: Re: [PATCH 18/62] bnxt_en: Fix bnxt_dl_reload_up()
Date: Mon, 23 Feb 2026 14:56:53 -0800 [thread overview]
Message-ID: <637edf98-64b2-4a04-8fa9-4a4b791d7d53@gmail.com> (raw)
In-Reply-To: <CACKFLinqWm7wbdgES_gpYNhQiZJ0cv=w0zpra8rXF=3jMQ+BdA@mail.gmail.com>
On 2/23/26 2:37 PM, Michael Chan wrote:
> On Mon, Feb 23, 2026 at 2:27 PM Bart Van Assche
> <bart.vanassche@gmail.com> wrote:
>
>> My understanding is that bnxt_dl_reload_up() is only called if
>> bnxt_dl_reload_down() returns 0 (see also devlink_reload()).
>> bnxt_dl_reload_up() returns an error code (-EOPNOTSUPP) for other
>> actions than DEVLINK_RELOAD_ACTION_DRIVER_REINIT or
>> DEVLINK_RELOAD_ACTION_FW_ACTIVATE. Hence, bnxt_dl_reload_up() is only
>> called if "action" is either DEVLINK_RELOAD_ACTION_DRIVER_REINIT or
>> DEVLINK_RELOAD_ACTION_FW_ACTIVATE. In other words, the code in the
>> "default" clause will never be reached. So I think the above change is
>> correct but also that the patch description should be modified to
>> reflect that this is not a bug fix. Did I perhaps misunderstand
>> something?
>>
> Yes, your description is correct. So perhaps a better cleanup would
> be to remove the default case in bnxt_dl_reload_up()? Thanks.
Hmm ... wouldn't that trigger a -Wswitch warning, a warning that is
enabled by default for kernel code? From the gcc documentation:
"Warn whenever a switch statement has an index of enumerated type and
lacks a case for one or more of the named codes of that enumeration.
(The presence of a default label prevents this warning.) case labels
that do not correspond to enumerators also provoke warnings when this
option is used, unless the enumeration is marked with the flag_enum
attribute. This warning is enabled by -Wall."
Changing "default: return -EOPNOTSUPP;" into "default: BUG();" keeps
the Clang thread-sanitizer happy but does not comply with the kernel
coding style. Does the patch below look better?
Thanks,
Bart.
bnxt_en: Suppress thread-safety complaints about bnxt_dl_reload_up()
bnxt_dl_reload_down() returns an error code for actions that are not
supported. Hence, bnxt_dl_reload_up() won't be called for unsupported
actions. Since the compiler doesn't know this, add unlock calls to the
default clause. This patch suppresses a Clang thread-sanitizer
complaint. Compile-tested only.
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Shantiprasad Shettar <shantiprasad.shettar@broadcom.com>
Cc: Stanislav Fomichev <sdf@fomichev.me>
Cc: netdev@vger.kernel.org
Fixes: 004b5008016a ("eth: bnxt: remove most dependencies on RTNL")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 15de802bbac4..aa7ebd1426ed 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -562,6 +562,13 @@ static int bnxt_dl_reload_up(struct devlink *dl,
enum devlink_reload_action acti
break;
}
default:
+ /*
+ * Other actions have already been rejected by
+ * bnxt_dl_reload_down().
+ */
+ WARN_ON_ONCE(true);
+ netdev_unlock(bp->dev);
+ rtnl_unlock();
return -EOPNOTSUPP;
}
next prev parent reply other threads:[~2026-02-23 22:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260223214950.2153735-1-bvanassche@acm.org>
2026-02-23 21:49 ` [PATCH 17/62] bnxt_en: Make bnxt_resume() easier to analyze Bart Van Assche
2026-02-23 22:23 ` Jakub Kicinski
2026-02-23 22:24 ` Jakub Kicinski
2026-02-23 22:30 ` Bart Van Assche
2026-02-23 21:49 ` [PATCH 18/62] bnxt_en: Fix bnxt_dl_reload_up() Bart Van Assche
2026-02-23 22:17 ` Michael Chan
2026-02-23 22:27 ` Bart Van Assche
2026-02-23 22:37 ` Michael Chan
2026-02-23 22:56 ` Bart Van Assche [this message]
2026-02-23 23:42 ` Michael Chan
2026-02-23 21:49 ` [PATCH 20/62] octeontx2-pf: Fix locking in an error path Bart Van Assche
2026-02-23 21:49 ` [PATCH 21/62] qed: Make _qed_mcp_cmd_and_union() easier to analyze Bart Van Assche
2026-02-23 21:49 ` [PATCH 22/62] mctp i3c: Fix locking in error paths Bart Van Assche
[not found] <20260223215118.2154194-1-bvanassche@acm.org>
2026-02-23 21:50 ` [PATCH 18/62] bnxt_en: Fix bnxt_dl_reload_up() Bart Van Assche
[not found] <20260223220102.2158611-1-bart.vanassche@linux.dev>
2026-02-23 22:00 ` Bart Van Assche
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=637edf98-64b2-4a04-8fa9-4a4b791d7d53@gmail.com \
--to=bart.vanassche@gmail.com \
--cc=kuba@kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sdf@fomichev.me \
--cc=shantiprasad.shettar@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