From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 60E8E19DF62; Sat, 8 Nov 2025 05:38:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762580314; cv=none; b=N8/g90y+PQPgViOrQT166Eg+mUukt9D87THnn8McP6zmV6YoimxCEdlbUBPqPGsd8IJEJt6x/cgG7Cen3Jn//5yINquLJC5nNHXpOH9OGjl5p20YkXyrf68u3EDVR3lkt2a24AwJ08ENgVC2yP0noO29WNXzPTYifI7xlcADVfE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762580314; c=relaxed/simple; bh=w6GXV8F8qq8Ivlsip/h/QX7gHcMdkkyqZQffmsH93Go=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oGo0f2+Ys6FOeruPJqU1Lku63wnfEHbwk7+hTV94xHRXOj5Sr9NXyVUS3suQWg3xDsV1sxHqeEQrxCYDdslbmrn1l1AsAtDKYYiYiodfxBC5FpTVDc2bJxj+ifiV+VoWlaRq5qUMck/ElPlU23wjfaya0I3tX77nmsf9M6lDzxg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R6rzkZ9a; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R6rzkZ9a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC516C19422; Sat, 8 Nov 2025 05:38:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762580313; bh=w6GXV8F8qq8Ivlsip/h/QX7gHcMdkkyqZQffmsH93Go=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=R6rzkZ9aOnGt/EQ9R93dim8mBYYjOjakJehQ5+rN7x3rvkrZwgPe3DNMNBLOS6Sh4 mImZKwWN8OxH6gjwHfbPpky8S4xfaMEw4jAyYKPEkT3ztoZqWXNpmZBCg3s9GW11DH ubqLYGlFVZD9/bwsgi4HUeIL+tGoVZRpcmwSzbCHe4/tKN/YY1WJFNFfWmJhYpQvYq aLmPydUhP1j4nb/QPh4Bpfzi2TidyWlqi7OIYoBoMGpHxUbV0BbBU/eCT9rJf0d0LI UGX4tJ2pBMvLkxAGG5WdK5NuaGVKDGXY0wPCPhO3ZVQAVKzkoatva84A/KHH/1yljJ uT5/heaaQlZPQ== Date: Fri, 7 Nov 2025 21:38:32 -0800 From: Saeed Mahameed To: Daniel Zahka Cc: Jiri Pirko , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Srujana Challa , Bharat Bhushan , Herbert Xu , Brett Creeley , Andrew Lunn , Michael Chan , Pavan Chebbi , Tony Nguyen , Przemek Kitszel , Sunil Goutham , Linu Cherian , Geetha sowjanya , Jerin Jacob , hariprasad , Subbaraya Sundeep , Tariq Toukan , Saeed Mahameed , Leon Romanovsky , Mark Bloch , Ido Schimmel , Petr Machata , Manish Chopra , Maxime Coquelin , Alexandre Torgue , Siddharth Vadapalli , Roger Quadros , Loic Poulain , Sergey Ryazanov , Johannes Berg , Vladimir Oltean , Michal Swiatkowski , Aleksandr Loktionov , Dave Ertman , Vlad Dumitrescu , "Russell King (Oracle)" , Alexander Sverdlin , Lorenzo Bianconi , netdev@vger.kernel.org, linux-doc@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-rdma@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org Subject: Re: [PATCH net-next v2 2/2] net/mlx5: implement swp_l4_csum_mode via devlink params Message-ID: References: <20251103194554.3203178-1-daniel.zahka@gmail.com> <20251103194554.3203178-3-daniel.zahka@gmail.com> <6aa2f011-3ba5-4614-950d-d8f0ec62222b@gmail.com> <78db1fab-e482-4ebc-82ce-ba84b3f561e2@gmail.com> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <78db1fab-e482-4ebc-82ce-ba84b3f561e2@gmail.com> On 04 Nov 09:48, Daniel Zahka wrote: > > >On 11/4/25 9:39 AM, Jiri Pirko wrote: >>Tue, Nov 04, 2025 at 01:51:16PM +0100, daniel.zahka@gmail.com wrote: >>> >>>On 11/4/25 6:38 AM, Daniel Zahka wrote: >>>> >>>>On 11/4/25 5:14 AM, Jiri Pirko wrote: >>>>>I did some research. 0/DEVICE_DEFAULT should not be ever reported back >>>>>from FW. It's purpose is for user to reset to default FW configuration. >>>>>What's the usecase for that? I think you could just avoid >>>>>0/DEVICE_DEFAULT entirely, for both get and set. >>>>I find that 0/DEVICE_DEFAULT is reported back on my device. I have >>>>observed this same behavior when using the mstconfig tool for setting the >>>>parameter too. >>>e.g. >>>$ dmesg | grep -i mlx | grep -i firmware >>>[   10.165767] mlx5_core 0000:01:00.0: firmware version: 28.46.1006 >>> >>>$ ./mstconfig -d 01:00.0 -b ./mlxconfig_host.db query SWP_L4_CHECKSUM_MODE >>> >>>Device #1: >>>---------- >>> >>>Device type:        ConnectX7 >>>Name:               CX71143DMC-CDAE_FB_Ax >>>Description:        ConnectX-7 Ethernet adapter card; 100 GbE OCP3.0; >>>Single-port QSFP; Multi Host; 2 Host; PCIe 4.0 x16; Crypto and Secure Boot >>>Device:             01:00.0 >>> >>>Configurations:                                          Next Boot >>>         SWP_L4_CHECKSUM_MODE DEVICE_DEFAULT(0) >>This is next-boot value. You should query current (--enable_verbosity) >>to show in param get. > >I am still seeing that DEVICE_DEFAULT(0) is read back: > >$ ./mstconfig --enable_verbosity -d 01:00.0 -b ./mlxconfig_host.db >query SWP_L4_CHECKSUM_MODE > >Device #1: >---------- > >Device type:        ConnectX7 >Name:               CX71143DMC-CDAE_FB_Ax >Description:        ConnectX-7 Ethernet adapter card; 100 GbE OCP3.0; >Single-port QSFP; Multi Host; 2 Host; PCIe 4.0 x16; Crypto and Secure >Boot >Device:             01:00.0 > >Configurations:                  Default             Current       Next Boot >        SWP_L4_CHECKSUM_MODE DEVICE_DEFAULT(0) DEVICE_DEFAULT(0)    >DEVICE_DEFAULT(0) > When default value of nvconfig is managed by FW, 0 will always mean DEVICE_DEFAULT, and it is a way for the driver to reset back to default on write, but on read FW should never return it, so this is a FW bug. But this shouldn't block this series so just return 'default', from the driver perspective we should return 'default' when we know 0 means that.