Re: [PATCH net-next V5 6/6] net/mlx5: Apply devlink eswitch mode boot default on probe
From: Jiri Pirko <jiri@resnulli.us>
Date: 2026-07-08 08:34:59
Also in:
linux-doc, linux-rdma
Tue, Jul 07, 2026 at 07:45:27PM +0200, mbloch@nvidia.com wrote:
quoted hunk ↗ jump to hunk
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