From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F19A442DFE9 for ; Thu, 5 Feb 2026 15:57:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770307038; cv=none; b=PrAWID2mxHl6Iuru5xRWMWiGTCm8j+7LqH16z0CE3O0ULN+kwkpLfQCtEeovsJHaAj98CtfGBpJQJzDURvlXvyKJjcfawJB32C0+jQCLlPfHD4VVDZfE74gb1TAc6ynAGduNRe71Bf3yzp5mvw6imwlu/hu5Zsk4GEtRPtBeClQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770307038; c=relaxed/simple; bh=uTFRtOzk76BST5VS+Lip0kikkOj/ahnj2fnN6yMO73E=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Gq7tivvmeBN2JP5geYBhAKtpnoMGxT9o/a4kv+GAlkEblpO5mDrA5dQEzIkH+NvcVWZZ7l/JBz0HxW2+s149UpVMmyh2VlNHRpiCZQTVpD8i9T3yBiUjBU3TWQlQEtgYyWAsd6Tdw4DpuLOpyyUrhgBC/M3lDziCG8ytpIVQO68= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=UNIuxJrM; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=dgbWmAbY; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UNIuxJrM"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="dgbWmAbY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770307037; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XGSaW/PyR/xsnHgTVbJJStPR08qCT++OSZAv5+zvB4U=; b=UNIuxJrMl9zP02FOvl+6iftR6gv6vy5VwfffWz+Vf1lDPDd24PBI8hkccpv7m/xl0E9p6c Fkd7lxSuf69T2dE2ejkR2A7lXh8bOmJEHC/QdoEDn9VwPAVqKshWx1Y6uzMCLt7DsNFIhj GiKnFMNsmqj+l9da81AKIqSFskCFj8c= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-670-758ARw4eN5GDNAkHFB-ktA-1; Thu, 05 Feb 2026 10:57:11 -0500 X-MC-Unique: 758ARw4eN5GDNAkHFB-ktA-1 X-Mimecast-MFC-AGG-ID: 758ARw4eN5GDNAkHFB-ktA_1770307030 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-4325aa61c6bso915868f8f.0 for ; Thu, 05 Feb 2026 07:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770307030; x=1770911830; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=XGSaW/PyR/xsnHgTVbJJStPR08qCT++OSZAv5+zvB4U=; b=dgbWmAbYlKzwSfbmf78zJpF09VHdVBYZEzjC5ZHT9mWYLjPS9weLCBVCyszJt0jK+a yH2+z4HTH9TRSMqv6sFAvT+VKe4ua3yh+2G95PcGFLRaKbO/bJhHd0feTDJ8RXHPPsDQ 7QMnLd9x9lvzXsDLVHx9ks9Uol4zwtZydJswksL7Ldj/uzecd1dSJ0arOmnt5Zr6ZmtA yfTV+7d2YVyDMWwvH/VBTifM2JUNyYbxnQ+lY76jQZFTcYwW5uQUSC9iAbwZ6XYWKhZn Eb8iPn54JjRIhBKyiCxS/JbzXFDWxeZe/AKSjDF97tCZgua1UBqCCJ5L8RKC1qJeFj+G XsYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770307030; x=1770911830; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XGSaW/PyR/xsnHgTVbJJStPR08qCT++OSZAv5+zvB4U=; b=evHp86BGZHu9lfdGIyQKIrrqTn4+UMKGzZRURs+zicviGF9kkEgyvmDdbacCpeIzwB ZjLQGxwxVfbenCK6q4NjmsMWAg0Qsamrka//1Nqw58uH2ToMYrLjENO9tPcn3D8A5wk+ JQnZCsmfNTD931QIM4uzCdCVnPAjEiF+Unn3SP2axuBJHuHDXZ7lPzIlJSnx5yDX0nfp rSN/ltwgZGoBuhvJ7IJlrvkaIZJOhWEy2TiUI7ykDTrJaqghgrAICA2ToMnamFhvHClC nn+5rsjHIogEhPUlMRN2e6KCVr+yRfCfOO7PbnFS1QP0ttfoGhUbZo2tV1jsoXQc3RDV GsHA== X-Forwarded-Encrypted: i=1; AJvYcCXrs3Nx6rq38qL6lSxYorh9q6V9+Ps9nSA8QssVUS5XvHKtxnIeOFnfsOTqm8WYswr4DJaZXC+cNAMwUCA=@vger.kernel.org X-Gm-Message-State: AOJu0YwJzi0Dv/DUkzmTqE+/08xIzPXunQyLm68Yf9E3mEKAzIIO6L0c /czp79Y/4geYGt9HoVxPWUmtlJAaG4p77wOYnzceAvD5Bz+oglI58nC3o8YJm2kMRrMNv7s+pUa 6Hmw9t8jwRChjew69Wby1AjJMJDJzh71rBbC9N4nx9AzFzHEoYzY+SMWSberfYQOi9w== X-Gm-Gg: AZuq6aLv15ggI3Ui0NYNluEwqGleMyDg0uu63yHOxuWf561/kU87esp+9r8GoCtFssr /8iS/n8cSeiRIgxgZ/XtiugksrzrapZ65uE0QwPxpxBFE8Frswwz3e5aI9dMHORp+jUbGz9Thre kqDICT7P3QuFsxPc29AQGzxaCQ8HhFp24SGc8LPTW2VJvX5KzkYSyc4i6ujkK6GtdioYtPTOlDS ampVZ65dFaWWwKhewmu7NNGukHSGNt1b/MZhH5wWxAjsvEjV07Y3eJc9l4LvdblbteN0Bp4vCt5 V8vsWa2Ri5F6l0aKnfl/94nqqPWJczGzTR1e688ho9eVIjtiZm9oWUMcwCHlkXpRu1GpxCNYH5Q u+2psyBgzMnTG X-Received: by 2002:a05:6000:1ac7:b0:435:a647:a3b8 with SMTP id ffacd0b85a97d-43618055314mr10647375f8f.36.1770307029632; Thu, 05 Feb 2026 07:57:09 -0800 (PST) X-Received: by 2002:a05:6000:1ac7:b0:435:a647:a3b8 with SMTP id ffacd0b85a97d-43618055314mr10647335f8f.36.1770307029161; Thu, 05 Feb 2026 07:57:09 -0800 (PST) Received: from [192.168.88.32] ([216.128.11.114]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43617e3a546sm17453676f8f.17.2026.02.05.07.57.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Feb 2026 07:57:08 -0800 (PST) Message-ID: <722cba76-363e-4273-8150-2b50c9f591a5@redhat.com> Date: Thu, 5 Feb 2026 16:57:06 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next] net/mlx5: Support devlink port state for host PF To: Tariq Toukan , Eric Dumazet , Jakub Kicinski , Andrew Lunn , "David S. Miller" Cc: Saeed Mahameed , Leon Romanovsky , Mark Bloch , netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Gal Pressman , Moshe Shemesh , Or Har-Toov , Jiri Pirko , Parav Pandit References: <20260203102402.1712218-1-tariqt@nvidia.com> Content-Language: en-US From: Paolo Abeni In-Reply-To: <20260203102402.1712218-1-tariqt@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/3/26 11:24 AM, Tariq Toukan wrote: > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c > index 4b7a1ce7f406..5fbfabe28bdb 100644 > --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c > +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c > @@ -1304,24 +1304,52 @@ static int mlx5_eswitch_load_ec_vf_vports(struct mlx5_eswitch *esw, u16 num_ec_v > return err; > } > > -static int host_pf_enable_hca(struct mlx5_core_dev *dev) > +int mlx5_esw_host_pf_enable_hca(struct mlx5_core_dev *dev) > { > - if (!mlx5_core_is_ecpf(dev)) > + struct mlx5_eswitch *esw = dev->priv.eswitch; > + struct mlx5_vport *vport; > + int err; > + > + if (!mlx5_core_is_ecpf(dev) || !mlx5_esw_allowed(esw)) > return 0; I was able to miss the AI feedback here: --- The old host_pf_enable_hca() only checked mlx5_core_is_ecpf(dev) before calling mlx5_cmd_host_pf_enable_hca(). The new function adds a check for mlx5_esw_allowed(esw), which returns false when esw is NULL or when the device is not an eswitch manager. When called from mlx5_host_pf_init() in ecpf.c on an ECPF device that is not an eswitch manager (the path when mlx5_ecpf_esw_admins_host_pf() returns false), this new condition will cause the function to return 0 without enabling the HCA. Is this behavior change intentional? The old code would enable the HCA in this configuration, but the new code skips it. The same concern applies to mlx5_esw_host_pf_disable_hca() below. --- and indeed it looks relevant. I think you have to follow-up or send a revert, whatever it's easier/faster. > @@ -1347,7 +1375,7 @@ mlx5_eswitch_enable_pf_vf_vports(struct mlx5_eswitch *esw, > > if (mlx5_esw_host_functions_enabled(esw->dev)) { > /* Enable external host PF HCA */ > - ret = host_pf_enable_hca(esw->dev); > + ret = mlx5_esw_host_pf_enable_hca(esw->dev); Just FTR, more AI feedback here: --- The old host_pf_disable_hca() was a void function. The new mlx5_esw_host_pf_disable_hca() returns int and can fail, but the return value is not checked here in the error path. If mlx5_esw_host_pf_disable_hca() fails, it returns without setting vport->pf_activated = false. This leaves pf_activated set to true even though the HCA state may be inconsistent. Later, mlx5_devlink_pf_port_fn_state_get() reads vport->pf_activated to report state to userspace, which could then report incorrect state. Should the return value be checked, or should the pf_activated flag be updated unconditionally to reflect the intended state? The same pattern appears in mlx5_eswitch_disable_pf_vf_vports(). ---