From: Jiri Pirko <jiri@resnulli.us>
To: Mark Bloch <mbloch@nvidia.com>
Cc: Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
Tariq Toukan <tariqt@nvidia.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH net-next V5 6/6] net/mlx5: Apply devlink eswitch mode boot default on probe
Date: Wed, 8 Jul 2026 10:34:54 +0200 [thread overview]
Message-ID: <ak4LVcyKofmtrWcU@FV6GYCPJ69> (raw)
In-Reply-To: <20260707174527.425134-7-mbloch@nvidia.com>
Tue, Jul 07, 2026 at 07:45:27PM +0200, mbloch@nvidia.com wrote:
>Apply devlink_eswitch_mode= boot defaults for mlx5 after the initial
>probe finishes device initialization while holding the devlink instance
>lock.
>
>At this point the devlink instance is registered and mlx5 can perform an
>eswitch mode change. Calling devl_apply_default_esw_mode() also clears
>any pending default apply work queued by devl_register(), so the queued
>work will not apply the same default again.
>
>Keep this call in mlx5_init_one() rather than the lower-level
>devl-locked init helper. That helper is also used by devlink reload, and
>devlink core already applies the boot default after a successful
>DRIVER_REINIT reload.
>
>Signed-off-by: Mark Bloch <mbloch@nvidia.com>
>---
> drivers/net/ethernet/mellanox/mlx5/core/main.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>index 643b4aac2033..0712efea74cc 100644
>--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
>+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>@@ -1392,6 +1392,17 @@ static void mlx5_unload(struct mlx5_core_dev *dev)
> mlx5_free_bfreg(dev, &dev->priv.bfreg);
> }
>
>+static void mlx5_devl_apply_default_esw_mode(struct mlx5_core_dev *dev)
>+{
>+ struct devlink *devlink = priv_to_devlink(dev);
>+
>+ if (!MLX5_ESWITCH_MANAGER(dev))
>+ return;
>+
>+ devl_assert_locked(devlink);
>+ devl_apply_default_esw_mode(devlink);
>+}
>+
> int mlx5_init_one_devl_locked(struct mlx5_core_dev *dev)
> {
> bool light_probe = mlx5_dev_is_lightweight(dev);
>@@ -1471,6 +1482,8 @@ int mlx5_init_one(struct mlx5_core_dev *dev)
> err = mlx5_init_one_devl_locked(dev);
> if (err)
> devl_unregister(devlink);
>+ else
>+ mlx5_devl_apply_default_esw_mode(dev);
I don't understand why this patch is needed at all. Just leave the job
to the devlink core, no? That was the point to not pollute drivers with
code like this. Is it some kind of leftover?
> unlock:
> devl_unlock(devlink);
> return err;
>--
>2.43.0
>
prev parent reply other threads:[~2026-07-08 8:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 17:45 [PATCH net-next V5 0/6] devlink: Add boot-time eswitch mode defaults Mark Bloch
2026-07-07 17:45 ` [PATCH net-next V5 1/6] net/mlx5: Clear FW reset-in-progress bit before reload Mark Bloch
2026-07-07 17:45 ` [PATCH net-next V5 2/6] devlink: Factor out eswitch mode setting Mark Bloch
2026-07-07 17:45 ` [PATCH net-next V5 3/6] devlink: Parse eswitch mode boot defaults Mark Bloch
2026-07-07 17:45 ` [PATCH net-next V5 4/6] devlink: Apply " Mark Bloch
2026-07-08 8:59 ` Jiri Pirko
2026-07-07 17:45 ` [PATCH net-next V5 5/6] devlink: Add API to apply eswitch mode boot default Mark Bloch
2026-07-07 17:45 ` [PATCH net-next V5 6/6] net/mlx5: Apply devlink eswitch mode boot default on probe Mark Bloch
2026-07-08 8:34 ` Jiri Pirko [this message]
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=ak4LVcyKofmtrWcU@FV6GYCPJ69 \
--to=jiri@resnulli.us \
--cc=andrew+netdev@lunn.ch \
--cc=corbet@lwn.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=skhan@linuxfoundation.org \
--cc=tariqt@nvidia.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