[PATCH] common/mlx5: avoid warning about operation mixing different enum types

[PATCH] common/mlx5: avoid warning about operation mixing different enum types

[Andre Muezerie]

When compiling with MSVC, warnings like the one below pop up:

../drivers/common/mlx5/mlx5_devx_cmds.c(554): warning C5287: operands
    are different enum types
    '<unnamed-enum-MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE>' and
    '<unnamed-enum-MLX5_HCA_CAP_OPMOD_GET_MAX>'; use an explicit cast
    to silence this warning

The values in both enums indicate that this sort of mixed bit
manipulation is intentional, so this patch just uses an explicit
cast to avoid the warning.

Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
---
 drivers/common/mlx5/mlx5_devx_cmds.c | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/common/mlx5/mlx5_devx_cmds.c b/drivers/common/mlx5/mlx5_devx_cmds.c
index 39a4298b58..1a3f4580d8 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.c
+++ b/drivers/common/mlx5/mlx5_devx_cmds.c
@@ -552,7 +552,7 @@ mlx5_devx_cmd_query_hca_vdpa_attr(void *ctx,
 
 	hcattr = mlx5_devx_get_hca_cap(ctx, in, out, NULL,
 			MLX5_GET_HCA_CAP_OP_MOD_VDPA_EMULATION |
-			MLX5_HCA_CAP_OPMOD_GET_CUR);
+			(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 	if (!hcattr) {
 		DRV_LOG(DEBUG, "Failed to query devx VDPA capabilities");
 		vdpa_attr->valid = 0;
@@ -851,7 +851,7 @@ mlx5_devx_cmd_query_hca_parse_graph_node_cap
 
 	hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
 			MLX5_GET_HCA_CAP_OP_MOD_PARSE_GRAPH_NODE_CAP |
-			MLX5_HCA_CAP_OPMOD_GET_CUR);
+			(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 	if (!hcattr)
 		return rc;
 	attr->node_in = MLX5_GET(parse_graph_node_cap, hcattr, node_in);
@@ -884,7 +884,7 @@ mlx5_devx_cmd_query_hca_parse_graph_node_cap
 	/* Get the max supported samples from HCA CAP 2 */
 	hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
 			MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE_2 |
-			MLX5_HCA_CAP_OPMOD_GET_CUR);
+			(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 	if (!hcattr)
 		return rc;
 	attr->max_num_prog_sample =
@@ -943,7 +943,7 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
 
 	hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
 			MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE |
-			MLX5_HCA_CAP_OPMOD_GET_CUR);
+			(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 	if (!hcattr)
 		return rc;
 	hca_cap_2_sup = MLX5_GET(cmd_hca_cap, hcattr, hca_cap_2);
@@ -1127,7 +1127,7 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
 		MLX5_GET(cmd_hca_cap, hcattr, aes_xts_single_block_le_tweak);
 		hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
 				MLX5_GET_HCA_CAP_OP_MOD_CRYPTO |
-				MLX5_HCA_CAP_OPMOD_GET_CUR);
+				(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 		if (!hcattr)
 			return -1;
 		attr->crypto_wrapped_import_method = !!(MLX5_GET(crypto_caps,
@@ -1152,7 +1152,7 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
 	if (hca_cap_2_sup) {
 		hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
 				MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE_2 |
-				MLX5_HCA_CAP_OPMOD_GET_CUR);
+				(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 		if (!hcattr) {
 			DRV_LOG(DEBUG,
 				"Failed to query DevX HCA capabilities 2.");
@@ -1193,7 +1193,7 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
 	if (attr->qos.sup) {
 		hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
 				MLX5_GET_HCA_CAP_OP_MOD_QOS_CAP |
-				MLX5_HCA_CAP_OPMOD_GET_CUR);
+				(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 		if (!hcattr) {
 			DRV_LOG(DEBUG, "Failed to query devx QOS capabilities");
 			return rc;
@@ -1229,7 +1229,7 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
 	/* Query Flow Sampler Capability From FLow Table Properties Layout. */
 	hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
 			MLX5_GET_HCA_CAP_OP_MOD_NIC_FLOW_TABLE |
-			MLX5_HCA_CAP_OPMOD_GET_CUR);
+			(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 	if (!hcattr) {
 		attr->log_max_ft_sampler_num = 0;
 		return rc;
@@ -1286,7 +1286,7 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
 	/* Query HCA offloads for Ethernet protocol. */
 	hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
 			MLX5_GET_HCA_CAP_OP_MOD_ETHERNET_OFFLOAD_CAPS |
-			MLX5_HCA_CAP_OPMOD_GET_CUR);
+			(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 	if (!hcattr) {
 		attr->eth_net_offloads = 0;
 		return rc;
@@ -1355,7 +1355,7 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
 	if (attr->wqe_based_flow_table_sup) {
 		hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
 				MLX5_GET_HCA_CAP_OP_MOD_WQE_BASED_FLOW_TABLE |
-				MLX5_HCA_CAP_OPMOD_GET_CUR);
+				(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 		if (!hcattr) {
 			DRV_LOG(DEBUG, "Failed to query WQE Based Flow table capabilities");
 			return rc;
@@ -1378,7 +1378,7 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
 	if (attr->roce) {
 		hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
 				MLX5_GET_HCA_CAP_OP_MOD_ROCE |
-				MLX5_HCA_CAP_OPMOD_GET_CUR);
+				(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 		if (!hcattr) {
 			DRV_LOG(DEBUG,
 				"Failed to query devx HCA ROCE capabilities");
@@ -1396,7 +1396,7 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
 	if (attr->eswitch_manager) {
 		hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
 				MLX5_SET_HCA_CAP_OP_MOD_ESW |
-				MLX5_HCA_CAP_OPMOD_GET_CUR);
+				(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 		if (!hcattr)
 			return rc;
 		attr->esw_mgr_vport_id_valid =
@@ -1410,7 +1410,7 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
 
 		hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
 				MLX5_GET_HCA_CAP_OP_MOD_ESW_FLOW_TABLE |
-				MLX5_HCA_CAP_OPMOD_GET_CUR);
+				(uint32_t)MLX5_HCA_CAP_OPMOD_GET_CUR);
 		if (!hcattr)
 			return rc;
 		esw_reg = MLX5_GET(flow_table_esw_cap, hcattr,
-- 
2.49.0.vfs.0.3

Re: [PATCH] common/mlx5: avoid warning about operation mixing different enum types

[Dariusz Sosnowski]

Hi,

On Tue, May 27, 2025 at 04:41:25PM -0700, Andre Muezerie wrote:
> When compiling with MSVC, warnings like the one below pop up:
> 
> ../drivers/common/mlx5/mlx5_devx_cmds.c(554): warning C5287: operands
>     are different enum types
>     '<unnamed-enum-MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE>' and
>     '<unnamed-enum-MLX5_HCA_CAP_OPMOD_GET_MAX>'; use an explicit cast
>     to silence this warning
> 
> The values in both enums indicate that this sort of mixed bit
> manipulation is intentional, so this patch just uses an explicit
> cast to avoid the warning.
> 
> Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>

Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>

Best regards,
Dariusz Sosnowski

Re: [PATCH] common/mlx5: avoid warning about operation mixing different enum types

[Dariusz Sosnowski]

Hi,

On Tue, Jun 03, 2025 at 06:41:24PM +0200, Dariusz Sosnowski wrote:
> Hi,
> 
> On Tue, May 27, 2025 at 04:41:25PM -0700, Andre Muezerie wrote:
> > When compiling with MSVC, warnings like the one below pop up:
> > 
> > ../drivers/common/mlx5/mlx5_devx_cmds.c(554): warning C5287: operands
> >     are different enum types
> >     '<unnamed-enum-MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE>' and
> >     '<unnamed-enum-MLX5_HCA_CAP_OPMOD_GET_MAX>'; use an explicit cast
> >     to silence this warning
> > 
> > The values in both enums indicate that this sort of mixed bit
> > manipulation is intentional, so this patch just uses an explicit
> > cast to avoid the warning.
> > 
> > Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
> 
> Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
> 
> Best regards,
> Dariusz Sosnowski

@Patrick Could you please take a look at CI failures for this patch?
Here is the test report log: https://mails.dpdk.org/archives/test-report/2025-May/882321.html
There is a Fedora 41 compilation failure in "dpdk_compile_spdk".
It seems on the related to the patch, because it fails in SPDK code.

@Andre Could you please take a look at CI failure on Windows?
There is a unit tests failure on Windows Server 2022.

Best regards,
Dariusz Sosnowski

Re: [PATCH] common/mlx5: avoid warning about operation mixing different enum types

[Raslan Darawsheh]

Hi,


On 28/05/2025 2:41 AM, Andre Muezerie wrote:
> When compiling with MSVC, warnings like the one below pop up:
> 
> ../drivers/common/mlx5/mlx5_devx_cmds.c(554): warning C5287: operands
>      are different enum types
>      '<unnamed-enum-MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE>' and
>      '<unnamed-enum-MLX5_HCA_CAP_OPMOD_GET_MAX>'; use an explicit cast
>      to silence this warning
> 
> The values in both enums indicate that this sort of mixed bit
> manipulation is intentional, so this patch just uses an explicit
> cast to avoid the warning.
> 
> Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com> 

Patch applied to next-net-mlx,

Kindest regards
Raslan Darawsheh

Re: [PATCH] common/mlx5: avoid warning about operation mixing different enum types

[Andre Muezerie]

On Wed, Jun 04, 2025 at 09:42:31AM +0200, Dariusz Sosnowski wrote:
> Hi,
> 
> On Tue, Jun 03, 2025 at 06:41:24PM +0200, Dariusz Sosnowski wrote:
> > Hi,
> > 
> > On Tue, May 27, 2025 at 04:41:25PM -0700, Andre Muezerie wrote:
> > > When compiling with MSVC, warnings like the one below pop up:
> > > 
> > > ../drivers/common/mlx5/mlx5_devx_cmds.c(554): warning C5287: operands
> > >     are different enum types
> > >     '<unnamed-enum-MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE>' and
> > >     '<unnamed-enum-MLX5_HCA_CAP_OPMOD_GET_MAX>'; use an explicit cast
> > >     to silence this warning
> > > 
> > > The values in both enums indicate that this sort of mixed bit
> > > manipulation is intentional, so this patch just uses an explicit
> > > cast to avoid the warning.
> > > 
> > > Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
> > 
> > Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
> > 
> > Best regards,
> > Dariusz Sosnowski
> 
> @Patrick Could you please take a look at CI failures for this patch?
> Here is the test report log: https://mails.dpdk.org/archives/test-report/2025-May/882321.html
> There is a Fedora 41 compilation failure in "dpdk_compile_spdk".
> It seems on the related to the patch, because it fails in SPDK code.
> 
> @Andre Could you please take a look at CI failure on Windows?
> There is a unit tests failure on Windows Server 2022.
> 

Hi Dariusz,

I looked at the failed test. It should be unrelated to this patch. I ran
the same lcores_autotest on my machine compiling with MSVC and Clang
and it passed (with the changes in the patch).

For completeness, here is the output from CI:

44/92 DPDK:fast-tests / lcore_var_autotest             OK               0.35s
meson : ERROR: The process "4692" not found.
At C:\Users\builder\jenkins\workspace\Generic-VM-Unit-Test-DPDK@tmp\durable-3a3a8aa3\powershellScript.ps1:3 char:45
+ ...                      meson test --suite fast-tests -t 60 2>&1 | tee - ...
+                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (ERROR: The process "4692" not found.:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
 
45/92 DPDK:fast-tests / lcores_autotest                TIMEOUT        629.35s
>>> DPDK_TEST=lcores_autotest MALLOC_PERTURB_=25 C:\Users\builder\jenkins\workspace\Generic-VM-Unit-Test-DPDK\dpdk\build\app\dpdk-test.exe --no-huge -m 2048

46/92 DPDK:fast-tests / logs_autotest                  OK               0.16s

Thanks,
Andre Muezerie

> Best regards,
> Dariusz Sosnowski

Re: [PATCH] common/mlx5: avoid warning about operation mixing different enum types

[Dariusz Sosnowski]

On Wed, Jun 04, 2025 at 08:18:58AM -0700, Andre Muezerie wrote:
> On Wed, Jun 04, 2025 at 09:42:31AM +0200, Dariusz Sosnowski wrote:
> > Hi,
> > 
> > On Tue, Jun 03, 2025 at 06:41:24PM +0200, Dariusz Sosnowski wrote:
> > > Hi,
> > > 
> > > On Tue, May 27, 2025 at 04:41:25PM -0700, Andre Muezerie wrote:
> > > > When compiling with MSVC, warnings like the one below pop up:
> > > > 
> > > > ../drivers/common/mlx5/mlx5_devx_cmds.c(554): warning C5287: operands
> > > >     are different enum types
> > > >     '<unnamed-enum-MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE>' and
> > > >     '<unnamed-enum-MLX5_HCA_CAP_OPMOD_GET_MAX>'; use an explicit cast
> > > >     to silence this warning
> > > > 
> > > > The values in both enums indicate that this sort of mixed bit
> > > > manipulation is intentional, so this patch just uses an explicit
> > > > cast to avoid the warning.
> > > > 
> > > > Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
> > > 
> > > Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
> > > 
> > > Best regards,
> > > Dariusz Sosnowski
> > 
> > @Patrick Could you please take a look at CI failures for this patch?
> > Here is the test report log: https://mails.dpdk.org/archives/test-report/2025-May/882321.html
> > There is a Fedora 41 compilation failure in "dpdk_compile_spdk".
> > It seems on the related to the patch, because it fails in SPDK code.
> > 
> > @Andre Could you please take a look at CI failure on Windows?
> > There is a unit tests failure on Windows Server 2022.
> > 
> 
> Hi Dariusz,
> 
> I looked at the failed test. It should be unrelated to this patch. I ran
> the same lcores_autotest on my machine compiling with MSVC and Clang
> and it passed (with the changes in the patch).
> 
> For completeness, here is the output from CI:
> 
> 44/92 DPDK:fast-tests / lcore_var_autotest             OK               0.35s
> meson : ERROR: The process "4692" not found.
> At C:\Users\builder\jenkins\workspace\Generic-VM-Unit-Test-DPDK@tmp\durable-3a3a8aa3\powershellScript.ps1:3 char:45
> + ...                      meson test --suite fast-tests -t 60 2>&1 | tee - ...
> +                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     + CategoryInfo          : NotSpecified: (ERROR: The process "4692" not found.:String) [], RemoteException
>     + FullyQualifiedErrorId : NativeCommandError
>  
> 45/92 DPDK:fast-tests / lcores_autotest                TIMEOUT        629.35s
> >>> DPDK_TEST=lcores_autotest MALLOC_PERTURB_=25 C:\Users\builder\jenkins\workspace\Generic-VM-Unit-Test-DPDK\dpdk\build\app\dpdk-test.exe --no-huge -m 2048
> 
> 46/92 DPDK:fast-tests / logs_autotest                  OK               0.16s

Ok, thank you for checking.

Best regards,
Dariusz Sosnowski